Fedora to switch to Python 3 by default
From: | Kevin Fenzi <kevin-AT-scrye.com> | |
To: | Development discussions related to Fedora <devel-AT-lists.fedoraproject.org>, meetingminutes-AT-lists.fedoraproject.org | |
Subject: | Summary/Minutes from today's FESCo Meeting (2013-10-23) | |
Date: | Wed, 23 Oct 2013 13:41:30 -0600 | |
Message-ID: | <20131023134130.26afe4c7@voldemort.scrye.com> | |
Archive‑link: | Article |
=================================== #fedora-meeting: FESCO (2013-10-23) =================================== Meeting started by nirik at 18:00:04 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-10-2... . Meeting summary --------------- * init process (nirik, 18:00:04) * ticket #1164 F20 Changes - Process on Changes Freeze (nirik, 18:02:46) * AGREED: moving ryu to f21, wait on vagrant and lvm thin provisioning. (+8,0,0) (nirik, 18:05:32) * ticket #1181 Fedora still vulnerable to BEAST (nirik, 18:05:42) * AGREED: close ticket now that nss is rebuilt. Follow up with other related items on list. (nirik, 18:10:17) * ticket #1182 F21/F22 System Wide Change: Python 3 as the Default Implementation - https://fedoraproject.org/wiki/Changes/Python_3_as_Default (nirik, 18:10:29) * AGREED: Feature is approved, provided that the contingency plan is updated with permitting a mixed environment of py2/py3 (+6,-1,0) (nirik, 18:30:22) * FESCo strongly advises prioritizing this work on those packages that appear in the minimal and cloud images first (sgallagh, 18:30:33) * ticket #1183 Don't enable prelink by default in Fedora (nirik, 18:31:40) * AGREED: remove prelink from core and standard groups (+8,0,0) (nirik, 18:34:20) * ticket #1170 Working Group call for Volunteers (nirik, 18:34:39) * AGREED: pknirsch will coordinate base design working group for fesco. (+7,0,0) (nirik, 18:47:16) * AGREED: working groups can decide if they want new lists when they meet (+7,0,0) (nirik, 19:15:35) * AGREED: working groups should have a governance document/charter by nov 15th approved by fesco (+7,0,0) (nirik, 19:22:49) * Next week's chair (nirik, 19:27:01) * notting to chair next week (nirik, 19:28:40) * Open Floor (nirik, 19:28:44) * LINK: https://fedoraproject.org/wiki/Elections (nirik, 19:33:19) * LINK: https://fedoraproject.org/wiki/FESCo_election_policy (nirik, 19:34:30) * LINK: https://fedorahosted.org/fesco/ticket/360 (nirik, 19:35:34) Meeting ended at 19:40:29 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (139) * sgallagh (97) * mattdm (59) * jwb (35) * mitr (34) * notting (28) * pjones (24) * pknirsch (21) * adamw (17) * mmaslano (17) * jreznik (16) * t8m (11) * Viking-Ice (9) * zodbot (9) * drago01_ (8) * samkottler (2) * kalev (1) * abadger1999 (0) -- 18:00:04 <nirik> #startmeeting FESCO (2013-10-23) 18:00:04 <zodbot> Meeting started Wed Oct 23 18:00:04 2013 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:04 <nirik> #meetingname fesco 18:00:04 <nirik> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh 18:00:04 <nirik> #topic init process 18:00:04 <zodbot> The meeting name has been set to 'fesco' 18:00:04 <zodbot> Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:20 <nirik> who all is here today for exciting and fun fesco meeting? 18:00:25 <mmaslano> hi 18:00:29 <mattdm> oooh! I am! 18:00:30 <sgallagh> Greetings 18:00:36 <mitr> Hello 18:00:42 <t8m> hi all 18:00:51 <nirik> abadger1999 is off at ansiblefest today, so he likely won't be around. 18:01:07 <pjones> hello. 18:02:31 <notting> i'm here as long as the conference wifi holds up 18:02:37 <nirik> cool. 18:02:44 <notting> (and as long as we don't go too ridiculously long) 18:02:46 <nirik> #topic ticket #1164 F20 Changes - Process on Changes Freeze 18:02:46 <nirik> .fesco 1164 18:02:47 <zodbot> nirik: #1164 (F20 Changes - Progress on Changes Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/1164 18:03:02 <nirik> I'm +1 to jreznik's suggestion in the last comment. 18:03:32 <mitr> +1 18:03:39 <mattdm> Proposal: 18:03:41 <mattdm> mark Ryu Network Operating System as incomplete, postpone to F21 18:03:42 <t8m> +1 from me as well 18:03:43 <mattdm> Vagrant as Self Contained Change, not on any official media - wait for completion by Final Change Deadline, only for marketing purposes 18:03:45 <pjones> I'm +1 to that 18:03:45 <mattdm> same for OS Installer Support for LVM Thin Provisioning - Change is completed, missing user friendliness bits (profiles, LVM team is aware of it) 18:03:47 <sgallagh> nirik: +1, but it doesn't talk about what to do with the LVM change 18:04:00 * sgallagh misread 18:04:03 <mattdm> +1 18:04:16 <sgallagh> I missed the "same for" piece. Pay me no mind. 18:04:24 <mmaslano> +1 18:05:26 <notting> action plan seems reasonable - +1 18:05:32 <nirik> #agreed moving ryu to f21, wait on vagrant and lvm thin provisioning. (+8,0,0) 18:05:42 <nirik> #topic ticket #1181 Fedora still vulnerable to BEAST 18:05:42 <nirik> .fesco 1181 18:05:43 <zodbot> nirik: #1181 (Fedora still vulnerable to BEAST) – FESCo - https://fedorahosted.org/fesco/ticket/1181 18:05:47 <nirik> anything we still need to do here? 18:06:55 * jreznik is here, sorry, blocked on blocker review 18:07:25 <notting> i thought there was some discussion in the bugs of additional patching required, but i don't think it was anything that required more fesco attention 18:07:35 <pjones> nirik: I don't think so? we voted last week... 18:07:44 <jreznik> sgallagh: for lvm profiles, for dlehman it's considered done from his side, he told me to ask lvm guys what they think about it 18:07:50 <nirik> yeah, the thread petered out on the devel list, but it sounded like there might be dependent packages that need rebuilding? 18:08:12 <nirik> ok, I'll remove the meeting keyword then and we leave it for final tracking? or just close it? 18:08:26 <mitr> NSS has been switched in f20 (... but not in rawhide?) 18:08:34 <notting> i think we can close it if NSS itself is built 18:08:44 <mitr> The mailing list thread ended up addressing most issues I think 18:08:46 <mitr> => let's close it 18:08:54 <nirik> ok. 18:08:59 <sgallagh> Why isn't it built in Rawhide? 18:09:01 <nirik> why not rawhide? that seems strange. 18:09:04 <sgallagh> That seems to be missing the point 18:09:22 <mitr> I'll ask Elio separately 18:09:30 <pjones> I suspect it's just been overlooked because we're so close to the beta deadline 18:09:40 <pjones> but yeah, asking him can't hurt. 18:09:47 <nirik> yeah, please do. 18:10:06 <mitr> ... never mind, it's already been out in rawhide, so we are fine 18:10:17 <nirik> #agreed close ticket now that nss is rebuilt. Follow up with other related items on list. 18:10:18 <mitr> ("out" == "the offending patch hasn't been applied") 18:10:24 <nirik> cool 18:10:29 <nirik> #topic ticket #1182 F21/F22 System Wide Change: Python 3 as the Default Implementation - https://fedoraproject.org/wiki/Changes/Python_3_as_Default 18:10:29 <nirik> .fesco 1182 18:10:30 <zodbot> nirik: #1182 (F21/F22 System Wide Change: Python 3 as the Default Implementation - https://fedoraproject.org/wiki/Changes/Python_3_as_Default) – FESCo - https://fedorahosted.org/fesco/ticket/1182 18:11:59 <sgallagh> We were waiting on an update to the Change page. I haven't seen one 18:12:20 <nirik> There was some more discussion on list. 18:12:55 <mattdm> Do we want to defer until abadger1999 is back? Is there urgency? 18:13:11 <nirik> yeah, so punt another week and ask them to update contingency planning? 18:13:11 <notting> seems reasonable, i can't imagine there is urgency yet 18:13:11 <pjones> I would be for waiting for him, since he's the closest to this. 18:13:23 <sgallagh> mattdm: Well, we want to give people an idea whether this is likely to pass FESCo 18:13:33 <nirik> proposal: defer a week for more discussion/updating of feature page? 18:13:40 <sgallagh> Although I suppose the previous email "FESCo is inclined to approve" is probably sufficient on that. 18:13:48 <mmaslano> it would be nice to give those who propose the feature at least seems good to us 18:13:58 <sgallagh> I.e. if people want to start this effort, they should feel welcome to go ahead 18:14:05 <mattdm> I am generally in favor. 18:14:11 <mitr> The outstanding issues were 1) contingency plan, and 2) dnf bindings 18:14:13 <mattdm> And I trust people to work out the details. 18:14:27 <mattdm> Like, for example, those details. :) 18:14:30 <mitr> 2) has been resolved, and 1) AFAICS amounts to "we know we can have one, not sure whether we need to" 18:14:45 <jwb> apologies for interrupting, but can someone ping me when we get to the WG stuff? 18:15:00 <nirik> I'm generally in favor... but would like to see a better contingency plan... 18:15:03 <nirik> jwb: can do 18:15:08 <jwb> thx 18:15:47 <mitr> proposal: Change is approved, to be revisited when planning F21 18:16:30 <t8m> mitr, I think we can wait for the contingency plan proposal or at least some reasoning why we do not need one 18:17:10 <mitr> t8m: it's the other way around - the proposed contingency plan is a side tag; we have dgilmore arguing that that we don't need one 18:17:13 <nirik> yeah, I'd like to see a little better/more planning on contingency before approving 18:17:19 <sgallagh> Proposal: Change is approved, conditional upon the contingency plan as we specified previously 18:17:21 <mmaslano> well, it was proposed using different branch and not merging, but that wasn't approved by relengs 18:17:24 <nirik> I think a side tag is not a good contingency. 18:17:33 <mmaslano> nirik: what else should be done? 18:17:55 <nirik> ship both py2/py3 until the rest of items that were py2 that were not done are fixed? 18:18:02 <notting> i think we need a side tag to *stage*. is the contingency a side tag to build the un-do and then merge that? 18:18:19 <sgallagh> notting: Why do we need a side tag at all? 18:18:25 <nirik> notting: they wanted to build in a side tag, merge, then if it failed unmerge. 18:18:29 <notting> we're going to need py2 and py3 around for at least as long as we've had py2 and p3 so far, i think. depends on how the stacks are packaged 18:18:38 <sgallagh> If the contingency is to ship mixed, then can't we just build in the regular build system? 18:18:41 <notting> sgallagh: to build a stack switch from yum/dnf deps up to anaconda 18:18:46 <sgallagh> Then things can land as they arrive 18:18:53 <mitr> yum/dnf, anaconda, python-kickstart and the like need to land in Python3 version approximately at the same time 18:18:54 <sgallagh> hmm 18:19:08 <sgallagh> Ok, that makes sense. 18:20:20 <nirik> side tags should be short lived not kept around for multiple releases. 18:20:23 <nirik> they just don't work that way 18:21:13 <nirik> anyhow, I'm ok with punting to next week, approving conditionally on a better contingency plan either one. 18:22:11 <mitr> nirik: The proposal is to have a side tag only during the lifetime of f22 18:22:20 <mmaslano> +1 18:22:22 <sgallagh> Proposal: Feature is approved, provided that the contingency plan is updated with permitting a mixed environment of py2/py3 18:22:35 <nirik> mitr: but I don't see how that helps. 18:22:55 <nirik> sgallagh: sure, +1 18:23:00 <t8m> sgallagh, +1 18:23:06 <mitr> sgallagh: that sounds like asking them to ship parallel versions of the yum/anaconda stack 18:23:34 <sgallagh> mitr: Perhaps I was unclear with my phrasing. 18:23:35 <pjones> mitr: well, at least yum bindings? 18:23:35 <nirik> mitr: they said on list that anaconda should be able to keep py2/3 bindings for a few releases? 18:24:01 <sgallagh> That shouldn't imply that any of the components should be duplicated (except maybe bindings). 18:24:11 <mmaslano> sgallagh: +1 18:24:13 <pjones> if we can still use python2 bindings for a couple of releases, that's going to be good enough for anaconda. 18:24:21 <sgallagh> Just that we accept that we might have to have both py2 and py3 in the minimal image for a release 18:24:27 <nirik> right. 18:24:52 <nirik> sgallagh: +1 18:25:03 <mitr> works for me 18:25:05 <mitr> +1 18:25:09 <nirik> so, thats +5 I guess so far 18:25:13 <nirik> any other votes? 18:25:29 <sgallagh> +1 to my own proposal, for the record 18:25:35 <mattdm> I don't want to have both in the minimal image 18:25:43 <kalev> I would like to note that we've had both py2 and py3 on the Desktop image since F19. 18:25:52 <sgallagh> mattdm: Your case might be special. 18:26:09 <nirik> well, this is a contengency plan... not the desired outcome 18:26:12 <mattdm> sgallagh yes but I happen to care about it a lot 18:26:23 <sgallagh> Sorry, again being unclear. 18:26:37 <sgallagh> I mean, your image may be able to avoid this in any case, since you'll probably strip extra stuff out 18:26:46 <sgallagh> Your images don't use anaconda, do they? 18:27:23 <sgallagh> In any case, as nirik said, this is a contingency, not the plan 18:27:27 <mattdm> they use images generated by either anaconda or appliance-creator 18:28:16 <mattdm> yeah, I don't like that as a contingency -- it seems more like failure than a fallback 18:28:19 <nirik> ok, this passes, unless anyone wants to change votes? 18:28:40 <mattdm> i guess i'll officially vote -1 18:28:40 <sgallagh> mattdm: Then let's do our part to ensure that we don't hit this case. 18:28:43 <nirik> the other alternative is: revert work done back to py2 18:28:58 <mattdm> that sucks too but less for the cloud image 18:29:05 <sgallagh> Or force all work in this direction to guarantee compatibility with both 18:29:10 <sgallagh> But I doubt we have that much control 18:29:33 <pjones> sgallagh: I can be +1 as well, since anaconda is covered. 18:30:01 <mitr> There are very few python users in the minimal image IIRC anyway 18:30:06 <mattdm> anyway, outvoted, moving on. :) 18:30:22 <nirik> #agreed Feature is approved, provided that the contingency plan is updated with permitting a mixed environment of py2/py3 (+6,-1,0) 18:30:33 <sgallagh> #info FESCo strongly advises prioritizing this work on those packages that appear in the minimal and cloud images first 18:30:58 <nirik> should we do the prelink ticket before working groups? or does anyone care which? prelink might be quick (I hope) 18:31:13 * sgallagh remains in the "nuke it from orbit" group 18:31:15 <pjones> I already voted on prelink in the ticket and I've only got 15 more minutes. 18:31:34 <pjones> But I suspect it'll also be super fast, and I don't have any serious objects to the proposed WG members in the ticket. 18:31:36 <nirik> lets get it out of the way... 18:31:40 <nirik> #topic ticket #1183 Don't enable prelink by default in Fedora 18:31:40 <nirik> .fesco 1183 18:31:42 <zodbot> nirik: #1183 (Don't enable prelink by default in Fedora) – FESCo - https://fedorahosted.org/fesco/ticket/1183 18:31:58 <pjones> Proposal: remove prelink from base and standard. 18:32:04 <t8m> pjones, +1 18:32:12 <sgallagh> pjones: +1 (can I vote early and often on this?) 18:32:26 * pjones +1 18:32:29 <nirik> toshio was +1 in ticket 18:32:36 <mitr> I haven't seen enough to suggest that prelink is sufficiently maintained, so... sadly, +1 18:32:40 <nirik> I'm +1 (we are talking remove from standard right?) 18:32:50 <nirik> yeah, sorry. 18:32:58 <pjones> I phrased it very precisely ;) 18:33:02 <notting> base and standard? 18:33:09 <pjones> notting: as in "it should be in neither" 18:33:18 <nirik> you did. I just was off reading the ticket. ;) 18:33:21 <mattdm> +1 18:33:23 <pjones> not meaning to imply that it's in both or something. 18:33:47 <notting> pjones: just that those are the same thing 18:33:50 <notting> anyway, +1 18:33:58 <pjones> notting: oh right. 18:34:00 <pjones> bah. 18:34:11 <pjones> nirik: seems to have passed. 18:34:20 <nirik> #agreed remove prelink from core and standard groups (+8,0,0) 18:34:39 <nirik> #topic ticket #1170 Working Group call for Volunteers 18:34:39 <nirik> .fesco 1170 18:34:40 <zodbot> nirik: #1170 (Working Group call for Volunteers) – FESCo - https://fedorahosted.org/fesco/ticket/1170 18:35:06 <sgallagh> First order here should probably be to discuss the Base Design WG 18:35:18 <nirik> ok 18:35:46 <sgallagh> Last week we happily volunteered notting for the position, but he has had to decline. Sorry about that, notting. 18:36:32 <notting> has had to? :) heh. in any case, new blood is good. 18:36:34 <sgallagh> nirik: You are the other FESCo volunteer on that group, but as I've also requested you on the Server WG, I would understand if you aren't jumping up and down here 18:37:10 <nirik> mitr: is also there? 18:37:16 <sgallagh> jwb: BTW, we're discussing WGs now. 18:37:23 <sgallagh> Is he? 18:37:31 <nirik> oh yeah, I blame the cold meds. Sorry. 18:37:47 <jwb> :) 18:38:08 <nirik> anyhow, mitr: would you be willing to be coordinator for base wg? 18:38:16 <sgallagh> Hmm, I missed his name. He's also on my request list for Server WG :) 18:38:37 <mitr> sgallagh: I'm also on the server WG, and I specifically don't want to be choosing members of the base WG => I'd like to decline as well 18:39:11 * sgallagh lucked out and claimed the good ones early 18:39:24 <nirik> ha. hot potato hot potato. 18:39:38 <sgallagh> Well, I'd like to make an alternate (non-FESCo) suggestion 18:39:44 <nirik> ok, if no one else will I will help coordinate base design then. 18:39:58 <drago01_> do the selection by a rng ;) 18:40:17 <sgallagh> nirik: Are you withdrawing from the Server WG, or are you going to take both on? 18:40:43 <nirik> sgallagh: well, I could withdraw if you want, or try and do both. So much to do. ;) 18:40:57 <mattdm> we can try to find nirik more minions 18:40:57 <jwb> fwiw, i think some overlap in members is probably good 18:41:05 * pknirsch nods 18:41:07 <jwb> particularly among base and other WGs 18:41:14 <mattdm> overlap between these particulary groups seems good, yeah. 18:41:15 <Viking-Ice> didn't you guys discuss early that this was so time consuming work that one could only serve in one WG? 18:41:21 <pknirsch> especially base will have to talk a lot with the other teams 18:41:28 <sgallagh> Viking-Ice: We phrased it as "strongly recommend against it" 18:41:31 <sgallagh> But didn't forbid it. 18:42:02 <jwb> some people are in a position to do more, so forbiding it would be excessive just on the grounds of "it takes a lot of time" 18:42:06 <mitr> (for the record, I'm crazy enough to still try to do both server and base) 18:42:18 <notting> sgallagh: what was your alternate suggestion? 18:42:20 <mitr> ... depending on what the coordinator chooses, of course. 18:42:20 <nirik> yeah, I signed up for those two too. 18:42:33 <nirik> but if you want to try another coordinator for base that would be fine too. ;) 18:42:34 <sgallagh> I was going to propose pknirsch for the coordinator. 18:42:57 <mattdm> If nirik feels able to do both, I'm +1 to that. 18:43:05 * pjones now has to go. 18:43:27 <pknirsch> i'd certainly be willing to be coordinator for base 18:43:37 <sgallagh> Yeah, if nirik is up to it, I'm fine with that as well. I just don't want him to feel like he's cornered into it :) 18:43:46 <mattdm> I would also be good with pknirsch as alternate if nirik prefers not to 18:43:52 <mattdm> given an out :) 18:43:55 <pknirsch> :) 18:44:11 <nirik> :) ok, in the interests of my time, lets let pknirsch do it. ;) 18:44:30 <adamw> sgallagh asked me to note that i might be interested in joining one of the WGs if there's interest 18:44:33 <pknirsch> alright, thanks nirik. and i don't want to steal your work :) 18:44:45 <pknirsch> just for the record :) 18:44:46 <adamw> seems like QA might want someone to be 'on the bus' at least 18:44:56 <Viking-Ice> the nomination period is over 18:45:08 <pjones> adamw: there is one WG that currently has no QA people... 18:45:08 <adamw> Viking-Ice: sgallagh was sounding me out the other day about late nominations 18:45:13 <adamw> pjones: which one? 18:45:18 <nirik> pknirsch: I'm sure things would be in good hands with you... and you might have more time to devote to it. 18:45:21 <jwb> er... 18:45:33 <drago01_> adamw: workstation 18:45:33 <adamw> looks like we have viking_ice and handsome_pirate involved in a couple 18:45:37 <jwb> so i asked earlier this week and was told we had to make the list from people on the nominee list 18:45:39 <pjones> "NOTE: There were no representatives from QA that nominated for this WG. I will be encouraging participation from all that want to pitch in anyway, but I'll explicitly try discussing things with QA as we go forward. " - from the workstation list. 18:45:42 <sgallagh> Viking-Ice: As a special case, since he happened to be on vacation the whole nomination period 18:45:51 <Viking-Ice> adamw, more thinking about those that did nominate but did not get selected while people that did not nominate suddenly did 18:45:52 <sgallagh> And having QA people aboard makes sense 18:46:02 <pknirsch> nirik: i'll certainly do my best :) 18:46:05 <nirik> so, votes on pknirsch for coordinator for base design group? 18:46:15 <mattdm> yes let's do one thing at a time here 18:46:18 <mattdm> +1 pknirsch 18:46:21 <adamw> Viking-Ice: yeah, I know - i figured i'd missed the bus... 18:46:22 <sgallagh> +1 pknirsch 18:46:25 <nirik> +1 here 18:46:27 <mitr> +1 pknirsch 18:46:36 <mmaslano> +1 pknirsch 18:46:41 <pjones> +1 18:46:42 * pjones really goes. 18:46:44 <notting> i can be +1 to either nirik or pknirsch 18:47:16 <nirik> #agreed pknirsch will coordinate base design working group for fesco. (+7,0,0) 18:47:19 <sgallagh> jwb: Yeah, and that's officially the rule. But I noted that we were *extremely* limited in QA reps and was hoping we could loophole the guy who was out of touch during the nomination period :) 18:47:20 <nirik> thanks pknirsch 18:47:29 <pknirsch> thanks everyone for the vote of confidence ;) 18:47:38 * adamw is happy to be loopholed or not. 18:47:43 <sgallagh> But that obviously wouldn't be my sole decision 18:47:57 <mattdm> Also note that the initial membership does not automatically constitute the membership 4 life 18:48:01 * adamw is currently 1500 mails behind on devel-list, so missed the whole thing. 18:48:02 <jwb> sgallagh, the issue is that we've already drafted the lists and verified people still want to do it 18:48:10 <nirik> ok, should we now approve/vote on the proposed working groups? or do we want to discuss adding adamw as a late candidate? 18:48:20 <jwb> so unless we're talking about Base, we'd have to bump to add late-commers 18:48:33 <sgallagh> jwb: I was mostly thinking of base, yeah 18:48:50 <jwb> ok. and to be clear, i want QA input regardless of voting member status. 18:48:51 <adamw> jwb: ah, i wouldn't want to kick anyone out. 18:48:56 <jwb> adamw, base isn't formed. 18:49:01 <jwb> so yeah, maybe loophole there 18:49:05 <drago01_> adamw: just delete those 1500 mails ;) 18:49:08 <adamw> base is probably where i'd be interested in, anyway. 18:49:19 <Viking-Ice> nirik, if you are going to add one in then you can just as well wipe the slate clean regarding the nominators, approving this is a double edged sword 18:49:19 <adamw> drago01_: hell, no, i already found out the bugzilla header thing, which is like my favourite thing all year 18:49:22 <mitr> I'd lean towards not bending the rules here, 1) as a matter of principle, 2) because bending them doesn't give us _that_ much anyway: elections are within a few months, and we can get QA input even without formal membership 18:49:55 <drago01_> adamw: ;) 18:49:55 * nirik is with mitr 18:50:02 <notting> ... and a WG can have as its first meeting voting to eject one of its own members for a different person anyway. each WG can invent its own loopholes 18:50:03 <pknirsch> i'd personally love you in base, adamw, even if you're late on the bus ;) 18:50:15 <jwb> notting, ha, fair 18:50:19 <pknirsch> hehehe 18:50:24 <adamw> process hackery! 18:50:32 <jwb> governance model is the first thing to draft. it isn't a hack. 18:50:59 <sgallagh> OK, then it sounds like in order to be fair, we should keep adamw off the lists. Sorry for the noise, folks. 18:51:11 <adamw> so, um, what's the status with the base group? 18:51:20 * adamw is a tad confused whether that is included in the current voting or not 18:51:35 <sgallagh> adamw: The coordinator we selected last week couldn't do it. So pknirsch will draft a group for next week to be ratified 18:51:49 <nirik> right. 18:51:59 <pknirsch> i'll be assembling a list of proposed nominees for it and put it in https://fedorahosted.org/fesco/ticket/1170 18:52:12 <adamw> OK. executive summary: am I too late for that one or not? 18:52:19 <nirik> so shall we vote on each proposed group? or vote +1 on all by default unless objections? 18:52:40 <jwb> adamw, think you're too late 18:52:42 <sgallagh> adamw: I think we're going to stick to the rules 18:52:44 <adamw> roger. 18:52:45 <nirik> adamw: I think we decided you are too late, but that group once formed could decide to drop a member and add you 18:52:50 <sgallagh> However, that doesn't mean you shouldn't participate 18:52:55 <sgallagh> Just that you won't get a vote 18:52:55 <nirik> right. 18:52:56 * adamw has his peanuts ready already/. 18:53:01 <nirik> this is just voting members. 18:53:38 <nirik> ok, so does anyone object to any of the proposed makeup of working groups? 18:54:07 * nirik is fine with all of them in the ticket so far. 18:54:13 * mattdm is too 18:54:22 <mitr> no objections 18:54:44 <mitr> Are there proposed candidates for the cloud group? 18:55:03 <nirik> I don't see them in ticket yet. 18:55:07 <t8m> no objections 18:55:22 <notting> no objections to the list so far. curious how the multi-desktop participation in workstation works out in terms of deliverables, but that's for them to figure 18:55:47 <jwb> i think that's notting's way of saying i'm crazy? 18:56:14 <pknirsch> :) 18:56:28 <nirik> yeah, I definitely am curious how non featured products will shake out... 18:56:45 <sgallagh> mattdm: Cloud nominees? 18:57:03 <nirik> so we need cloud and base... we could do them next week? 18:57:14 <mattdm> no i have my list... 18:57:26 <sgallagh> I have no objections to any of the currently-proposed WGs 18:57:33 <mattdm> i was sure I put it in trac. hold on... 18:57:41 <sgallagh> mattdm: Not there yet, no 18:58:09 <mattdm> one second 18:58:22 <nirik> thats +6 for approving the workstation, server and env and stacks groups I think... (If I counted right) 18:59:18 <jwb> nirik, notting: i have my own ideas on that, but yeah it will be interesting to see. i've hopefully set it up to be collaborative and not combative 18:59:23 <mattdm> okay there now. 18:59:35 <mattdm> without little nice comments about everyone -- that seems to have gotten lost. 18:59:40 <mattdm> (not sure what happned there. 18:59:54 <sgallagh> mattdm: That's what the "preview" button is for 18:59:55 <sgallagh> :) 19:00:10 <mattdm> preview button probably ate my original post :) 19:00:14 <t8m> no objection to cloud wg list either 19:00:35 <nirik> that does put sam in 2 groups... but if he's got the time I guess... 19:00:37 <sgallagh> Is Sam Kottler okay with serving on both Cloud and Stacks? 19:00:47 <notting> ooh, you tabbed the FPL. no fair going above everyone! 19:01:04 <mattdm> notting mwhahaha. 19:01:07 <notting> samkottler: question for you above 19:01:39 <samkottler> sgallagh: yeah, I'm okay with it despite what my sleep pattern might have to say about it 19:01:50 <mmaslano> I also picked Jens Petersen, and he's already in Workstation, so... 19:02:04 <mmaslano> I'll have to ask him where he'd like to stay 19:02:14 <sgallagh> mmaslano: Ah, I missed that too 19:02:45 <notting> samkottler: sleep pattern, course load, patch backlog... 19:03:05 * nirik has no real objections to proposed cloud makeup either 19:03:31 <samkottler> notting: :P all the things are busy 19:03:44 <notting> cloud group seems ok 19:03:55 <nirik> so, all those ok for everyone then? and we do base next week? 19:04:19 <nirik> query: do we have a short list of deliverables we want from each working group? if not, should we make one now? 19:04:30 <sgallagh> I'd like to recommend that the coordinators of approved WGs get a WhenIsGood sent out to all of their participants and should meet before the next FESCo meeting 19:05:10 <mattdm> nirik: short list of deliverables for product wgs https://fedoraproject.org/wiki/Fedora.next/boardproposal#... 19:05:20 <mattdm> it is a little more vague for base and env/stacks 19:05:26 <mattdm> which is probably my fault 19:05:51 <nirik> ok, great. 19:05:59 <sgallagh> Also "January 2014" is a little vague as well. 19:06:01 <nirik> just want to make sure groups know what they should be working on. 19:06:05 <sgallagh> Beginning? End? 19:06:06 <Viking-Ice> I would propose WG start working on defining "Product Interactions" a.s.a.p there seems to be a bit of overlap on the suggestion page 19:06:59 <sgallagh> Should we set a deadline for the governance charter? 19:07:01 <mmaslano> mattdm: no worries, guys already have some ideas about env/stack. I can sum ti up on some mailing list 19:07:01 <mattdm> Viking-Ice yes, that's important 19:07:07 <nirik> Viking-Ice: having requirements docs hopefully will help identify those interaction areas. 19:07:29 <mattdm> and if they come into conflict we can work it out. 19:07:38 <nirik> so, speaking of mailing lists... 19:07:52 <sgallagh> Negotiating overlap is one duty that FESCo should be retaining here 19:08:10 <mattdm> +1 sgallagh. and the development will be done in the open so there should not be any surprises 19:08:18 * nirik nods 19:08:59 <nirik> I'd prefer to reuse existing lists if possible... 19:09:08 <mattdm> I'm okay with setting a deadline, but I do note that we put the january deliverable out there so that time demands of the f20 release wouldn't make participation hard. 19:09:14 <mattdm> +1 to prefering existing lists 19:09:16 <nirik> desktop -> workstation, cloud -> cloud, server -> server, stacks and base -> devel 19:09:17 <mmaslano> nirik: I don't :) 19:09:22 <sgallagh> mattdm: Yes, but *when* in January? 19:09:27 <sgallagh> Somewhat vague. 19:09:28 <nirik> mmaslano: ok. why not? 19:09:56 <mmaslano> nirik: I guess someone wanted less email on devel, do you think it will help when we start disucssing stacks there? 19:10:00 <jreznik> sgallagh: I'd say try to avoid early Jan 19:10:02 <jwb> setting a deadline for what exactly? all of the items on the list? 19:10:02 <sgallagh> I'm planning to use server@lists.fp.o for the Server WG 19:10:22 <t8m> nirik, I think stacks should have its own list 19:10:37 <t8m> nirik, keeping base on devel would be fine (at least for me) 19:10:44 * pknirsch nods 19:10:57 <pknirsch> we can always prefix the subject with [BaseWG] e.g. 19:11:03 <mitr> sgallagh: If we weren''t 90% done by Jan 1, and started to look at the specific deadline to get something delivered, we'd be in deep trouble anyway 19:11:05 <sgallagh> We should consider publishing regular updates to devel@ though 19:11:07 <pknirsch> so that it can be clear that the topic is about that 19:11:16 <nirik> well, the problem with more lists is that people don't like subscribing to more and mroe lists, so they stop... and sure your new list is quiet, but only because you aren't getting the feedback you really should be getting. 19:11:24 <nirik> I guess I could see stacks being seperate. 19:12:18 <mmaslano> nirik: ok, I'll ask rest of the group again, they wanted new today 19:12:38 <mattdm> mmaslano you can ask them on the new list! oh wait. 19:12:40 <nirik> how about this proposal: use existing lists for now, working groups when they meet can decide if they require a new list and request it? 19:12:44 <mmaslano> mattdm: ha 19:12:54 <sgallagh> nirik: Seems reasonable to me. +1 19:13:21 <mitr> +1 (let's not spend time on this...) 19:13:23 <nirik> instead of us deciding, they can decide how best to go. 19:13:38 <mattdm> +1 to all of those sentiments 19:14:19 <nirik> any other votes? objections? :) 19:15:03 <mmaslano> +1 19:15:05 <t8m> +1 19:15:28 <notting> nirik: i like it. +1 19:15:35 <nirik> #agreed working groups can decide if they want new lists when they meet (+7,0,0) 19:15:43 <nirik> ok, what else do we need to decide here? 19:15:54 <jwb> did you set deadlines for specific items on the list of stuff to produce? 19:16:17 <jwb> "january" is all i heard, and i'm assuming that's for all the things in the lsit 19:16:17 <nirik> we have not yet. 19:16:21 <nirik> yeah. 19:16:43 <sgallagh> Governance charter really should be sometime in December 19:16:44 <mattdm> Do we need deadlines or is it okay to just start working? Is there a lack of urgency without? 19:16:48 <mitr> jwb: https://fedoraproject.org/wiki/Fedora.next/boardproposal#... mentions January only for the first 2 19:16:55 <sgallagh> If only to give time to deal with any voting app stuff 19:16:58 <drago01_> how about "asap" (so that we can plan for a release) 19:17:23 <mitr> Overall I'm not thrilled about establishing too many interim deadlines (... and imposing a waterfall model by that) 19:17:27 <jwb> i would think you at least want the governance charter set before you start working on the PRD 19:17:40 <jwb> and does fesco have to approve that? 19:17:44 <mattdm> and we want to start working on the prd right away 19:18:07 <notting> a PRD can predate governance, no? 19:18:16 <jwb> it can, but i'm not sure you want it to 19:18:23 <nirik> I'd say yes, or at least object if there's something problematic in one. 19:18:38 <jwb> what happens if people quit because they don't agree with the majority? 19:18:42 <jwb> etc 19:19:32 <nirik> I'd hope we wouldn't get too complex with charters... 19:19:35 <pknirsch> you can always start drafting it though i suppose? 19:19:52 <jwb> pknirsch, it? 19:19:55 <pknirsch> prd 19:20:03 <pknirsch> e.g. start getting input 19:20:05 <nirik> if it would help I can whip up a default/template thing for groups? 19:20:10 <pknirsch> collecting it in a wiki or some form 19:20:13 <pknirsch> etc. 19:20:37 <jwb> yes, yes, sure. but i think getting the charter in place is important enough to give it a due date. it doesn't have to be complex, but i think it's necessary 19:20:45 <mattdm> +1 jwb 19:20:50 <nirik> how about dec 1st? 19:20:50 <pknirsch> sure, absolutely 19:20:52 <mattdm> let's make that soon then. 19:21:01 <jwb> nirik, i was thinking more like nov 15 19:21:01 <nirik> sorry, thats a sunday 19:21:09 <nirik> ok, thats fine too 19:21:15 <mattdm> +1 nov 15th 19:21:20 <nirik> +1 nov 15th 19:21:44 <mitr> +1 nov 15th 19:21:52 <sgallagh> +1 nov 15th 19:22:12 <sgallagh> Are we requiring FESCo ratification, or are we giving a free hand here? 19:22:25 <jwb> the FESCo section on the wiki page implies approval 19:22:26 <notting> +1 nov 15th 19:22:30 <t8m> +1 19:22:32 <mmaslano> +1 19:22:42 <jwb> or if not approval, at least oversight of some form 19:22:45 <sgallagh> jwb: Right, thanks. Just making sure. 19:22:49 <nirik> #agreed working groups should have a governance document/charter by nov 15th approved by fesco (+7,0,0) 19:22:59 <sgallagh> i.e. "We vote unanimously to be dictators-for-life" won't fly :) 19:23:08 <jwb> heh 19:23:42 <nirik> ok, anything further we need to setup for working groups? 19:24:05 * nirik will move on to open floor in a min if not 19:24:13 <drago01_> just one question are they supposed to stick "forever" or just kick of the new products etc? 19:24:52 <drago01_> if yes how does those interact with fesco? who approves features etc etc. (lots of open questions) 19:24:53 <sgallagh> drago01_: We agreed last week that the charter would go into effect at the next FESCo election period 19:24:59 <nirik> IMHO they are around as long as that product is a featured product produced by fedora 19:25:23 <nirik> yeah, there's def lots of open questions still. 19:25:27 <sgallagh> I'd say that's also part of the governance that they have to design 19:25:33 <drago01_> ok 19:25:49 <sgallagh> Are they designing the "100% all of the future" PRD, or the F21 PRD? 19:26:03 <sgallagh> (for example) 19:26:24 <sgallagh> Let's leave that up to the charter process to deal with 19:26:31 <sgallagh> And if it's not satisfactory, revisit then 19:26:44 <mitr> We all have better things to do than to hypothetically discuss how 5 different groups will solve the same problem, don't we? 19:26:46 <nirik> I don't think it's possible to design one thing now that will be good forever. :) At least not if you want it to adopt good changes moving forward. 19:26:53 <notting> sgallagh: 'next election period'? that would be next month,. 19:26:53 <nirik> right. moving on then... 19:26:56 <mitr> Let's either prescribe a common solution now, or ove to a different topic. 19:27:01 <nirik> #topic Next week's chair 19:27:08 <nirik> who wants it? 19:27:20 <sgallagh> notting: Last week we agreed to move the election period until after the WG initial deliverables 19:27:24 <sgallagh> For pretty much this reason. 19:27:48 <notting> sgallagh: ok 19:28:03 <nirik> did we get a board ack for that? (or ask for one)? 19:28:15 <notting> i can do next week, it's been a bit 19:28:26 <sgallagh> nirik: I think jwb gave us tacit approval on their behalf. 19:28:35 <nirik> notting: thanks! 19:28:40 <nirik> #info notting to chair next week 19:28:44 <nirik> #topic Open Floor 19:28:56 <nirik> I had 2 random things to mention... 19:29:11 <sgallagh> So, I've been hanging around blocker bug meetings lately. Things look a little risky for Anaconda... 19:29:16 <mattdm> I think we should probably formally ask the board 19:29:21 * mattdm can file a ticket 19:29:23 <nirik> 1. There's some talk on the devel list about sponsorship... did we want to look at making any changes in the sponsorship process for packagers? 19:29:25 <sgallagh> mattdm: Thanks 19:29:36 <jwb> sgallagh, i don't think i can speak for the board. i also don't think there will be a big deal about it 19:29:50 <sgallagh> jwb: Hooray for cognitive dissonance ;-) 19:29:56 <Viking-Ice> sgallagh, what do you mean risky? 19:30:09 <jreznik> sgallagh: for elections, I can take care, already asked ankur and we need a new elections coordinator but I can do it probably 19:30:11 <sgallagh> Viking-Ice: As in, it doesn't look like they'll be ready in time for beta 19:30:21 <Viking-Ice> so what else is new? 19:30:42 <jwb> sgallagh, that's not so much cognitive dissonance as "sigh, formality seems excessive but sigh" 19:30:56 <mitr> Re: elections, the current FESCo policy mentions "the combined elections" FWIW - but that's all up to the board 19:31:34 <jreznik> mitr: well, it makes sense to combine both - I think this is combined work of both FESCo and Board 19:31:46 * nirik now cannot recall the second thing he was going to mention. oh well, must not be important. ;) 19:32:00 <notting> i really have to head out at this point... 19:32:29 <Viking-Ice> sgallagh, I've been trying get somekind of feed back from the anaconda team regarding their development cycle because to be able to deal effectively with multiple products in QA we need to either need to move it sooner or later in the release cycle 19:32:29 <mattdm> hey where IS the current election schedule policy? 19:32:39 * jreznik will take care of elections coordination, just wanted more data before doing so... as otherwise it would be the right time to start coordination 19:32:52 <mattdm> fesco page just says "FESCo elections will be held twice a year, as part of the Fedora Project combined election process." -- with no reference to that process. 19:33:19 <nirik> https://fedoraproject.org/wiki/Elections 19:33:22 <jreznik> mattdm: there are some rules in the overall schedule but we are not very strict 19:34:08 <mattdm> nirik that page doesn't seem to say how the schedule is determined 19:34:30 <nirik> https://fedoraproject.org/wiki/FESCo_election_policy 19:34:53 <mattdm> nirik gah infinite loop! 19:35:34 <nirik> https://fedorahosted.org/fesco/ticket/360 19:35:39 <sgallagh> So as far as I can tell, the exact timing is left unspecified 19:36:01 <mattdm> jreznik do you mean you plan to talk to the board and i shouldn't? 19:36:15 <nirik> we changed our exacting policy to be the 'combined' one, but yeah, not sure where the combined one is defined. 19:36:26 <jreznik> mattdm: http://fedorapeople.org/groups/schedule/f-20/source/f-20.tjp - some rules are there but we don't use this big schedule anymore and ankur did it in it's own 19:36:41 <jreznik> mattdm: yeah, I'm planning to do it 19:36:51 <jreznik> btw. we need elections wrangler... 19:36:52 <mattdm> jreznik okay awesome. so I won't. :) 19:37:09 <jreznik> so any volunteer? otherwise I'll take care 19:37:28 <mattdm> *crickets* 19:37:37 <sgallagh> Proposal: Eliminate voting and allow people to serve until they're sick of it... /sarcasm 19:37:50 <nirik> well, you can also ask for volunteers on list, etc... 19:37:57 <jreznik> sgallagh: it would be pretty short term 19:38:00 <nirik> anyhow, anything further for open floor? or shall we close out? 19:38:04 <jreznik> nirik: yep, planning to do so 19:38:22 <Viking-Ice> sgallagh, propsal: magic eight ball to be used instead ;) 19:38:27 <jreznik> just there's usually more work from my side to coordinate work/schedules than just doing by myself 19:38:44 <sgallagh> Viking-Ice: Shh... that's actually how the voting system works under the hood 19:38:45 <jreznik> but once I come back with answer from Board, I'll start with it 19:39:21 <jreznik> another question jwb raised some time ago - do we still need Board and with products governance... 19:39:22 * nirik will close in a minute if nothing further 19:39:52 <jwb> jreznik, that's clearly something for the board to decide 19:39:54 <sgallagh> jreznik: I don't think that FESCo can unilaterally dissolve the Board. 19:40:04 <nirik> indeed. 19:40:16 <sgallagh> Nor do I think that starting a coup is a good way to proceed on these plans :) 19:40:26 <nirik> ok, thanks for coming everyone. 19:40:29 <nirik> #endmeeting -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
(Log in to post comments)
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 10:04 UTC (Thu) by josh (subscriber, #17465) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 10:08 UTC (Thu) by euske (subscriber, #9300) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 13:51 UTC (Thu) by jonnor (guest, #76768) [Link]
Having to keep patches for shebangs is not KISS.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 14:17 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 15:48 UTC (Thu) by epa (subscriber, #39769) [Link]
That PEP does sayin preparation for an eventual change in the default version of Python, Python 2 only scripts should either be updated to be source compatible with Python 3 or else to use python2 in the shebang line.so I don't think you are right to say that /usr/bin/python should always point to Python 2. Just for the time being.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 15:52 UTC (Thu) by anatolik (subscriber, #73797) [Link]
Only scripts that are both v2 and v3 source compatible should use /usr/bin/python. If your script uses v2 features that it should use /usr/bin/python2 explicitly.
So Arch did everything right. And that is why I love Arch that it always do things right.
It is better to help projects to migrate to python3. I, for example, updated many of my AUR to python3 and sent patches upstream.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 16:50 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
"Avoiding breakage of such third party scripts is the key reason this PEP recommends that python continue to refer to python2 for the time being"
This situation MAY change in the future but if any distribution is pointing /usr/bin/python to python 3, they aren't following the recommendations of upstream Python project.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 17:19 UTC (Thu) by anatolik (subscriber, #73797) [Link]
PS This v2->v3 Python migration looks ridiculous. Especially if compare to recent Ruby migration (1.8->1.9->2.0).
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 17:38 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 18:36 UTC (Thu) by anatolik (subscriber, #73797) [Link]
Well if you do not want to change your server configuration why do you install new version of Fedora at all? Arch and Fedora are known by their philosophy of living on the edge. And they first who changed python to v3 by default (somebody should be the first). If you do not like changes and do not want to make your scripts pythonv3 compatible then use other distro, thankfully there are a lot of different flavors with different release/support schedules.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 18:54 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:01 UTC (Thu) by anatolik (subscriber, #73797) [Link]
Arch moved to Python3 Oct'2010 [1], PEP was accepted Feb'2012 [2]
So obviously Arch did not break any PEP at the time of migration.
[1] https://www.archlinux.org/news/python-is-now-python-3/
[2] https://mail.python.org/pipermail/python-dev/2012-Februar...
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:06 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:22 UTC (Thu) by anatolik (subscriber, #73797) [Link]
Arch developers made a huge effort on making sure all the packages work with Python3. And were active at fixing all the incompatibilities.
> It is not too late to revert the change either. They really should do it.
Hopefully they will not do it. And I will vote against switching python to v2. Arch successfully uses python3 as a default version for 2 years now and those who needs python2 can easily install one. I have a number of packages that use python3 and python2, I do not see any problem with this. Hopefully Fedora will switch to Python3 as well. No more procrastination! Python community should more forward. Look at the Ruby community - it is a good source of inspiration for Python developers.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:30 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
So? That has nothing to do with user scripts.
"Hopefully Fedora will switch to Python3 as well. No more procrastination! Python community should more forward."
Fedora will switch to Python 3 as will other distributions but unlike Arch will not make /usr/bin/python point to Python 3 by default. This entire conversation has nothing to do with procrastination or not moving forward.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:31 UTC (Thu) by khim (subscriber, #9252) [Link]
Arch developers made a huge effort on making sure all the packages work with Python3. And were active at fixing all the incompatibilities.
IOW: they broke system's ABI for no good reason they spent a lot of time trying to fix it. Apparently they have too much time on their hands.
Hopefully they will not do it.
It's their choice. They have the right to do anything they want in their system but upstream will continue to use /usr/bin/python for python2-only scripts. I know of at least one project which does not plan to support system where /usr/bin/python is Python3 any time soon.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:57 UTC (Thu) by dlang (guest, #313) [Link]
>Arch developers made a huge effort on making sure all the packages work with Python3. And were active at fixing all the incompatibilities.
you just aren't getting it.
The issue isn't with Python scripts that Arch provides, it's with Python scripts from other sources, including scripts written in-house.
It's all those scripts that you have opted to break needlessly
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 0:01 UTC (Fri) by rahvin (guest, #16953) [Link]
I get why you are mad, stuff like this is the reason I stopped using Gentoo, but the fact is that what Arch does or doesn't do frankly doesn't matter.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 15:52 UTC (Fri) by leifbk (subscriber, #35665) [Link]
A Gentoo system has both Python 2 and 3 installed. You can choose yourself if you want to use Python 2 or 3 as default for user scripts:
balapapa ~ # eselect python list Available Python interpreters: [1] python2.7 * [2] python3.2
Your comment that «stuff like this is the reason I stopped using Gentoo» is just plain BS. If you can't handle tools like eselect, you probably should stick to Ubuntu.
Fedora to switch to Python 3 by default
Posted Oct 26, 2013 4:03 UTC (Sat) by rahvin (guest, #16953) [Link]
I don't play the game jump to conclusions and I suggest you stop playing it here as it's really not appropriate in this forum, you will find it's played frequently at slashdot where you can satisfy your craving for it.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:15 UTC (Thu) by khim (subscriber, #9252) [Link]
And during this 5 year period developers were not able to make theirs source v2/v3 compatible or at least fix shebang?
And how could they do that? Most popular desktop UNIX (this being MacOS) does not provide /usr/bin/python2, it only provides /usr/bin/python, which was upgraded to python 2.6 only with Snow Leopard in 2009. And you can only can use print as a function in python2.6 which means that, realistically speaking, you can start writing python2+3 scripts when you know that you can abandon all platforms where python 2.6 does not exist. One such platform is Ubuntu Lucid which will be supported till April 2015 (on servers). Which means that, realistically speaking, switch from python2 to python2+3 will happen after that time. Then we'll need to wait till python3 will be included in MacOS, etc.
This v2->v3 Python migration looks ridiculous. Especially if compare to recent Ruby migration (1.8->1.9->2.0).
Or effortless guile 1.x to guile 2.x transtions. Yup, it's quite easy to introduce incompatible changes into a component of your system which is not used much. And, of course, difference between ruby 2.0 and ruby 1.8 is much smaller then difference between python3 and python2.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 21:45 UTC (Thu) by proski (subscriber, #104) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 22:06 UTC (Thu) by khim (subscriber, #9252) [Link]
Even if you ignore server stuff you still are stuck with the fact that Lucid was supported till April 2013.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 22:22 UTC (Thu) by mgedmin (subscriber, #34497) [Link]
And you can get 2.7 (or 3.3) from the deadsnakes PPA: https://launchpad.net/~fkrull/+archive/deadsnakes?field.s...
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 0:10 UTC (Fri) by khim (subscriber, #9252) [Link]
Mea Culpa. Well, this means that, indeed, it's possible to write python2+3 code right now. The only problem, of course is that it's more of a puzzle rather then normal programming: identical text have radically different meaning in python2 and python3 thus it's not trival. It's much easier to program in python2 or python3 rather then in python2+3, but yes, it's probably time to start doing that.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 2:39 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 8:34 UTC (Fri) by khim (subscriber, #9252) [Link]
Strange. The fact that binary strings and unicode strings were swapped is not a problem for you? It was PITA for me when I've tried to write something usable in both python2 and python3. Usually it's possible to do but you need to be… creative.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 13:02 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
[1]I was was actually trying to make Python3 code work in 2 to test performance differences (re.compile's memoizing is slooooow up to 3.3; haven't tested 3.4 yet where it's supposed to be fixed). PyPy doesn't seem to help /enough/ either; will have to rethink some of that code.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:23 UTC (Thu) by lambda (subscriber, #40735) [Link]
People run software that is more than 5 years old all the time. Breaking that for no particularly good reason is not all that friendly.
What makes you think such software still has developers? Sometimes people write code and move on, but there are still users depending on that code.
One thing stopping people from fixing the shebang is that Python hasn't been installed at /usr/bin/python2
for the entire duration of those 5 years. In fact, Fedora only just this August updated their documentation to recommend using python2 instead of python. Other distros may not even have a python2 executable. Most have a python2.6 or python2.7, which /usr/bin/python
is symlinked to; but if you have something that's compatible back to python2.5 and want people to be able to run it with the latest Python 2 available, your only choice has been to use /usr/bin/python
in your shebang.
So no, people could not have been fixing their shebang over the past 5 years, because there was nothing to change it to. It's only after Arch unilaterally switched to Python 3 and everything broke that people realized that actually, we need to provide both a python2 and python3 and leave python pointing to python2 for at least several more years to give people time to fix their shebangs.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 7:04 UTC (Fri) by jmayer (subscriber, #595) [Link]
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 16:56 UTC (Fri) by epa (subscriber, #39769) [Link]
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 18:05 UTC (Fri) by HelloWorld (guest, #56129) [Link]
Fedora to switch to Python 3 by default
Posted Oct 28, 2013 10:50 UTC (Mon) by epa (subscriber, #39769) [Link]
Fedora to switch to Python 3 by default
Posted Oct 28, 2013 11:25 UTC (Mon) by HelloWorld (guest, #56129) [Link]
Non sequitur. You gain nothing by moving /bin/bash to /bin/bash4, except breaking all kinds of scripts that use #!/bin/bash as a shebang now. The right solution is to leave /bin/bash alone, and if an incompatible bash 5 is ever released, place it in /bin/bash5.
Sure, it's inconsistent to have the version suffix for v5 and not for v4. But I don't think that fixing what is essentially an aesthetic issue is worth breaking compatibility.
Fedora to switch to Python 3 by default
Posted Oct 28, 2013 12:21 UTC (Mon) by epa (subscriber, #39769) [Link]
can put #!/bin/bash as now.
Fedora to switch to Python 3 by default
Posted Oct 28, 2013 13:16 UTC (Mon) by HelloWorld (guest, #56129) [Link]
What's the purpose of that? Even if you make sure your script works with python2 and python3, it may still break with python4, so using a symlink to the most recent version is *never* a robust solution. The solution is really quite simple: /usr/bin/python is Python2, /usr/bin/python3 is Python3, and if you really need your script to run on either, use a simple wrapper script to pick the right interpreter. I don't think that's a common case by the way, as it leads to quite ugly code. Most projects probably use 2to3 or 3to2 rather than polyglot programming.
Fedora to switch to Python 3 by default
Posted Oct 28, 2013 14:15 UTC (Mon) by epa (subscriber, #39769) [Link]
Even if you make sure your script works with python2 and python3, it may still break with python4, so using a symlink to the most recent version is *never* a robust solution.I agree, which is why putting an explicit 'python2' or 'python3' is better. I'd use "always get the latest" only for quick single-file scripts in my personal bin/ directory where I am happy to take on the maintenance work of fixing them when a new version comes out.
Even if /usr/bin/python remains as python2, it is still useful to have an explicit /usr/bin/python2 so that people can say what they mean. If you are auditing programs on your system in preparation for an upgrade to Python 3, then if you see one with /usr/bin/python2 you know that somebody has thought about the issue, and explicitly decided that Python 2 (and not a later version) is needed.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 6:26 UTC (Fri) by tdalman (guest, #41971) [Link]
I disagree. It is a distribution problem to report upward compatibility issues with these scripts to work with their Python installation. In my eyes that's no different to upgrading the compiler version. There will always be source packages that fail to compile with a newer GCC version.
So, for me, /usr/bin/python should ALWAYS point to the distribution default version of Python. I haven't yet switched to Python 3 since there are still some issues left, but eventually I will do so and I'm looking forward to it.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 6:31 UTC (Fri) by josh (subscriber, #17465) [Link]
Fedora to switch to Python 3 by default
Posted Oct 26, 2013 8:37 UTC (Sat) by tdalman (guest, #41971) [Link]
My understanding of "fixing" things would be to make the Python programs to become portable between Python 2 and Python 3 instead of just making modifications in the #! line.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 10:21 UTC (Thu) by micka (subscriber, #38720) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 12:29 UTC (Thu) by josh (subscriber, #17465) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 10:48 UTC (Thu) by cesarb (subscriber, #6266) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 12:03 UTC (Thu) by Otus (subscriber, #67685) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 12:26 UTC (Thu) by drag (guest, #31333) [Link]
That would just make the problems you run into when there is no python 2.x all the more confusing and difficult to deal with.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 12:30 UTC (Thu) by josh (subscriber, #17465) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 14:54 UTC (Thu) by zuki (subscriber, #41808) [Link]
(Just trolling, I agree that /usr/bin/python should be 2.x for now. ;) )
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 16:03 UTC (Thu) by Otus (subscriber, #67685) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 16:11 UTC (Thu) by khim (subscriber, #9252) [Link]
There were some deliberately incompatible changes, but yes, it's usually easy to make fix python2.6-compatible and make it work with python 2.7. NOT so for python3.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:14 UTC (Thu) by zuki (subscriber, #41808) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:34 UTC (Thu) by drag (guest, #31333) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:33 UTC (Thu) by drag (guest, #31333) [Link]
The difference between 2.6 and 2.7 is not the same difference between 2 and 3
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:49 UTC (Thu) by sinuhe (guest, #68638) [Link]
PEP appears to like the idea of python pointing to python3 at some reasonable point in the future. This makes sense. When python 2.7 is no longer supported or patched by the Python community, why would new platforms include it, and therefore why should python still point to a non-existant python2? Looking at the time frame, that seems to be what Fedora is doing.
Frankly, once python2.7 is no longer supported, apps should be updated for current platforms, and the python2 version deprecated as legacy code supported on aging platforms. New systems after this time will rightly refuse to include EOL software that could present a security risk, because it uses an EOL Python.
Python2 is to K&R as Python3 is to ANSI C, or perhaps even C++. Compilers expect legacy C code to be updated. Why shouldn't Python see things the same way? Use legacy Fortan 77 or modern 90/95/2003/2008/2015? At some point you just decide to drop floppies for CDs, right?
Like Arch, some are ahead of the curve. It means that their xHTML only websites don't support Internet Explorer (well until version 9), but if that's their audience, good for them. They do some of the dirty work for us, and we learn from that going forward, and once IE catches up no one notices anymore.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 20:00 UTC (Thu) by dlang (guest, #313) [Link]
actually, most of the time they don't, and when they do require existing code to be changed, it's usually only because the prior way of doing things had not yet been standardized.
They try _really_ hard to not break existing code with new compiler version, and when they do it's usually viewed as a regression
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 20:29 UTC (Thu) by sinuhe (guest, #68638) [Link]
python3 does not interpret python2, so I suppose the C analogy doesn't work.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 14:56 UTC (Fri) by jengelh (subscriber, #33263) [Link]
Whereas python2 is expected to decay over time, C sees no such decline.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 9:55 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
The actual type has to be named _Bool because the leading underscore prefix is reserved whereas names like "bool" or "Boolean" were never reserved by previous standards and so might be (and indeed have been) used by application programmers.
So the standard provides a header <stdbool.h>. Old programs have no reason to include such a header, which is in the reserved namespace <std*.h> while new programs which want to use the standard boolean type can include it. The header typedefs the ugly but standard _Bool as the more pleasing bool
To a certain type of person this is all needless back compatibility junk. They don't believe in such junk, they are always willing to put in the extra work to stay at the bleeding edge and don't see why others won't do the same. Until they get a little older, have a little more to do beyond constantly fiddling with things to keep them working, and then it suddenly seems rather tiresome that the whim of some 19 year old should mean you've got to spend your weekend manually updating everything only for them to change their mind again next week.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 14:22 UTC (Fri) by HelloWorld (guest, #56129) [Link]
Yes, and due to the C committee's craziness about compatibility, _Bool is so useless that one has to wonder why they bothered with it at all. What's the point of having a boolean type when every operator that ought to produce a boolean (like ==, <, > etc.) produces an int instead?
I actually think that what the ISO committee did in this case is thoroughly idiotic. They should have made it so that "#include <stdbool.h>" is special-cased through some compiler magic and not only defines bool, true and false, but also changes the meaning of expressions involving these operators in the current file so that they yield a boolean. Of course one needs to deal with corner cases. What if the relevant expression is expanded from a macro that was defined in a file that doesn't have "#include <stdbool.h>"? Should the traditional or the new rules apply? And even worse, what if an expression is made up of the contents of multiple files?
/* file a */ 42 /* file b */ ... if (a == #include "a" ) { ...But dealing with this kind of craziness is the committees job. And instead of doing their jobs and giving us a bool type that is actually worthwhile, they opted for giving us a half-arsed solution that doesn't help anybody.
Bottom line: If one wants to to evolve a language in a sensible way, the ISO C committee is not the group of people one should emulate.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 17:12 UTC (Fri) by khim (subscriber, #9252) [Link]
Yes, and due to the C committee's craziness about compatibility, _Bool is so useless that one has to wonder why they bothered with it at all. What's the point of having a boolean type when every operator that ought to produce a boolean (like ==, <, > etc.) produces an int instead?
The point is the same as with any other language. Yes, operations like == produce int, but you can safely save it in _Bool
, so what's your problem? You need to do something extremely exotic with _Bool
for that difference to be noticeable.
And instead of doing their jobs and giving us a bool type that is actually worthwhile, they opted for giving us a half-arsed solution that doesn't help anybody.
You need to provide some more detailed explanation then lots of hot air and handwaving without anything substantial. Some examples where choices made by ISO hurt will be great. They have not covered one use-case (the need to support compilers without C99 support like MSVC), true, but that's not something you can fix with your crazy proposals.
So far you've only shown an example where your crazy solution is worse than committee's solution, how about something where it's better.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 18:42 UTC (Fri) by HelloWorld (guest, #56129) [Link]
The point is the same as with any other language.
In other languages the point of having a boolean type is to prevent people from doing nonsense such as testing an integer value for truth or adding boolean values. C's _Bool doesn't prevent that, so what's the point?
You need to provide some more detailed explanation then lots of hot air and handwaving without anything substantial. Some examples where choices made by ISO hurt will be great.
_Bool is useless, it complicates the language and doesn't provide the benefits that a real boolean type provides (or can you name an actual, substantial benefit?). Isn't that hurtful enough?
They have not covered one use-case (the need to support compilers without C99 support like MSVC), true
Just what are you talking about? How is anything from a new version of a programming language standard supposed to help people who are using an implementation that refuses to implement that new standard?
So far you've only shown an example where your crazy solution is worse than committee's solution, how about something where it's better.
Giving the boolean type sane semantics (i. e. disallowing "foobar" ? x : y
and true + true
) *is* better than the C99 solution. Besides, the "problem" I pointed out is pretty much only of theoretical importance since this kind of construct is clearly rare. There are two solutions:
- make the behaviour in that case implementation-defined and make the implementation issue a warning in that case
- adopt a simple rule: the meaning of the relevant operator is determined by whether the file where the token originally comes from contained the line "#include <stdbool.h>".
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 19:10 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
From the compiler level, _Bool is pretty useless. However, using _Bool (or, preferably, 'bool') as an argument type to a function is vastly better than using 'int'. It also standardizes 'true' and 'false' where there are cases of '#define TRUE 0' and '#define FALSE 1'[1] in the wild. These are enough for me to think it is worth being in the standard.
Of course, better would have been to have a 'strong' typedef (similar to Haskell's 'newtype') so that you could use the representation of some other type but disallow casting altogether. Currently, you're stuck with 'typedef struct { int x; } my_int;' instead which changes access and assignment syntax whereas 'typedef int my_int;' allows implicit conversions between the two silently.
[1]From some WTF article a few years back.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 20:27 UTC (Fri) by HelloWorld (guest, #56129) [Link]
However, using _Bool (or, preferably, 'bool') as an argument type to a function is vastly better than using 'int'How is it better than passing a bool defined as
typedef enum { false, true } bool;
?
It also standardizes 'true' and 'false' where there are cases of '#define TRUE 0' and '#define FALSE 1'[1] in the wild.In C, Truth is represented as 1, Falseness as 0, there's no doubt and no ambiguity. The fact that somebody defined nonsensical macros doesn't change that, just like the Indiana Pi Bill didn't create any doubt about the value of π.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 21:03 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Because there is now a header which does it and you don't have to have '#define BOOL_DEFINED' crap everywhere to avoid redefinition errors?
> In C, Truth is represented as [non-zero], Falseness as 0, there's no doubt and no ambiguity.
Sure, but it's not like you get warnings that '#define true 0' is fscking up your code (not that this *fixes* that, but now you can hit them with a cluebat that they're messing with standard headers).
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 22:14 UTC (Fri) by khim (subscriber, #9252) [Link]
How is it better than passing a bool defined as typedef enum { false, true } bool;
?
You can not use said enum
for bitfields and it's not interoperable with C++.
The fact that somebody defined nonsensical macros doesn't change that, just like the Indiana Pi Bill didn't create any doubt about the value of π.
No, but it's now easier to write headers which can be used in both C and C++ mode. The fact that there various BOOL
, Bool
, Boolean
, _XtBoolean
and others certainly show that such thing is wanted.
Sure, _Bool
is not something to write poems and odes, but it's still quite useful addition to the language.
Fedora to switch to Python 3 by default
Posted Oct 26, 2013 1:08 UTC (Sat) by HelloWorld (guest, #56129) [Link]
Bitfields? Seriously? Those things that nobody right in their mind uses because they can't be safely accessed concurrently and aren't portable? Besides if that's the reason _Bool is needed, they could just have allowed enums to be stored in bitfields and be done with it.
> The fact that there various BOOL, Bool, Boolean, _XtBoolean and others certainly show that such thing is wanted.
Yeah, except that _Bool can't replace those because they're for the most part a typedef for int or an enum and thus replacing them with _Bool isn't ABI-compatible.
> Sure, _Bool is not something to write poems and odes, but it's still quite useful addition to the language.
You have yet to name one advantage. No, "_Bool can only have values 0 and 1" isn't an advantage by itself.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 21:19 UTC (Fri) by khim (subscriber, #9252) [Link]
We are talking about python here, remember?
In other languages the point of having a boolean type is to prevent people from doing nonsense such as testing an integer value for truth or adding boolean values.
Interesting idea, but
$ python3
Python 3.2.3 (default, Sep 25 2013, 18:22:43)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 == True
True
>>> True + True
2
it does not work like that.
_Bool is useless, it complicates the language and doesn't provide the benefits that a real boolean type provides (or can you name an actual, substantial benefit?).
Sure. _Bool guarantees that value of the variable is either true
or false
. Just like in python or other languages. Nothing more, nothing less.
How is anything from a new version of a programming language standard supposed to help people who are using an implementation that refuses to implement that new standard?
It could not, of course, but I've only ever encountered problems with bool
/true
/false
when code was supposed to be Windows-portable (in such a case people usually introduce some kind of portability.h
which conflict when few libraries are used in a single project). In all other cases C99 bool
works at least as well as python's bool
.
Giving the boolean type sane semantics (i. e. disallowing "foobar" ? x : y and true + true) *is* better than the C99 solution.
Why would you need to disallow useful and well-defined constructs? They are allowed both C99 and python as I've pointed out above so I really fail to see your point.
Besides you called my solution "crazy" without giving any reason whatsoever, I don't see how that helps.
Well, you've managed to find reason anyway, right: it complicates the language and doesn't provide the benefits. Now you can have perfectly valid code which will suddenly become invalid if you'll include some strange .h
file. This happens, but it's definitely not something people want/need to encourage.
It's cleaner in those languages because they have a module system, but given the mess that the C preprocessor is, the above is the best I can think of and IMNSHO clearly better than what the committee actually did.
Your opinion is most definitely not humble but I'm not see how it's justified.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 22:29 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
> Your opinion is most definitely not humble but I'm not see how it's justified.
IMNSHO == "in my not so humble opinion"
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 22:32 UTC (Fri) by HelloWorld (guest, #56129) [Link]
it does not work like that.
Actually most languages got that right by now: Java, C#, Scala, F#, Haskell, Ocaml, SML. Even dynamically-typed ones like Scheme or Ruby. And while not quite strongly-typed, even in C++ the type of 1 == 1 is bool, not int.
Sure. _Bool guarantees that value of the variable is either true or false. Just like in python or other languages.
Python doesn't even have a static type system, how is it supposed to guarantee anything? Hell, Python doesn't even guarantee that True is true, True = False
being a valid statement. Oh, and by the way: int
guarantees that a variable contains either zero or non-zero, which is entirely isomorphic.
In all other cases C99 bool works at least as well as python's bool.
You mean it's just as useless?
Why would you need to disallow useful and well-defined constructs?
They may be defined, but how are they useful? They're not, they're confusing and nonsensical. Here's what I found when I googled for "C coding guidelines":
http://www.jetcafe.org/jim/c-style.html#boolean
http://users.ece.cmu.edu/~eno/coding/CCodingStandard.html#nztest
https://www.kernel.org/doc/Documentation/CodingStyle
Quote from the third:
If the C language included a strong distinction between integers and booleans then the compiler would find these mistakes for us... but it doesn't.
And let's not forget that confusing = and == would never have been an issue if it weren't for C's broken concept of boolean values. Bottom line: everybody agrees that C not having strongly-typed booleans is error-prone and useless.
Well, you've managed to find reason anyway, right: it complicates the language and doesn't provide the benefits.
Having a type-safe boolean is useful, and I'm not the only one to think that, see the above-mentioned languages and coding style documents. It's certainly more useful than _Bool, which doesn't do *anything* an integer couldn't do.
Now you can have perfectly valid code which will suddenly become invalid if you'll include some strange .h file.Are you serious? Every time you include a header you can break code because somebody
#define
d an identifier you're using. Every time you use strict;
you break legacy code. What you're saying is essentially that Perl should never have bothered with use strict;
. Sorry, you're just wrong.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 23:22 UTC (Fri) by khim (subscriber, #9252) [Link]
Actually most languages got that right by now: Java, C#, Scala, F#, Haskell, Ocaml, SML. Even dynamically-typed ones like Scheme or Ruby. And while not quite strongly-typed, even in C++ the type of 1 == 1 is bool, not int.
In C++ type of 1 == 1
may be bool
, not int
, but this is still perfectly valid C++:
bool foo(bool a, bool b) {
return a + b;
}
And this is valid, too:
int bar(float x) {
if (x)
return 42;
else
return 0;
}
Python doesn't even have a static type system, how is it supposed to guarantee anything?
With it's dynamic type system, obviously. If type of object is bool
then it's either True
or False
. And you can even create a nice syntax with decorators!
Hell, Python doesn't even guarantee that True is true, True = False being a valid statement.
That's another side of the python's coin: many constructions which use reserved words in python don't use them and thus can be broken. len = False
and range = False
are valid, too, but it does not mean they should not use len
or range
!
Oh, and by the way: int guarantees that a variable contains either zero or non-zero, which is entirely isomorphic.
Sure. And you can even go further and use double
instead of int
everywhere (as JavaScript does), but it does not mean it's good idea.
They may be defined, but how are they useful?
They are useful when you need to do certain things. Namely: check is some non-boolean variable contains zero or if you want to transform code
bool to some flag (in such a case you need to multiply bool
by int, of course) or just calculate some kind of weight (where each bool
will have one).
One may argue that it's probably not as important and safety will be preferable, but this is separate issue and in a language where you can store float
value in an int
variable (or the other way around) these look quite natural. Heck, even enum
can participate in arithmetic in C! I would be surprised to see bool
which can not be used in such a way in C—especially since C++ also allows that.
Bottom line: everybody agrees that C not having strongly-typed booleans is error-prone and useless.
Where everybody is defined as “anyone who's nick is HelloWorld”? It's error-prone, true, but you are the only one who claims that it's useless.
Every time you include a header you can break code because somebody #defined an identifier you're using.
And you can find it and #undef it.
Every time you use strict;
you break legacy code.
There are no use strict;
in C.
What you're saying is essentially that Perl should never have bothered with use strict;
.
No, what I'm saying it that use strict;
(and it's GCC's analogue -Werror
) must be implemented as capability which is entirely decoupled from all other features. You want to mix it with something else. Sorry, but this is not useful and just plain wrong.
Fedora to switch to Python 3 by default
Posted Oct 26, 2013 0:43 UTC (Sat) by HelloWorld (guest, #56129) [Link]
In C++ type of 1 == 1 may be bool, not int, but this is still perfectly valid C++:So of all the languages I mentioned you had to pick the one that clearly only allows this kind of nonsense due to having to be compatible with C, despite the fact that I explicitly pointed out that C++'s
bool
is, in fact, not strongly-typed? Congratulations on that.
With it's dynamic type system, obviously. If type of object isSo? How does that help in any way, shape or form? It doesn't prevent any errors because obvious nonsense likebool
then it's eitherTrue
orFalse
.
foo[True]
still doesn't blow up.
Sure. And you can even go further and useYeah, except that doesn't work because adouble
instead ofint
everywhere
double
is (usually) bigger than an int
and can't represent all values of a long long
because its mantissa is only 53 bits. Really, try harder.
They are useful when you need to do certain things. Namely: check is some non-boolean variable contains zero or if you want to transform code bool to some flag (in such a case you need to multiply bool by int, of course) or just calculate some kind of weight (where each bool will have one).All this can be done with trivial helper functions and is certainly not a reason to mess up the type system of the programming language. Sorry, this doesn't match my idea of a useful feature.
And you can find it and #undef it.Yeah, and if you don't like sane semantics for the
bool
type, you don't include the header. Duh.
There are no use strict; in C.So I'm proposing a
use strict;
-like feature for C and you respond by telling me that... there's no use strict;
in C? I mean, honestly?
No, what I'm saying it that use strict; (and it's GCC's analogue -Werror) must be implemented as capability which is entirely decoupled from all other features. You want to mix it with something else. Sorry, but this is not useful and just plain wrong.So you're saying that the introduction of a new boolean type and the introduction of rules as to what expressions yield values of that type should be separate? I'm sorry, you're insane.
Fedora to switch to Python 3 by default
Posted Oct 26, 2013 1:05 UTC (Sat) by HelloWorld (guest, #56129) [Link]
I actually agree with that, it would be a surprising. And in fact I'm not even saying that things should be done that way. What I'm saying is that they should either a) give the boolean type a sane semantics or b) not add it at all. They instead opted for c) add a boolean type with the same kind of idiocies that affect pretty much everything else in C's type system, thus effectively making it next-to-useless clutter. And sorry, but that's just a clusterfuck.
Fedora to switch to Python 3 by default
Posted Nov 11, 2013 11:48 UTC (Mon) by yeti-dn (guest, #46560) [Link]
Anyway, the idiotic type system of C is primarily just a representation of the raw machine types. Until processors actually operate with bools (not to be confused with bit flags inside integers), well, bool in C cannot be much more than a fancy name for int. You will not get the distinction you ask for in C. Whether it makes sense to include such thing in C, that is a question, but IMO it carries useful semantics *for the programmer*.
Fedora to switch to Python 3 by default
Posted Nov 12, 2013 8:20 UTC (Tue) by jezuch (subscriber, #52988) [Link]
The type system of C is the spirit of the 70's when programs were 1000 times simpler. I read an interview with Thompson recently in which he downplayed the problems with C basically saying "just don't make mistakes". It was kind of disappointing to see him say it, really. But in his times it was 1000 times easier not to make mistakes and he's a smart guy, so I can understand it.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 17:13 UTC (Fri) by dashesy (guest, #74652) [Link]
What is ugly, is to deal with a source code with Microsoft's idiotic "#include "StdAfx.h"" that also needs to be compiled cross platform. Beauty of C is that it does not lie to you, no magic, just following simple set of idioms.
Why <stdafx.h> or <stdbool.h> should be treated specially?
At lest <stdbool.h> is not magic, it solely relies on previously reserved names, a hack yes but fairly clever one. They were reserved for a reason after all.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 18:54 UTC (Fri) by HelloWorld (guest, #56129) [Link]
Why <stdafx.h> or <stdbool.h> should be treated specially?What other way can you think of to a) give the boolean type sane semantics (i. e.
a == a
has type bool
, not int
, if ("foobar")
is disallowed, and so is true + true
) and b) not sacrifice backward compatibility?
Well, thinking about it, a standard pragma could have done the job. But that's really just a syntax issue.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 17:21 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Note that _Bool really is boolean, if you try to store a non-boolean value into a _Bool it gets converted accordingly, whereas if you'd stuck with a traditional integer variable you'll get an integer conversion which might cause all manner of nasty surprises. For example
(_Bool) 0.5 /* is true, as a reasonable observer would expect */
(int) 0.5 /* is zero */
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 19:03 UTC (Fri) by HelloWorld (guest, #56129) [Link]
(_Bool) 0.5 /* is true, as a reasonable observer would expect */So
(_Bool) x
is the same as x == 0.0f
for float
s? Didn't your mommy tell you to never compare floating point numbers for equality? Why does this print 1?
#include <stdbool.h> #include <stdio.h> int main() { double d = 1.0; for (int i = 0; i < 10; ++i) d -= 0.1; bool b = d; printf("%d\n", b); }Having an implicit conversion from floating point numbers to booleans is nonsense, and the committee ought to know these things.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 22:29 UTC (Fri) by khim (subscriber, #9252) [Link]
Didn't your mommy tell you to never compare floating point numbers for equality?
My mommy told me to never use things if I don't understand how they work. If you know just what floats are and how to use them then I can compare them for equality just fine. If you don't know that and just replace equality tests with approximations then most likely you are just replacing one set of errors with another set of errors.
Why does this print 1?
Because you are pretending that floats are real numbers and thus are writing nonsense?
Heck floats are called float
and double
exactly to highlight that these are floating point numbers and double precision floating point numbers. If you forget for a minute that these are floating point numbers and most definitely not real numbers then you lose. It's as simple as that.
Fedora to switch to Python 3 by default
Posted Oct 26, 2013 1:21 UTC (Sat) by HelloWorld (guest, #56129) [Link]
*facepalm*.
Do I really have to explain this? Did you really think I *wasn't* aware of the fact that that loop doesn't yield a zero value, and that you have to educate me about the basics of floating-point arithmetic? Sorry, you're wrong (yet again).
My point is that having an implicit conversion from floating point values to _Bool is utter nonsense, because an equality comparison almost never makes sense for float types, because rounding errors lead to things not being zero even if they would be if one were using standard arithmetic. Thus, it's not a sensible kind of behaviour to build into a language.
Boy, I still can't believe I actually have to spell this out for you. Just do the world a favour and actually try to understand what others are trying to tell you, instead of being smug and assuming everyone else is an idiot, OK? It would make discussing with you so much less annoying...
Fedora to switch to Python 3 by default
Posted Oct 26, 2013 8:20 UTC (Sat) by niner (subscriber, #26151) [Link]
if (update_foo())
foo = new_foo_value();
if (foo != 0)
...
Please tell me why exactly the equality comparison doesn't make sense here.
Fedora to switch to Python 3 by default
Posted Oct 26, 2013 10:53 UTC (Sat) by hummassa (guest, #307) [Link]
Fedora to switch to Python 3 by default
Posted Oct 28, 2013 11:01 UTC (Mon) by jezuch (subscriber, #52988) [Link]
In my definition of "reasonable", which is admittedly Java-inspired (or Java-infected, if you will), this would be considered a compilation error. A reasonable observer, in this world, would expect _Bool to be incompatible with all the other primitive types so that the "conversion" is forced to be explicit:
if (value != 0.0)
instead of:
if (value)
...which I suppose C people consider a wonderful shortcut but I find confusing. Also note that the explicit version exposes the comparison of float values, which is frowned upon.
Fedora to switch to Python 3 by default
Posted Oct 28, 2013 15:20 UTC (Mon) by nybble41 (subscriber, #55106) [Link]
If you did that it wouldn't be C any more. The idea is to maintain backward compatibility, so you at least need to keep the automatic conversion between the types previously used for boolean values (generally "int", but could be any integer type) and the new _Bool type to avoid breaking existing code. The same goes for pointer-to-_Bool conversions. I suspect that the semantics for float-to-_Bool conversions were defined as they are for similar compatibility reasons, though I would hope that the use of floating-point types for this purpose was not widespread.
If we were starting over, I would definitely make integers and booleans distinct types with no automatic conversion. Given a dedicated boolean type, there is no reason to define zero as false and all other numbers as true. However, I would leave optional/nullable values implicitly convertible to boolean, including pointers (ptr != NULL) and possibly floating-point values (!isnan(f)).
Fedora to switch to Python 3 by default
Posted Oct 28, 2013 23:44 UTC (Mon) by Wol (subscriber, #4433) [Link]
(_Bool) (int) float
and would be surprised that 0.5 evaluates as true!
Mind you, as someone who is quite happy to use a language where the easiest way to multiply an integer by 10 is to string-concatenate a zero on the end... :-)
But the fact remains, "reasonable" and "obvious" is rarely reasonable and obvious.
Cheers,
Wol
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 22:58 UTC (Thu) by HelloWorld (guest, #56129) [Link]
No, it doesn't.
> When python 2.7 is no longer supported or patched by the Python community, why would new platforms include it
The answer is obvious: to run legacy Python2 programs.
> and therefore why should python still point to a non-existant python2?
Aside from the fact that there's no need for python to point anywhere, the answer is again obvious: so that users of said legacy Python2 programs get a decent error message instead of some weird nonsense resulting from trying to run a Python2 program on a Python3 interpreter. And, as josh already pointed out, there's simply no reason to not have the Python3 interpreter be called python3.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 23:15 UTC (Thu) by cesarb (subscriber, #6266) [Link]
Is the Perl 5 interpreter called perl5? No, it's not:
$ ls -l /usr/bin/perl5
ls: cannot access /usr/bin/perl5: No such file or directory
Once Python 2 does not exist anymore, there's simply no reason to not have the Python 3 interpreter take over the /usr/bin/python name.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 23:24 UTC (Thu) by josh (subscriber, #17465) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 23:32 UTC (Thu) by mchapman (subscriber, #66589) [Link]
> Nobody is seriously proposing to call the break-the-world Perl 6 /usr/bin/perl.
The intention is that that will Just Work:Migration is important. A Perl 6 interpreter, if invoked as "perl", will assume that it is being fed Perl 5 code unless the code starts with a "class" or "module" keyword, or you specifically tell it you're running Perl 6 code in some other way [...]
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 7:45 UTC (Fri) by niner (subscriber, #26151) [Link]
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 12:57 UTC (Fri) by HelloWorld (guest, #56129) [Link]
http://perldoc.perl.org/perl5100delta.html#Incompatible-C...
http://perldoc.perl.org/perl5120delta.html#Potentially-In...
http://perldoc.perl.org/perl5140delta.html#Incompatible-C...
http://perldoc.perl.org/perl5160delta.html#Incompatible-C...
http://perldoc.perl.org/perl5180delta.html#Incompatible-C...
And this isn't just about rarely-used functionality or some obscure corner case. They declared the ~~ operator (and thus also the given/when construct) experimental six years after its introduction.
I'm not saying that there aren't good reasons for these changes, but Perl's track record is anything but perfect when it comes to backward compatibility.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 14:58 UTC (Fri) by niner (subscriber, #26151) [Link]
The smartmatch operator may be the exception to this rule. But anyone who's ever tried to actually use smartmatch knows why. It was a bad idea from the start. Unfortunatley one that made it into a stable release. I'm quite sure the Perl porters would love to just rip it out and forget it but instead they marked it experimental as a warning to users and are trying to figure out how to fix it.
From my experience, Perl is in this regard still much better than the mentioned PHP or Python. The latter did it not only with the step to Python 3, but also before when they ripped out restricted python and we had to stay with Python 2.4 to keep our Zope servers running.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 19:59 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]
The flipside of maintaining backward compatibility is that it introduces quirks that can easily trip up unsuspecting users, e.g. ' being a valid package separator even though :: is now the standard. Those things don't necessarily crop up that much, but that just makes them even more confusing when they do. At some point a clean break can be preferable to maintaining the extra syntactic and coding complexity needed to preserve backward compatibility.
I would also expect for Python and Perl to have different standards about this. The whole "Swiss Army Chainsaw"/TIMTOWTDI attitude of Perl shows that it favors increased function- or even syntactic sugar- over simplicity. In contrast, Python leans heavily in favor of simplicity and orthogonality. It shouldn't come as a surprise that Python has been more willing to discard compatibility in the service of simplicity, while Perl has gone the opposite way. It reflects their basic character as programming languages.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 13:01 UTC (Fri) by HelloWorld (guest, #56129) [Link]
This is utterly irrelevant and obviously just meant to distract from the fact that you aren't able to name one rational reason for the Python3 interpreter to be called python instead of python3.
> Once Python 2 does not exist anymore ...
This isn't going to happen any time soon. And even if it were to happen, why bother? Then you'd have to change the shebangs of all kinds of Python3 scripts to point to python instead of python3. It's just useless churn.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 10:15 UTC (Fri) by chithanh (guest, #52801) [Link]
> No, it doesn't.
Not sure what is your antecedent of "it" here.
PEP 0394 does recommend pointing /usr/bin/python to python2 for the time being, but they do describe under which conditions the recommendation will change in favor of python3.
My opinion is that the switch makes sense as soon as scripts which support both version 2 and 3 start to lose features or performance when run inside a python2 environment.
Like Arch, Gentoo also runs python3 by default when invoking /usr/bin/python. But that is configurable by the administrator. All distribution installed python software will continue to run unimpressed no matter which version /usr/bin/python points to.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 14:56 UTC (Fri) by HelloWorld (guest, #56129) [Link]
I disagree. The fact that many scripts still weren't updated to have their shebangs point to /usr/bin/python2 instead of /usr/bin/python indicates that they've been working fine without those performance improvements or new features for a long time, while on the other hand we know that lots of scripts *are* going to break when you try to run them with python3. I also think that codebases that actually run on both python2 and python3 are a rather rare phenomenon. Most projects either just use one specific version or use 2to3 or 3to2.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 13:39 UTC (Fri) by cjwatson (subscriber, #7322) [Link]
I'm not bashing Python; I happen to think the trade-off here is worth making in a lot of cases. But C and other compiled languages just aren't a good target for comparison here.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 17:04 UTC (Fri) by khim (subscriber, #9252) [Link]
I think you've gotten your argument backwards.
In the event of an incompatible change in the syntax of a compiled language, you only have to care about it when you need to change it; in the case of an old locally-built program that may well be as close to never as makes no odds. In the event of an incompatible change in the syntax of an interpreted (or compiled-on-the-fly or whatever) language such as Python, you have to care about it the next time you need to run the program.
Right. Which means that it's significantly more important for python to be backward-compatible!
The analogy with compiled languages such as C is not a good one.
…in an ideal world where C language regularly introduces incompatible changes and python provides rock-solid backward compatibility, yes, this will be a bad analogy. In our world, on other hand, it's more than just good, it's perfect. You've just explained why python's compatibility needs to be almost perfect, certainly it must better then C compatibility at least, but what do we have… regular breakage? Pathetic.
Python does many things right, but it breaks perfectly valid scripts regularly which is certainly no fun.
I'm not bashing Python; I happen to think the trade-off here is worth making in a lot of cases.
Well, you've just explained why python must do better than C (which goes to great pain to make sure programs which were correct 20 years ago are still correct again) so now would be a good time to explain why what python is doing is justified.
I can understand python3: it's kinda-sorta-like C++ where incompatible changes are introduced. Ok. But what about other cases where python broke compatibility?
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 19:00 UTC (Fri) by cjwatson (subscriber, #7322) [Link]
My final point was that I use Python anyway because despite the train of compatibility breaks, it's still a very useful language with an immensely useful set of available libraries, and the compatibility breaks have made the language better if you choose to ignore the transition headaches. That doesn't mean that (as somebody who's done rather a lot of 2-to-3 porting) I don't sometimes wish there were fewer such headaches.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 22:19 UTC (Fri) by khim (subscriber, #9252) [Link]
Ah, sorry. There was proper complaint, too, I was sure you are replaying to that. Silly me. Yes, looks like we are in violent agreement, LOL.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 15:02 UTC (Thu) by jond (subscriber, #37669) [Link]
It should not use the alternatives system, because they are not alternatives for one another. Alternatives is for things which are compatible with one another: e.g., /bin/sh implementations being compatible super-sets of Bourne shell.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 16:14 UTC (Thu) by khim (subscriber, #9252) [Link]
Since python scripts which are compatible with both python2 and python3 exist and only these scripts are supposed to use /usr/bin/python… yes, python2 and python3 must be handled with alternatives system.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 17:13 UTC (Thu) by proski (subscriber, #104) [Link]
I think using /usr/bin/python would imply that the program is compatible with all versions of Python. But what if it works with Python 2 and 3, but not with the future Python 4?
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 17:16 UTC (Thu) by khim (subscriber, #9252) [Link]
Then there will be another PEP and, perhaps, another decision.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 18:05 UTC (Thu) by proski (subscriber, #104) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:20 UTC (Thu) by khim (subscriber, #9252) [Link]
This is probably good idea, but unfortunately it can only help with hypothetical future python3 to python4 transition. Plus it's not clear exactly why it's better to introduce some complex scheme rather then to stick with current “/usr/bin/python is for python2+3 scripts” and “/usr/bin/pythonX is for pythonX scripts (where X ≥ 2)”.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:35 UTC (Thu) by drag (guest, #31333) [Link]
Yes. Here it is:
#! /usr/bin/env python
Indicates the program should use Python 2.7
#! /usr/bin/env python3
Indicates that the program should use Python3.
I don't see why it needs to be any more complicated then that.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:52 UTC (Thu) by proski (subscriber, #104) [Link]
It is more complicated. Some programs support Python 2.4-2.7. Some support Python 2.7-3.3. Some program may support 3.0-3.2 and it's not known if it supports 3.3 because it wasn't tested with it. How would you indicate that?
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 22:29 UTC (Thu) by mgedmin (subscriber, #34497) [Link]
Programming Language :: Python :: 2.6
Programming Language :: Python :: 2.7
Programming Language :: Python :: 3.2
Programming Language :: Python :: 3.3
Programming Language :: Python :: Implementation :: CPython
Programming Language :: Python :: Implementation :: PyPy
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 19:54 UTC (Thu) by khim (subscriber, #9252) [Link]
I don't see why it needs to be any more complicated then that.
Because your non-solution for non-problem breaks killall and does not give you full solution anyway? Some systems out there only have /usr/bin/env
and some other only have /bin/env
and while these are rare and so can probably be ignored the same can be said about systems where “/usr/bin/env python
” exist and is not “/usr/bin/python
”.
Frankly I don't see what's this hoopla is all about. Arch made a bad choice and must fix it, end of story. There are nothing to discuss further.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 19:33 UTC (Fri) by drag (guest, #31333) [Link]
Except for system scripts I have found that it's generally not a good idea to specify a absolute path to python for applications and utilities. If somebody has their environment setup so that a different path is used by the python interpreter then it's usually done that way for good reason.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 22:44 UTC (Fri) by khim (subscriber, #9252) [Link]
Well besides the fact that I think you missed the point...
I think you've missed the point. Your use of /usr/bin/env
breaks down in some cases and my use of /usr/bin/python
also breaks down in some cases. It means that there are no single “perfect” solution. We much pick one. In my experience killall
is valuable and the ability to pick some random version of python is not, your experience may be different, but before we can discuss these experiences we need to find our just why do you need these tricks.
If somebody has their environment setup so that a different path is used by the python interpreter then it's usually done that way for good reason.
My experience is the exact opposite: if one does have /usr/bin/env
and a system with shebang support and does not have usable python under /usr/bin/python
name then one does something really strange (for example tries to run package which is designed to support modern Linux on some ten-year old Linux) and creates more trouble then it's really worth.
I certainly can not stop such people, but I don't see why their needs and wants must override my needs and wants.
Sometimes one gets the urge to use it to sidestep some other problem using such tricks (for example to sidestep the fact that Mac OS X Leopard uses python 2.5 and not python 2.6), but in such cases usually it's better to just wait and use only python 2.5 features till support of that six years old OS version can be dropped. You can use this trick to do some tricks but two incompatible pythons under the same name eventually lead to problems.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 18:56 UTC (Thu) by dlang (guest, #313) [Link]
Many of these programs and scripts are not actively maintained, they were written, they do the job, and there's no need to spend more time on them. In many cases the people who wrote them have moved on to other jobs.
Causing such things to break when someone does a system upgrade is exactly the type of ABI instability that gets people like Linus upset.
This is why /usr/bin/python should not be changed to the new, incompatible Python3 for the forseable future.
Scripts and programs have a _very_ long lifetime, people are still running Cobal programs written in the '70s (last updated for Y2K)
Just because you have the source it doesn't make it acceptable to change the system in a way that the program needs to be changed.
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 20:01 UTC (Thu) by proski (subscriber, #104) [Link]
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 20:08 UTC (Thu) by dlang (guest, #313) [Link]
How should the system or the programmer figure this out?
Fedora to switch to Python 3 by default
Posted Oct 24, 2013 20:30 UTC (Thu) by proski (subscriber, #104) [Link]
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 0:19 UTC (Fri) by k8to (guest, #15413) [Link]
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 0:39 UTC (Fri) by k8to (guest, #15413) [Link]
I think python probably could have handled this better, eg by providing a marker or differentiator that if a program is written for 3 to be automatically handed off. Opportunity possibly missed.
Fedora to switch to Python 3 by default
Posted Oct 25, 2013 10:45 UTC (Fri) by Otus (subscriber, #67685) [Link]
What's wrong with simply using either python or python3 depending on whether you want 2.x or 3.x? If some future "pythonN" supports one of them, it can simply offer an alternative for python and/or python3 as well.
If your program supports both 2 and 3, you should have a wrapper that tries to run it with the preferred version (probably 3) and falls back to the other if it's not found. That's the "pythonic" way in general: instead of testing for a version (or class) you try if what you need is supported and fall back to something else if not.
alternatives
Posted Oct 25, 2013 18:45 UTC (Fri) by justincormack (subscriber, #70439) [Link]
DNF = Did Not Finish?
Posted Oct 24, 2013 23:43 UTC (Thu) by imunsie (guest, #68550) [Link]
Not trying to troll - that's just the first thing that entered my head when I saw the DNF name, I'm sure the name has nothing to do with that :-/
DNF = Did Not Finish?
Posted Oct 24, 2013 23:58 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
DNF = Did Not Finish?
Posted Oct 25, 2013 13:30 UTC (Fri) by sanjoy (guest, #5026) [Link]
Fedora to switch to Python 3 by default
Posted Oct 26, 2013 10:58 UTC (Sat) by betanews (guest, #93606) [Link]
See:
http://www.omgubuntu.co.uk/2013/10/fixing-amazon-prime-st...
Fedora to switch to Python 3 by default
Posted Oct 28, 2013 4:58 UTC (Mon) by krakensden (guest, #72039) [Link]
Fedora to switch to Python 3 by default
Posted Oct 28, 2013 7:50 UTC (Mon) by salimma (subscriber, #34460) [Link]
Fedora to switch to Python 3 by default
Posted Oct 28, 2013 9:50 UTC (Mon) by mjblenner (subscriber, #53463) [Link]
Bleeding edge distros can use the same set of patches to keep HAL working if they want...