|
|
Subscribe / Log in / New account

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]

I'm very glad to see that they're not planning to point /usr/bin/python to Python 3; that's a huge problem for third-party software. There's nothing wrong with continuing to call Python 3 /usr/bin/python3 for all eternity, and leaving /usr/bin/python for Python 2.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 10:08 UTC (Thu) by euske (subscriber, #9300) [Link]

Very much agreed. I hated when that happened in Arch Linux.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 13:51 UTC (Thu) by jonnor (guest, #76768) [Link]

If Fedora and others chose the policy of python==Python2, I hope (as an Arch Linux user and AUR contributor) that Arch reverses its current behavior and adopts the same.
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]

The Arch switch led to http://www.python.org/dev/peps/pep-0394/ which Fedora follows. Arch should reverse this mistake. It is not a problem to switch to Python 3 by default but /usr/bin/python should always point to Python 2 to avoid breaking scripts.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 15:48 UTC (Thu) by epa (subscriber, #39769) [Link]

That PEP does say
in 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]

> It is not a problem to switch to Python 3 by default but /usr/bin/python should always point to Python 2 to avoid breaking scripts.

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]

No. Sorry. Arch didn't do everything right. The arch change broke many third party scripts that weren't under the purview of distributions and shoudn't have been done. Directly from the PEP

"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]

Could you please remind how long ago Python3 was released? 5 years ago? And since that time developers knew that python3 is not compatible to v2. And during this 5 year period developers were not able to make theirs source v2/v3 compatible or at least fix shebang? Do you think that further procrastination and keeping v2 default will make the situation better?

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]

Like it or not, Python 2 is going to be around for a very very long time. Python scripts are written not merely by developers but also system administrators who cannot make incompatible changes unless all their systems are capable of running Python 3 and there is a compelling reason to make the change. 5 years is merely a blip.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 18:36 UTC (Thu) by anatolik (subscriber, #73797) [Link]

So we get to that false dilemma again "I do not want to change anything on my server that is why I am against other people change their software".

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]

It doesn't have to be a all or nothing proposition. That is not a difficult concept to understand. /usr/bin/python pointing to Python 3 in Arch is against the recommendations of the upstream project and was never coordinated with upstream. It introduces unnecessary incompatibilities and breakages that could have been easily avoided. By all means, push for more projects to adopt Python3 but leave /usr/bin/python alone for the time being.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 19:01 UTC (Thu) by anatolik (subscriber, #73797) [Link]

> Arch is against the recommendations of the upstream project

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]

They broke user scripts. The fact that they didn't technically break the PEP isn't the major issue. If they had coordinated with upstream about the change, the PEP wouldn't even have been necessary. It is not too late to revert the change either. They really should do it.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 19:22 UTC (Thu) by anatolik (subscriber, #73797) [Link]

> They broke user scripts.
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]

"Arch developers made a huge effort on making sure all the packages work with Python3. And were active at fixing all the incompatibilities."

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]

>> They broke user scripts.

>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]

So don't use Arch. Isn't this why we have 300 distributions of the same thing, so we have choice? Your problem with this isn't the choice, it's the fact that you are a afraid the Arch policy could become contagious.

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]

You may or may not be aware, but the term "like this" implies of course that I'm not talking directly about python but incidents similar in nature where the install location of standard programs changed.

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]

I don't think Lucid Lynx (Ubuntu 10.04) really matters for new development. Support means fixing bugs in old software rather than bringing new software. OK, maybe developers of some server software still wants to target Lucid Lynx, but it should not apply to other kinds of software.

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]

Lucid *has* Python 2.6: http://packages.ubuntu.com/lucid/python2.6

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]

The main problems I usually run into are print-as-function (addressed by __future__) and metaclasses where the Python3 way of doing it is a syntax error in Python2 (and the Python2 way doesn't work in Python3). Granted, metaclasses aren't popular in scripts, but sometimes you run across them :/ . The rest are fairly easy to fix IME (wrap map() and filter() in list() or tuple() calls usually).

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]

Personally, no. These are things I've hit in uzbl scripts[1] and stuff at work. I do remember hitting the bytes/Unicode thing a few times but it was mainly just parameter changes on str.decode and the like.

[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 26, 2013 5:53 UTC (Sat) by salimma (subscriber, #34460) [Link]

I'd highly recommend using the six (2*3) library to handle the language differences

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]

Postings like this remind me what I like about lwn: Adding missing facts to the discussion, not just opinion.

Fedora to switch to Python 3 by default

Posted Oct 25, 2013 16:56 UTC (Fri) by epa (subscriber, #39769) [Link]

Next task, introduce symlinks for perl5, bash4, etc etc...

Fedora to switch to Python 3 by default

Posted Oct 25, 2013 18:05 UTC (Fri) by HelloWorld (guest, #56129) [Link]

When somebody tries to justify their own opinion by pointing at what others do, you know they've run out of rational arguments.

Fedora to switch to Python 3 by default

Posted Oct 28, 2013 10:50 UTC (Mon) by epa (subscriber, #39769) [Link]

I don't know if you understood what I wrote. Perl 6 is not compatible with perl 5, so it cannot be installed as /usr/bin/perl without breaking existing programs; better to make sure /usr/bin/perl5 exists now. Similarly, if a shell script requires bash features then beginning with #!/bin/sh is problematic, because /bin/sh on some distributions (Debian) may be a simple POSIX shell rather than bash. I can't say whether a future version of bash will break compatibility with existing scripts, but it's fairly certain that if it does, it will carry a new major version number. So making /bin/bash4 would be a wise step. This is not a issue specific to Python.

Fedora to switch to Python 3 by default

Posted Oct 28, 2013 11:25 UTC (Mon) by HelloWorld (guest, #56129) [Link]

> I can't say whether a future version of bash will break compatibility with existing scripts, but it's fairly certain that if it does, it will carry a new major version number. So making /bin/bash4 would be a wise step.
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]

No, I don't suggest removing /bin/bash, but adding /bin/bash4 in addition. Then those who are cautious (or who know of planned changes in bash 5 which will break their script) can put explicit #!/bin/bash4. Those who just want to get the latest bash version installed on the system, whatever it may be,
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]

> Those who just want to get the latest bash version installed on the system, whatever it may be, can put #!/bin/bash as now.
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]

> It is not a problem to switch to Python 3 by default but /usr/bin/python should always point to Python 2 to avoid breaking scripts.

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]

The distribution can go through the pain of fixing every script it ships, but that doesn't fix all the third-party software and local scripts that expect /usr/bin/python to point to python 2. And "fixing" those would break them on distros where /usr/bin/python *does* point to python 2.

Fedora to switch to Python 3 by default

Posted Oct 26, 2013 8:37 UTC (Sat) by tdalman (guest, #41971) [Link]

> And "fixing" those would break them on distros where /usr/bin/python *does* point to python 2.

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]

Shouldn't that be /usr/bin/python2 ?

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 12:29 UTC (Thu) by josh (subscriber, #17465) [Link]

With 20/20 hindsight, perhaps it should have been, but it wasn't. /usr/bin/python == Python 2, /usr/bin/python3 == Python 3.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 10:48 UTC (Thu) by cesarb (subscriber, #6266) [Link]

What about when there is no python2 (like on a minimal install or livecd)? /usr/bin/python should point to python3 in that case. I.e., it should use the alternatives mechanism, with python2 having a higher priority.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 12:03 UTC (Thu) by Otus (subscriber, #67685) [Link]

In that case it would be better to make /usr/bin/python a stub that tells you pthon2 is not installed and maybe offers to install it. If you make it point to python3 under any circumstances, someone is going to write a program that relies on that fact and breaks when python2 is installed.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 12:26 UTC (Thu) by drag (guest, #31333) [Link]

> /usr/bin/python should point to python3 in that case.

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]

No, /usr/bin/python should *never* point to Python 3, because then a script written for Python 2 with #!/usr/bin/python will break, and worse yet people will write scripts with #!/usr/bin/python and expect them to run with Python 3.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 14:54 UTC (Thu) by zuki (subscriber, #41808) [Link]

No, /usr/bin/python should *never* point to Python 2.7, because then a script written for Python 2.6 might break. Nevermind! No, /usr/bin/python should *never* point to Python 2.x, because then a script written for Python 1.5 might break, and worse yet people will write scripts with #!/usr/bin/python and expect them to run with Python 1.4.

(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]

If a script written for 2.6 breaks with 2.7 that's a bug in python.

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]

It's just a question of degree: the changes between 2.5 and 2.7 are smaller than between 2.7 and 3.3, but not incomparably so.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 19:34 UTC (Thu) by drag (guest, #31333) [Link]

And the degree of difference makes all the difference in the world.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 19:33 UTC (Thu) by drag (guest, #31333) [Link]

> No, /usr/bin/python should *never* point to Python 2.7, because then a script written for Python 2.6 might break

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]

>/usr/bin/python should *never* point to Python 3, because then a script written for Python 2 with #!/usr/bin/python will break

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]

> Compilers expect legacy C code to be updated

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]

Fair enough. The Fortan analogy is probably better. How about C to C++?
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]

>How about C to C++?

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]

Right, to get just a glimpse at how hard ISO C is willing to work for compatibility, check out modern C's boolean type.

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:

  1. make the behaviour in that case implementation-defined and make the implementation issue a warning in that case
  2. 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>".
Besides you called my solution "crazy" without giving any reason whatsoever, I don't see how that helps. This kind of hack is an established way of introducing new language features, witness for example Python's from __future__ import division or Perl's use strict. 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.

Fedora to switch to Python 3 by default

Posted Oct 25, 2013 19:10 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> _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?

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]

> How is it better than passing a bool defined as typedef enum { false, true } bool;?

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]

> You can not use said enum for bitfields and it's not interoperable with C++.
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]

> > IMNSHO
> 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 #defined 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 is bool then it's either True or False.
So? How does that help in any way, shape or form? It doesn't prevent any errors because obvious nonsense like foo[True] still doesn't blow up.
Sure. And you can even go further and use double instead of int everywhere
Yeah, except that doesn't work because a 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]

> 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.
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]

You seem to like to word idiotic a lot...

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]

> Anyway, the idiotic type system of C is primarily just a representation of the raw machine types.

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]

Oh no please no magic include line.
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]

All of these operators have their range restricted to values of true (1) or false (0) so they already seem boolean to me. What's your actual concern?

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 floats? 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]

> Because you are pretending that floats are real numbers and thus are writing nonsense?
*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]

float foo = 0;
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]

Because new_foo_value() can return a zero value that is different than ((float) 0)?

Fedora to switch to Python 3 by default

Posted Oct 28, 2013 11:01 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> (_Bool) 0.5 /* is true, as a reasonable observer would expect */

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]

> 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 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]

Except that some "reasonable" observers (who actually understand the internals of compilers etc) might expect the compiler to do

(_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]

> PEP appears to like the idea of python pointing to python3 at some reasonable point in the future. This makes sense.
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]

> And, as josh already pointed out, there's simply no reason to not have the Python3 interpreter be called python3.

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]

Perl is the perfect example, though. Nobody is seriously proposing to call the break-the-world Perl 6 /usr/bin/perl.

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]

And that's one of the things I really love about Perl. It works and it keeps working. Backwards incompatible changes in PHP 5.4 give us a great excuse to finally get rid of the last bit of PHP code we have and move it all to Perl where upgrades simply never keep old code from working. We improve code according to our development priorities and schedules, not because Perl Porters (the core developers) decide to move on.

Fedora to switch to Python 3 by default

Posted Oct 25, 2013 12:57 UTC (Fri) by HelloWorld (guest, #56129) [Link]

You must be joking.

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]

I can only speak from 15 years of experience as professional Perl developer. We never had something break due to an upgrade of Perl. Yes, of course there still are incompatible changes. There have to be because for example Unicode 6.1 simply contains such changes compared to 6.0. But most of the incompatabilities really are about obscure corner cases and rearely used features.

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]

> Is the Perl 5 interpreter called perl5? No, it's not:
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]

>> PEP appears to like the idea of python pointing to python3 at some reasonable point in the future. This makes sense.
> 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]

> 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.
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]

The analogy with compiled languages such as C is not a good one. 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.

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]

On the contrary; you have interpreted my argument backwards. The comment I was replying to argued that it was fine for Python to break compatibility because compiled languages do that too from time to time; I pointed out that that was a bad analogy because compatibility breaks in interpreted languages bite harder and sooner than those in compiled languages. As far as I can tell, you are vigorously agreeing with me.

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]

> I.e., it should use the alternatives mechanism, with python2 having a higher priority.

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]

There should be a standard way for the program to indicate which versions of Python it's supposed to run on, before the whole situation gets too messy. Then the python executable could decide if it's close enough to run the program. A wrapper could be written to select the best python executable for the program.

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]

> There should be a standard way for the program to indicate which versions of Python it's supposed to run on

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]

PyPI classifiers:

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]

Well besides the fact that I think you missed the point...

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]

well, at the time the programs were written they were compatible with all versions of Python. The people who wrote the programs had no way of knowing that Python would make changes to the language in the future that would make their programs not work.

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]

We would not have been in that situation if there was a requirement to indicate the target version of Python when those scripts were written. Python developers clearly intended to change Python and introduce major incompatibilities problems. Python is not C and not bash, it's not just an implementation of a standard with optional enhancements. Python developers should have thought of mandatory versioning long ago. But since they didn't, it should be fixed now to avoid more mess in the future.

Fedora to switch to Python 3 by default

Posted Oct 24, 2013 20:08 UTC (Thu) by dlang (guest, #313) [Link]

Ok, exactly what future versions of Python is a script that you are writing today compatible with?

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]

The programmer should write the compatible versions of Python at the time of writing, obviously. The python wrapper executable could incorporate some logic for choosing the best interpreter installed on the system. The python interpreters could refuse the script, print a warning or require a special command line option to run the script.

Fedora to switch to Python 3 by default

Posted Oct 25, 2013 0:19 UTC (Fri) by k8to (guest, #15413) [Link]

You're just defining another additional incompatible python runtime environment in which the scripts also won't work.

Fedora to switch to Python 3 by default

Posted Oct 25, 2013 0:39 UTC (Fri) by k8to (guest, #15413) [Link]

Well, on re-read, your middle sentence tries to allow them to work, but I think this approach would not really work in practice. The languages are similar enough, and the approaches to handle 2/3 compatability are varied enough that correctly determining which to use in a automated way is not very reasonable.

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]

> The python wrapper executable could incorporate some logic for choosing the best interpreter installed on the system.

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]

Actually the alternatives system has wider uses (or perhaps is used incorrectly), eg lua5.1 and lua5.2 are available as alternatives for lua in Debian but are only partly compatible.

DNF = Did Not Finish?

Posted Oct 24, 2013 23:43 UTC (Thu) by imunsie (guest, #68550) [Link]

Wait, why would they switch to a package manager named after the fact that they *Did Not Finish* it? Or is that a reference to the fact they they Did Not Finish porting all the Python 2 libraries and code to Python 3?

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]

It is an experimental fork of Yum and will eventually just replace the current yum and cease to exist as a separate project. So the name is pretty apt.

DNF = Did Not Finish?

Posted Oct 25, 2013 13:30 UTC (Fri) by sanjoy (guest, #5026) [Link]

You have an aptitude for apt puns.

Fedora to switch to Python 3 by default

Posted Oct 26, 2013 10:58 UTC (Sat) by betanews (guest, #93606) [Link]

Linux folks just have too much time to break stuff.

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]

that's been broken for years in Fedora...

Fedora to switch to Python 3 by default

Posted Oct 28, 2013 7:50 UTC (Mon) by salimma (subscriber, #34460) [Link]

Or rather, Ubuntu keeping HAL available for too long despite its deprecated status lets Adobe off the hook and screw up things for people who use more leading-edge distributions...

Fedora to switch to Python 3 by default

Posted Oct 28, 2013 9:50 UTC (Mon) by mjblenner (subscriber, #53463) [Link]

Adobe isn't going to update their linux plugin, except for security bugs. And Ubuntu isn't keeping HAL alive, it's been removed from the archives. This is just a ppa.

Bleeding edge distros can use the same set of patches to keep HAL working if they want...


Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds