Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Tue, Feb 18, 2014, at 03:54 PM, Barry Warsaw wrote: > On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: > > >Am 17.02.2014 00:25, schrieb Larry Hastings: > >> And my local branch will remain private until 3.4.0 final ships! > > > >sorry, but this is so wrong. Is there *any* reason why to keep this branch > >private? > > IMO, no. read-only for !larry sure, but not private. I've always published my releasing repo on hg.p.o as releasing/2.7.X. I wasn't aware people actually used it; it's mostly a nice backup for when I rm rf * things in anger... :) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Preview of 3.4 rc2 (so far) is up
The URL has changed slightly. Please go here: http://midwinter.com/~larry/3.4.status/ You'll notice two things: * a "merge.status.html" file, which shows you the list of revisions that I've cherry-picked after rc1. * a tarball containing the resulting source tree. As I cherry-pick more revisions, I'll add new tarballs and update the merge status. For the record, I've passed over only two requested cherry-pick revisions so far: http://bugs.python.org/issue20646 select and kqueue round the timeout aways from zero http://bugs.python.org/issue20679 improve Enum subclass behavior I haven't rejected them, I just want more review. If you'd like to see these changes get cherry-picked for 3.4.0 rc2 (and final) please review them or convince someone else to contribute a review. Only thirty cherry-picked revisions so far. Gosh, you're making my life easy, guys, //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Sounds like you aren't exactly a DVCS fan... On Tue, Feb 18, 2014 at 8:46 PM, Guido van Rossum wrote: > I do think there's one legitimate concern -- someone might pull a diff > from Larry's branch and then accidentally push it back to the public repo, > and then Larry would be in trouble if he was planning to rebase that diff. > (The joys of DVCS -- we never had this problem in the cvs or svn days...) > > Publishing tarballs would prevent this and still let people test the exact > code Larry is assembling on their favorite obscure platform. > > > On Tue, Feb 18, 2014 at 3:54 PM, Barry Warsaw wrote: > >> On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: >> >> >Am 17.02.2014 00:25, schrieb Larry Hastings: >> >> And my local branch will remain private until 3.4.0 final ships! >> > >> >sorry, but this is so wrong. Is there *any* reason why to keep this >> branch >> >private? >> >> IMO, no. read-only for !larry sure, but not private. >> >> -Barry >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum (python.org/~guido) > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...) Publishing tarballs would prevent this and still let people test the exact code Larry is assembling on their favorite obscure platform. On Tue, Feb 18, 2014 at 3:54 PM, Barry Warsaw wrote: > On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: > > >Am 17.02.2014 00:25, schrieb Larry Hastings: > >> And my local branch will remain private until 3.4.0 final ships! > > > >sorry, but this is so wrong. Is there *any* reason why to keep this branch > >private? > > IMO, no. read-only for !larry sure, but not private. > > -Barry > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: >Am 17.02.2014 00:25, schrieb Larry Hastings: >> And my local branch will remain private until 3.4.0 final ships! > >sorry, but this is so wrong. Is there *any* reason why to keep this branch >private? IMO, no. read-only for !larry sure, but not private. -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/18/2014 04:19 PM, Matthias Klose wrote: Am 19.02.2014 01:05, schrieb Larry Hastings: On 02/18/2014 03:56 PM, Matthias Klose wrote: Am 19.02.2014 00:46, schrieb Larry Hastings: On 02/18/2014 03:38 PM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier. Is there *any* reason to make this branch public before 3.4.0 final? - Python is an open source project. Why do we need to hide development for a month or more? - Not even four eyes looking at the code seems to be odd. You can make mistakes too. This seems to be a social or a technical problem. I assume making this branch available read-only would address your concerns? Does hg allow this? And if not, why not create this branch in the upstream repository, and tell people not to commit to it? Why shouldn't such a social restriction work? Seems to work well for other projects. When you are release manager for Python, you may institute this policy if you like. Right now, I have enough to do as it is. is it too much to ask for a public mirror / tarball / something of this branch? This seems to be a minor effort compared to the clinic work that went into 3.4. Why do you need this? What is your use case? //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 01:05, schrieb Larry Hastings: > On 02/18/2014 03:56 PM, Matthias Klose wrote: >> Am 19.02.2014 00:46, schrieb Larry Hastings: >>> On 02/18/2014 03:38 PM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: > And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? >>> Yes. It ensures that nobody can check something into it against my wishes. >>> Also, in the event that I cherry-pick revisions out-of-order, it allows me >>> to >>> rebase, making merging easier. >>> >>> Is there *any* reason to make this branch public before 3.4.0 final? >> - Python is an open source project. Why do we need to hide >> development for a month or more? >> >> - Not even four eyes looking at the code seems to be odd. You >> can make mistakes too. >> >> This seems to be a social or a technical problem. I assume making this >> branch >> available read-only would address your concerns? Does hg allow this? And if >> not, why not create this branch in the upstream repository, and tell people >> not >> to commit to it? Why shouldn't such a social restriction work? Seems to >> work >> well for other projects. > > When you are release manager for Python, you may institute this policy if you > like. Right now, I have enough to do as it is. is it too much to ask for a public mirror / tarball / something of this branch? This seems to be a minor effort compared to the clinic work that went into 3.4. Matthias ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/18/2014 03:54 PM, Victor Stinner wrote: 2014-02-19 0:46 GMT+01:00 Larry Hastings : Is there *any* reason to make this branch public before 3.4.0 final? I'm a little bit worried by the fact that buildbots will not test it. "fact"? http://docs.python.org/devguide/buildbots.html#custom-builders Would it be insane to use default as the next RC2? Yes. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/18/2014 03:56 PM, Matthias Klose wrote: Am 19.02.2014 00:46, schrieb Larry Hastings: On 02/18/2014 03:38 PM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier. Is there *any* reason to make this branch public before 3.4.0 final? - Python is an open source project. Why do we need to hide development for a month or more? - Not even four eyes looking at the code seems to be odd. You can make mistakes too. This seems to be a social or a technical problem. I assume making this branch available read-only would address your concerns? Does hg allow this? And if not, why not create this branch in the upstream repository, and tell people not to commit to it? Why shouldn't such a social restriction work? Seems to work well for other projects. When you are release manager for Python, you may institute this policy if you like. Right now, I have enough to do as it is. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
2014-02-17 0:25 GMT+01:00 Larry Hastings : > You might think that anything you check in to the "default" branch in Python > trunk will go into 3.4.0 rc2, and after that ships, checkins would go into > 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to > "default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0 final > will by default go into 3.4.1. Only fixes that I cherry-pick into my local > branch will go into 3.4.0 rc2 and final. And my local branch will remain > private until 3.4.0 final ships! I'm a little bit lost with the Misc/NEWS file. The current title is still "What's New in Python 3.4.0 release candidate 2?". Should we start a new "Python 3.4.1" section? Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 00:46, schrieb Larry Hastings: > On 02/18/2014 03:38 PM, Matthias Klose wrote: >> Am 17.02.2014 00:25, schrieb Larry Hastings: >>> And my local branch will remain private until 3.4.0 final ships! >> sorry, but this is so wrong. Is there *any* reason why to keep this branch >> private? > > Yes. It ensures that nobody can check something into it against my wishes. > Also, in the event that I cherry-pick revisions out-of-order, it allows me to > rebase, making merging easier. > > Is there *any* reason to make this branch public before 3.4.0 final? - Python is an open source project. Why do we need to hide development for a month or more? - Not even four eyes looking at the code seems to be odd. You can make mistakes too. This seems to be a social or a technical problem. I assume making this branch available read-only would address your concerns? Does hg allow this? And if not, why not create this branch in the upstream repository, and tell people not to commit to it? Why shouldn't such a social restriction work? Seems to work well for other projects. Matthias ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
2014-02-19 0:46 GMT+01:00 Larry Hastings : > Is there *any* reason to make this branch public before 3.4.0 final? I'm a little bit worried by the fact that buildbots will not test it. Cherry-picking many patches is complex. It's safe if you have a very short list of changes. Would it be insane to use default as the next RC2? It looks like there are too many changes between RC1 and RC2. Another release candidate is maybe needed. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/18/2014 03:38 PM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier. Is there *any* reason to make this branch public before 3.4.0 final? //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 17.02.2014 00:25, schrieb Larry Hastings: > And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? Matthias ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 2/18/2014 1:27 PM, Greg Ewing wrote: M.-A. Lemburg wrote: The alternative would be adding a new singleton to mean mostly the same thing as None, but having the property of comparing less than all other objects and then recommend its use in the DB-API for Python 3 applications... Which I think would be a *really bad* idea, because there would then no longer be One Obvious Way to represent and process null values. E.g. you would no longer be able to write 'value is None' and trust it to work on all kinds of null value you're likely to get. Of course you couldn't... value is None would never work full Null values, only for None, like it should. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 19 Feb 2014 07:26, "Paul Moore" wrote: > > On 18 February 2014 21:17, Greg Ewing wrote: > > What I'd *really* like to be able to write is: > > > >sort(invoices, keyattr = 'duedate', none = 'first') > > Which is of course a pretty trivial utility function to write. But I > understand your point - these "trivial helpers" add up over time into > a bit of a burden. But fixing that (if anyone feels it's worth doing > so) can be handled many ways, and changing the semantics of None is > far from the simplest or most obvious. So perhaps the real answer is for someone to write a sorting helper module and put it on PyPI. Things like sort_byattr (implicitly uses attrgetter), sort_byitem (implicitly uses itemgetter), a flag argument defaulting to "none_first=True", SortsLow and SortsHigh singletons, etc. Those don't need to be builtins, but collating them into a clean helper API would not only allow that module to be used directly, but also act as a reference for anyone wanting to implement the behaviour themselves. (I know, I know, we're way into python-ideas territory - it's just that so much if the thread *was* on topic for python-dev, it seems relatively pointless to split this iteration of the discussion. The *next* thread about it should definitely be on python-ideas, though) Cheers, Nick. > > Pul > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
On 02/18/2014 11:53 AM, Serhiy Storchaka wrote: 18.02.14 21:20, Guido van Rossum написав(ла): I'm confused. AFAICT enums are pickled by value too. What am I missing? Are we confused about terminology or about behavior? (I'm just guessing that the pickling happens by value because I don't see the string AF_INET.) Pickling was not even working two weeks ago. [1] For the record, pickling worked just fine for protocols 2 and 3, and 4 didn't exist at the time. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
On 02/18/2014 11:37 AM, Guido van Rossum wrote: Well, I'm against that. Given the lack of a tidal wave of support for the idea, I'll let it die with that. Still, many thanks to Serhiy for greatly improving the way pickling is implemented for Enums, even using values. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
M.-A. Lemburg wrote: The alternative would be adding a new singleton to mean mostly the same thing as None, but having the property of comparing less than all other objects and then recommend its use in the DB-API for Python 3 applications... Which I think would be a *really bad* idea, because there would then no longer be One Obvious Way to represent and process null values. E.g. you would no longer be able to write 'value is None' and trust it to work on all kinds of null value you're likely to get. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 18 February 2014 21:17, Greg Ewing wrote: > What I'd *really* like to be able to write is: > >sort(invoices, keyattr = 'duedate', none = 'first') Which is of course a pretty trivial utility function to write. But I understand your point - these "trivial helpers" add up over time into a bit of a burden. But fixing that (if anyone feels it's worth doing so) can be handled many ways, and changing the semantics of None is far from the simplest or most obvious. Pul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
Georg Brandl wrote: Seeing how you need a key function in any case for this sort to work, it's only the "or mindate" added, which I can't recognize as "ridiculous amount of boilerplate". Well, I don't much like having to construct a key function in the first place for something as common as sorting on an attribute. Also, in the particular case of dates, there's the annoying fact that the datetime module doesn't provide any kind of null object that can be compared with datetimes, so you have to make a fake one yourself. All of these small annoyances add up to what is, for me, a fairly big annoyance. What I'd *really* like to be able to write is: sort(invoices, keyattr = 'duedate', none = 'first') -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On Wed, Feb 19, 2014 at 3:10 AM, Mark Lawrence wrote: > Sorry if this has already been suggested, but why not introduce a new > singleton to make the database people happier if not happy? To avoid > confusion call it dbnull? A reasonable compromise or complete cobblers? :) That would be a major change to the DB API. Possibly the best solution, though. Start off by having the default be to return None (as now) and have a flag that can be set "please return sys.dbnull instead" (does dbnull belong in sys?), and let that settle for a few years. Recommend that all applications explicitly set the flag, either to True or to False. Then eventually, with the full deprecation warnings, change the default to True. (Or maybe make it an error to not set it.) Then, after another long round of deprecations, drop the None behaviour from the spec altogether. But even in its early steps, that could solve the problem. Anyone who wants to sort a list of tuples that came from the database can simply set the flag (assuming their back-end supports that flag) and happily use dbnull. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Treating tokenize.Untokenizer as private
I am working through the multiple bugs afflicting tokenize.untokenize, which is described in the tokenize doc and has an even longer docstring. While the function could be implemented as one 70-line function, it happens to be implemented as a 4-line wrapper for a completely undocumented (Untokenizer class with 4 methods. (It is unmentioned in the doc and there are currently no docstrings.) I view the class as a private implementation detail and would like to treat it as such, and perhaps even rename it _Untokenizer to make that clear. The issue arises in #9974. It appears that a fix may require the addition of an instance attribute or .add_whitespace parameter. If there is objection to treating the whole class as private, I would at least like to treat add_whitespace as the private helper that it is. There is no reason to call it directly except for testing. Otherwise, it could just as well have been left inline at the one call site. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
Brett Cannon writes: >> Yes, I see your point, but please also consider that None is >> used in database applications as natural mapping for SQL NULL >> and in other data processing applications to mean "no value". >> > > Fine, but not everything uses a database. =) Right, and even if everything did, as already said not all databases share the same default ordering rules, or have the same syntax to impose one specific direction. But more to the point, no database I know let you say "WHERE somecolumn < 1" and expect that when "somecolumn IS NULL" the condition is true... Paradoxically, if Python goes back to give a meaning to "None < 1", it would have an even more different semantic than most database engines out there. ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 2/18/2014 7:57 AM, Brett Cannon wrote: Yes, I see your point, but please also consider that None is used in database applications as natural mapping for SQL NULL and in other data processing applications to mean "no value". Fine, but not everything uses a database. =) Python None and SQL NULL share some properties, which makes it seem like it is a natural mapping. However, they also have some differing properties, which means that really it isn't a natural mapping. A big mistake in most Python/SQL marriages is the failure to implement an SQL NULL class that fully matches SQL semantics. Of course it is easier to map SQL NULL to Python None and then complain about the semantic differences. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
Well, I still think it should be done by value. On Tue, Feb 18, 2014 at 11:53 AM, Serhiy Storchaka wrote: > 18.02.14 21:20, Guido van Rossum написав(ла): > > I'm confused. AFAICT enums are pickled by value too. What am I missing? >> Are we confused about terminology or about behavior? (I'm just guessing >> that the pickling happens by value because I don't see the string >> AF_INET.) >> > > Pickling was not even working two weeks ago. [1] > > [1] http://bugs.python.org/issue20534 > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
18.02.14 21:20, Guido van Rossum написав(ла): I'm confused. AFAICT enums are pickled by value too. What am I missing? Are we confused about terminology or about behavior? (I'm just guessing that the pickling happens by value because I don't see the string AF_INET.) Pickling was not even working two weeks ago. [1] [1] http://bugs.python.org/issue20534 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
On 02/18/2014 11:20 AM, Guido van Rossum wrote: I'm confused. AFAICT enums are pickled by value too. What am I missing? Are we confused about terminology or about behavior? (I'm just guessing that the pickling happens by value because I don't see the string AF_INET.) There's an open issue [1] to switch to pickling by name. -- ~Ethan~ [1] http://bugs.python.org/issue20653 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
18.02.14 20:16, Ethan Furman написав(ла): This conversation wasn't in the PEP, but as I recall we decided to go with value instead of name for json because the receiving end may not be running Python. Is having json do it one way and pickle another a problem? We decided to go with value instead of name for JSON because JSON doesn't support enums, but supports integers and strings, and because enums are comparable with they values, but not with they names. >>> json.loads(json.dumps(socket.AF_INET)) == socket.AF_INET True We simply had no other choice. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
Well, I'm against that. On Tue, Feb 18, 2014 at 11:26 AM, Ethan Furman wrote: > On 02/18/2014 11:20 AM, Guido van Rossum wrote: > >> >> I'm confused. AFAICT enums are pickled by value too. What am I missing? >> Are we confused about terminology or about >> behavior? (I'm just guessing that the pickling happens by value because I >> don't see the string AF_INET.) >> > > There's an open issue [1] to switch to pickling by name. > > -- > ~Ethan~ > > [1] http://bugs.python.org/issue20653 > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
I'm confused. AFAICT enums are pickled by value too. What am I missing? Are we confused about terminology or about behavior? (I'm just guessing that the pickling happens by value because I don't see the string AF_INET.) $ python3 Python 3.4.0rc1+ (default:2ba583191550, Feb 11 2014, 16:05:24) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import socket, pickle, json, pickletools >>> socket.AF_INET >>> pickle.dumps(socket.AF_INET) b'\x80\x03csocket\nAddressFamily\nq\x00K\x02\x85q\x01Rq\x02.' >>> json.dumps(socket.AF_INET) '2' >>> pickletools.dis(pickle.dumps(socket.AF_INET)) 0: \x80 PROTO 3 2: cGLOBAL 'socket AddressFamily' 24: qBINPUT 0 26: KBININT12 28: \x85 TUPLE1 29: qBINPUT 1 31: RREDUCE 32: qBINPUT 2 34: .STOP highest protocol among opcodes = 2 >>> On Tue, Feb 18, 2014 at 10:16 AM, Ethan Furman wrote: > On 02/18/2014 10:05 AM, Guido van Rossum wrote: > >> Hm. But there's an implementation that has made it unscathed through >> several betas and an RC. AFAICT that beta pickles >> enums by value. And I happen to think that that is the better choice (but >> I don't have time to explain this gut feeling >> until after 3.4 has been released). >> > > This conversation wasn't in the PEP, but as I recall we decided to go with > value instead of name for json because the receiving end may not be running > Python. > > Is having json do it one way and pickle another a problem? > > -- > ~Ethan~ > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
18.02.14 19:20, Ethan Furman написав(ла): It seems to me what we really need is either a Null singleton to represent a data point with no known value but that can still be sorted, or have every data type able to represent a no-value state (datetime, I'm looking at you!). A Never singleton? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
On 02/18/2014 10:05 AM, Guido van Rossum wrote: Hm. But there's an implementation that has made it unscathed through several betas and an RC. AFAICT that beta pickles enums by value. And I happen to think that that is the better choice (but I don't have time to explain this gut feeling until after 3.4 has been released). This conversation wasn't in the PEP, but as I recall we decided to go with value instead of name for json because the receiving end may not be running Python. Is having json do it one way and pickle another a problem? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
18.02.14 19:11, Ethan Furman написав(ла): There is one more wrinkle to pickling by name (it's actually still there in pickle by value, just more obvious in pickle by name) -- aliases. It seems to me the most common scenario to having a name represent different values on different systems is when on system A they are different, but on system B they are the same: System A: class SystemEnum(Enum): value1 = 1 value2 = 2 System B: class SystemEnum(Enum): value1 = 1 value2 = 1 If you're on system B there is no way to pickle (by name or value) value2 such that we get value2 back on system A. The only way I know of to make that work would be to dispense with identity comparison, use the normal == comparison, and have aliases actually be separate objects (we could still use singletons, but it would be one per name instead of the current one per value, and it would also be an implementation detail). Thoughts? There are aliases and aliases. If there are modern name and deprecated name, then it should be one object referred by different names on all systems. If there are different entities with accidentally equal values, then they should be different objects. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
Hm. But there's an implementation that has made it unscathed through several betas and an RC. AFAICT that beta pickles enums by value. And I happen to think that that is the better choice (but I don't have time to explain this gut feeling until after 3.4 has been released). On Tue, Feb 18, 2014 at 10:01 AM, Ethan Furman wrote: > On 02/18/2014 09:47 AM, Guido van Rossum wrote: > >> >> I'm confused. Hasn't this all been decided by the PEP long ago? >> > > The PEP only mentions pickling briefly, as in "the normal rules apply". > How pickling occurs is an implementation detail, and it turns out that > pickling by name is more robust. > > Serhiy, as part of his argument for using the _name_ instead of the > _value_ for pickling, brought up the point that different systems could > have different values for the same name. If true in practice (and I > believe it is) this raises the issue of aliases, which currently *cannot* > be pickled by name because there is no distinct object for the alias. If > you ask for Color['alias_for_red'] you'll get Color.red instead. > > Using identity comparison was part of the PEP. > > I guess the question is which is more important? Identity comparison or > this (probably) rare use-case? If we stick with identity I'm not aware of > any work-around for pickling enum members that are aliases on one system, > but distinct on another. > > I've been talking about pickling specifically, but this applies to any > serialization method. > > > -- > ~Ethan~ > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
On Tue, 18 Feb 2014 10:01:42 -0800 Ethan Furman wrote: > > I guess the question is which is more important? Identity comparison or this > (probably) rare use-case? If we stick > with identity I'm not aware of any work-around for pickling enum members that > are aliases on one system, but distinct on > another. I don't think identity comparison is important. Enum values are supposed to act like values, not full-blown objects. OTOH, the "pickled aliases may end up different on other systems" issue is sufficiently fringy that we may simply paper over it. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
On 02/18/2014 09:47 AM, Guido van Rossum wrote: I'm confused. Hasn't this all been decided by the PEP long ago? The PEP only mentions pickling briefly, as in "the normal rules apply". How pickling occurs is an implementation detail, and it turns out that pickling by name is more robust. Serhiy, as part of his argument for using the _name_ instead of the _value_ for pickling, brought up the point that different systems could have different values for the same name. If true in practice (and I believe it is) this raises the issue of aliases, which currently *cannot* be pickled by name because there is no distinct object for the alias. If you ask for Color['alias_for_red'] you'll get Color.red instead. Using identity comparison was part of the PEP. I guess the question is which is more important? Identity comparison or this (probably) rare use-case? If we stick with identity I'm not aware of any work-around for pickling enum members that are aliases on one system, but distinct on another. I've been talking about pickling specifically, but this applies to any serialization method. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
I'm confused. Hasn't this all been decided by the PEP long ago? On Tue, Feb 18, 2014 at 9:11 AM, Ethan Furman wrote: > On 02/15/2014 11:01 AM, Serhiy Storchaka wrote: > >> How Enum items should be pickled, by value or by name? >> >> I think that Enum will be used to collect system-depending constants, so >> the value of AddressFamily.AF_UNIX can be 1 on >> one platform and 2 on other. If pickle enums by value, then pickled >> AddressFamily.AF_INET on on platform can be >> unpickled as AddressFamily.AF_UNIX on other platform. This looks weird >> and contrary to the nature of enums. >> > > There is one more wrinkle to pickling by name (it's actually still there > in pickle by value, just more obvious in pickle by name) -- aliases. It > seems to me the most common scenario to having a name represent different > values on different systems is when on system A they are different, but on > system B they are the same: > > System A: > > class SystemEnum(Enum): > value1 = 1 > value2 = 2 > > System B: > > class SystemEnum(Enum): > value1 = 1 > value2 = 1 > > If you're on system B there is no way to pickle (by name or value) value2 > such that we get value2 back on system A. The only way I know of to make > that work would be to dispense with identity comparison, use the normal == > comparison, and have aliases actually be separate objects (we could still > use singletons, but it would be one per name instead of the current one per > value, and it would also be an implementation detail). > > Thoughts? > > -- > ~Ethan~ > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
On 02/15/2014 11:01 AM, Serhiy Storchaka wrote: How Enum items should be pickled, by value or by name? I think that Enum will be used to collect system-depending constants, so the value of AddressFamily.AF_UNIX can be 1 on one platform and 2 on other. If pickle enums by value, then pickled AddressFamily.AF_INET on on platform can be unpickled as AddressFamily.AF_UNIX on other platform. This looks weird and contrary to the nature of enums. There is one more wrinkle to pickling by name (it's actually still there in pickle by value, just more obvious in pickle by name) -- aliases. It seems to me the most common scenario to having a name represent different values on different systems is when on system A they are different, but on system B they are the same: System A: class SystemEnum(Enum): value1 = 1 value2 = 2 System B: class SystemEnum(Enum): value1 = 1 value2 = 1 If you're on system B there is no way to pickle (by name or value) value2 such that we get value2 back on system A. The only way I know of to make that work would be to dispense with identity comparison, use the normal == comparison, and have aliases actually be separate objects (we could still use singletons, but it would be one per name instead of the current one per value, and it would also be an implementation detail). Thoughts? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 02/18/2014 02:08 AM, M.-A. Lemburg wrote: This is not garbage data, it's just missing information for a particular field [...] I think the basic problem is that None was over-used (or even mis-used?) to the point where 3.0 had to make a choice to bring consistency back to the language. It seems to me what we really need is either a Null singleton to represent a data point with no known value but that can still be sorted, or have every data type able to represent a no-value state (datetime, I'm looking at you!). -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 18/02/2014 15:45, Terry Reedy wrote: On 2/18/2014 12:11 AM, Greg Ewing wrote: Nobody is asking for a return to the arbitrary-but- [in]consistent mess of Python 2, only to bring back *one* special case, i.e. None comparing less than everything else. For a < None, that is only the fallback rule if a does not handle the comparison. The result is a mess, including a possible inconsistency between direct comparison and cmp. See my previous posts. 'Bringing back' what was or an improved version would be a semantic change that could break code and would require a two-version deprecation period. Sorry if this has already been suggested, but why not introduce a new singleton to make the database people happier if not happy? To avoid confusion call it dbnull? A reasonable compromise or complete cobblers? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 18 February 2014 15:53, Terry Reedy wrote:
> On 2/18/2014 2:35 AM, Greg Ewing wrote:
>
>>results = sorted(invoices, key=attrgetter('duedate'), none='first')
>
> I think this is the best idea on the thread. As a pure enhancement, it could
> be added in 3.5. The only tricky part of the implementation is maintaining
> stability of the sort. The obvious implementation of swapping Nones with
> objects at one end would break that. Instead, a scan listing the positions
> of Nones should be followed by a series of block moves of objects (pointers)
> between the Nones. It would still be O(n).
This only works if the list entry is a simple None. If the None is
embedded in e.g. a tuple then it would fail:
>>> (1, 2, 3) < (1, 2, None)
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: int() < NoneType()
Oscar
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 2/18/2014 12:32 AM, Greg Ewing wrote: Terry Reedy wrote: To make None a true bottom object, the rich comparison methods would have to special-case None as either argument before looking at the __rc__ special methods of either. I don't think it would be necessary to go that far. It is if you want None to be 'a true bottom object'. If you think something less is sufficient, or even desirable, then yes, ... It would be sufficient to put the special case *after* giving both operations a chance to handle the operation via the type slots. That would more or less reproduce the 2.x situation, except that a conflict between < and cmp would not be possible. Well-behaved objects generally wouldn't go out of their way to defeat that, but they could do so if necessary, e.g. to create a Bottom() that compares less than None. Although once None becomes usable as a bottom in most cases, there shouldn't be much need for people to introduce their own bottoms. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
I'll reply inline, but tl;dr: I'm with Tim on this. On Tue, Feb 18, 2014 at 5:08 AM, M.-A. Lemburg wrote: > On 18.02.2014 05:25, Tim Peters wrote: > > [M.-A. Lemburg] > >> Now, the choice to have None compare less than all other objects > >> may have been arbitrary, but IMO it was a good, consistent and > >> useful choice. > > > > Possibly useful for some apps, sure. Not for my apps. For example, > > when I initialize an object attribute to None in Python 3, I _expect_ > > I'll get an exception if I try to use that attribute in most contexts. > > It makes no more sense to ask whether that attribute is, say, less > > than 3, than it does to add 3 to it. The exception is most useful > > then. More often than not, it was annoying to me that Python 2 > > _didn't_ whine about trying to compare None. > > Yes, I see your point, but please also consider that None is > used in database applications as natural mapping for SQL NULL > and in other data processing applications to mean "no value". > Fine, but not everything uses a database. =) > > This is not garbage data, it's just missing information for > a particular field and you can still happily process such data > without having the information for these fields as values > (indeed in some cases, the information whether a field has a > value or not is important, e.g. for data validations and to cross > check entries). > > You do still want to be able to sort such data, but as it stands, > Python 3 doesn't allow you to, without adding an extra layer > of protection against None values deep inside the structures > you're sorting. > Which in my opinion is fine as the boilerplate is typically minimal. No one has said any solution is going to take even 10 lines of code to work around this. > > >> So why not bring it back > > > > A huge barrier is (or should be) that Python 3 is over 5 years old > > now. Fiddling with the semantics of basic builtin types was possible > > - and even welcome - 6 years ago. Now they really shouldn't be > > touched in the absence of a critical bug, or a wholly > > backward-compatible (with Python 3) addition. > > > >> and perhaps this time in a way that actually does work consistently for > >> all Python objects by implementing the tp_richcompare slot on > >> PyNoneType objects and documenting it ?! > > > > Something to suggest for Python 4, in which case I'll only be -0 ;-) > > Well, like I said: we'd be making something work again that has > worked before and only remove a failure case. The barrier for > entry should be lower in such a case. > But this is still a semantic change. Python 3 users could very well be relying on the fact that comparing against None raises an exception as a way to detect when erroneous data has leaked into some data structure. What is being suggested is a semantic change to a core data type within a major release. We waited until Python 3 to make comparisons against disparate types illegal for a reason. > > This is similar to bringing back the u"" literals. Those used > to cause a SyntaxError and now they no longer do. > I don't think they are similar at all. Allowing the u prefix on strings basically made something that was a typo or accidental hold-over from Python 2 just not throw an error. There was no semantic shift in what u meant in Python 3.2 vs. 3.3 which could break some code. Basically we just made some syntactic fluff not upset the parser which in no way changed the semantic meaning of the string literal it was attached to. Making None sort a specific way is beyond just adding some syntactic fluff. > > Even better: we have a chance to properly document the behavior > this time around and make it consistent all the way. > > The alternative would be adding a new singleton to mean mostly > the same thing as None, but having the property of comparing > less than all other objects and then recommend its use in the > DB-API for Python 3 applications... which would break a lot > of existing DB-API based apps of course... which is the reason > why I'm advocating for changing None instead :-) > Or DB-API stuff needs to be updated to use some None-that-sorts singleton if they want to use None to represent NULL but sort in a specific way. As Tim has said, 3.0 has been out for five years, so we are talking about breaking code for this over what can be viewed as a minor inconvenience for DB code. The current situation is not insurmountable in any way for those that want None to sort. I should also mention I view None as representing nothing, which includes not sharing a type with anything, which is why it can't be compared against any other type in Python 3. But this suggestion of having None sort as the lowest thing no matter what in way says None is implicitly every type when it comes to sorting which breaks that mental model of None representing the void of information by being void of value, but everything when it comes to its type for comparison purposes. _
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 2/18/2014 2:35 AM, Greg Ewing wrote:
results = sorted(invoices, key=attrgetter('duedate'), none='first')
I think this is the best idea on the thread. As a pure enhancement, it
could be added in 3.5. The only tricky part of the implementation is
maintaining stability of the sort. The obvious implementation of
swapping Nones with objects at one end would break that. Instead, a scan
listing the positions of Nones should be followed by a series of block
moves of objects (pointers) between the Nones. It would still be O(n).
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 2/18/2014 12:11 AM, Greg Ewing wrote: Nobody is asking for a return to the arbitrary-but- [in]consistent mess of Python 2, only to bring back *one* special case, i.e. None comparing less than everything else. For a < None, that is only the fallback rule if a does not handle the comparison. The result is a mess, including a possible inconsistency between direct comparison and cmp. See my previous posts. 'Bringing back' what was or an improved version would be a semantic change that could break code and would require a two-version deprecation period. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 2014-02-18 14:11, MRAB wrote: On 2014-02-18 13:48, Serhiy Storchaka wrote: 18.02.14 10:10, Paul Moore написав(ла): Or alternatively, a "default on None" function - Oracle SQL calls this nvl, so I will too: def nvl(x, dflt): return dflt if x is None else x results = sorted(invoices, key=lambda x: nvl(x.duedate, datetime(MINYEAR,1,1)) Or, as was proposed above: results = sorted(invoices, key=lambda x: (x.duedate is not None, x.duedate)) That makes me wonder. Why is: None < None unorderable and not False but: (None, ) < (None, ) orderable? tuple's rich comparison uses PyObject_RichCompareBool(x, y, Py_EQ) to find the first pair of items that is unequal. Then it will test the order of any remaining elements. http://hg.python.org/cpython/file/79e5bb0d9b8e/Objects/tupleobject.c#l591 PyObject_RichCompareBool(x, y, Py_EQ) treats identical objects as equal. http://hg.python.org/cpython/file/79e5bb0d9b8e/Objects/object.c#l716 -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 2014-02-18 13:48, Serhiy Storchaka wrote: 18.02.14 10:10, Paul Moore написав(ла): Or alternatively, a "default on None" function - Oracle SQL calls this nvl, so I will too: def nvl(x, dflt): return dflt if x is None else x results = sorted(invoices, key=lambda x: nvl(x.duedate, datetime(MINYEAR,1,1)) Or, as was proposed above: results = sorted(invoices, key=lambda x: (x.duedate is not None, x.duedate)) That makes me wonder. Why is: None < None unorderable and not False but: (None, ) < (None, ) orderable? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
18.02.14 10:10, Paul Moore написав(ла): Or alternatively, a "default on None" function - Oracle SQL calls this nvl, so I will too: def nvl(x, dflt): return dflt if x is None else x results = sorted(invoices, key=lambda x: nvl(x.duedate, datetime(MINYEAR,1,1)) Or, as was proposed above: results = sorted(invoices, key=lambda x: (x.duedate is not None, x.duedate)) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 18.02.2014 05:25, Tim Peters wrote: > [M.-A. Lemburg] >> Now, the choice to have None compare less than all other objects >> may have been arbitrary, but IMO it was a good, consistent and >> useful choice. > > Possibly useful for some apps, sure. Not for my apps. For example, > when I initialize an object attribute to None in Python 3, I _expect_ > I'll get an exception if I try to use that attribute in most contexts. > It makes no more sense to ask whether that attribute is, say, less > than 3, than it does to add 3 to it. The exception is most useful > then. More often than not, it was annoying to me that Python 2 > _didn't_ whine about trying to compare None. Yes, I see your point, but please also consider that None is used in database applications as natural mapping for SQL NULL and in other data processing applications to mean "no value". This is not garbage data, it's just missing information for a particular field and you can still happily process such data without having the information for these fields as values (indeed in some cases, the information whether a field has a value or not is important, e.g. for data validations and to cross check entries). You do still want to be able to sort such data, but as it stands, Python 3 doesn't allow you to, without adding an extra layer of protection against None values deep inside the structures you're sorting. >> So why not bring it back > > A huge barrier is (or should be) that Python 3 is over 5 years old > now. Fiddling with the semantics of basic builtin types was possible > - and even welcome - 6 years ago. Now they really shouldn't be > touched in the absence of a critical bug, or a wholly > backward-compatible (with Python 3) addition. > >> and perhaps this time in a way that actually does work consistently for >> all Python objects by implementing the tp_richcompare slot on >> PyNoneType objects and documenting it ?! > > Something to suggest for Python 4, in which case I'll only be -0 ;-) Well, like I said: we'd be making something work again that has worked before and only remove a failure case. The barrier for entry should be lower in such a case. This is similar to bringing back the u"" literals. Those used to cause a SyntaxError and now they no longer do. Even better: we have a chance to properly document the behavior this time around and make it consistent all the way. The alternative would be adding a new singleton to mean mostly the same thing as None, but having the property of comparing less than all other objects and then recommend its use in the DB-API for Python 3 applications... which would break a lot of existing DB-API based apps of course... which is the reason why I'm advocating for changing None instead :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 18 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53 : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
Am 18.02.2014 08:35, schrieb Greg Ewing: > Tim Peters wrote: >> >> [Greg Ewing] >> >>>often >>>one wants to sort a collection of objects having >>>keys that can take on null values. >> >> Perhaps that's often true of your code, but it's never been true of mine. > > It's fairly common in accounting circles. I have a > collection of invoices, each of which can have a due > date specified, but doesn't have to. I want to sort > the invoices by due date. It's not particularly > important whether the missing dates sort first or > last, but it *is* important that the sort *not blow > up*. > > Dates seem to be a particularly irksome case. Here's > one suggestion from StackOverflow for dealing with > the problem: > > import datetime > mindate = datetime.date(datetime.MINYEAR, 1, 1) > > def getaccountingdate(x): > return x['accountingdate'] or mindate > > results = sorted(data, key=getaccountingdate) > > That's a ridiculous amount of boilerplate for doing > something that ought to be straightforward. Seeing how you need a key function in any case for this sort to work, it's only the "or mindate" added, which I can't recognize as "ridiculous amount of boilerplate". Much more so since you can put the key function in a shared module and import it from there anywhere you need it. Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On Tue, Feb 18, 2014 at 8:35 AM, Greg Ewing wrote:
> If you don't want to touch comparison in general,
> how about an option to sort()?
>
> results = sorted(invoices, key=attrgetter('duedate'), none='first')
I think this is a much better option.
//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Close #20656: Fix select.select() on OpenBSD 64-bit
Hi, 2014-02-18 6:19 GMT+01:00 Zachary Ware : > On Mon, Feb 17, 2014 at 6:36 PM, victor.stinner > wrote: >> http://hg.python.org/cpython/rev/79ccf36b0fd0 >> changeset: 89239:79ccf36b0fd0 >> user:Victor Stinner >> date:Tue Feb 18 01:35:40 2014 +0100 >> summary: >> Close #20656: Fix select.select() on OpenBSD 64-bit >> >> files: >> Modules/selectmodule.c | 22 -- >> 1 files changed, 12 insertions(+), 10 deletions(-) > > This changeset caused a compile warning on 32-bit Windows: > > ..\Modules\selectmodule.c(238): warning C4244: '=' : conversion from > 'time_t' to 'long', possible loss of data > [P:\ath\to\cpython\PCbuild\select.vcxproj] Ah yes, I didn't remember why I wrote the downcast initially. You're right, it is still neeed (on 64-bit Windows). I restored it: --- user:Victor Stinner date:Tue Feb 18 09:30:33 2014 +0100 files: Modules/selectmodule.c description: Issue #20656: Restore explicit downcast in select_select(). Cast from time_t (64 bit) to long (32 bit). It should fix a compiler warning. --- Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
On 18 February 2014 07:35, Greg Ewing wrote:
> If you don't want to touch comparison in general,
> how about an option to sort()?
>
> results = sorted(invoices, key=attrgetter('duedate'), none='first')
Or alternatively, a "default on None" function - Oracle SQL calls this
nvl, so I will too:
def nvl(x, dflt):
return dflt if x is None else x
results = sorted(invoices, key=lambda x: nvl(x.duedate, datetime(MINYEAR,1,1))
Admittedly the key function is starting to get complex, but I find
that key functions often do - they are the one big area where Python
uses a lot of functional-style constructs. The existence of
itemgetter/attrgetter are a testament to this fact.
PS isn't this python-ideas territory by now?
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
