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
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 m
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
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...)
Pub
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 no
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
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
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
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* re
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
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?
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
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 int
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@pytho
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 thi
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 p
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
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~
___
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 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
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 sor
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
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 (Untoke
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
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 N
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
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
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
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 instea
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
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
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?
___
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 af
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
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 a
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 dis
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.
Se
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 con
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
Add
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.
I
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 r
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 implem
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 y
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, consi
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 ob
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 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, ke
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, datetim
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 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 initial
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 account
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
__
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:
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:
d
54 matches
Mail list logo
