On 18 February 2014 07:35, Greg Ewing greg.ew...@canterbury.ac.nz 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
Hi,
2014-02-18 6:19 GMT+01:00 Zachary Ware zachary.w...@gmail.com:
On Mon, Feb 17, 2014 at 6:36 PM, victor.stinner
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/79ccf36b0fd0
changeset: 89239:79ccf36b0fd0
user:Victor Stinner victor.stin...@gmail.com
date:
On Tue, Feb 18, 2014 at 8:35 AM, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
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
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:
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,
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,
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.
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
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 m...@egenix.com 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
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
On 18 February 2014 15:53, Terry Reedy tjre...@udel.edu 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
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
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.
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
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 et...@stoneleaf.us 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
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.
On Tue, 18 Feb 2014 10:01:42 -0800
Ethan Furman et...@stoneleaf.us 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
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
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
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
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?
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
Well, I'm against that.
On Tue, Feb 18, 2014 at 11:26 AM, Ethan Furman et...@stoneleaf.us 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
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
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
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
Well, I still think it should be done by value.
On Tue, Feb 18, 2014 at 11:53 AM, Serhiy Storchaka storch...@gmail.comwrote:
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
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
Brett Cannon br...@python.org 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
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
On Wed, Feb 19, 2014 at 3:10 AM, Mark Lawrence breamore...@yahoo.co.uk 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? :)
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
On 18 February 2014 21:17, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
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~
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
On 19 Feb 2014 07:26, Paul Moore p.f.mo...@gmail.com wrote:
On 18 February 2014 21:17, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
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
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
2014-02-19 0:46 GMT+01:00 Larry Hastings la...@hastings.org:
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.
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.
2014-02-17 0:25 GMT+01:00 Larry Hastings la...@hastings.org:
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
On 02/18/2014 03:54 PM, Victor Stinner wrote:
2014-02-19 0:46 GMT+01:00 Larry Hastings la...@hastings.org:
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?
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!
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
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
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...)
Sounds like you aren't exactly a DVCS fan...
On Tue, Feb 18, 2014 at 8:46 PM, Guido van Rossum gu...@python.org 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
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
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
53 matches
Mail list logo
