Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

[Georg Brandl]

Am 19.02.2014 01:07, schrieb Larry Hastings:
> 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

And this works without a public repo on hg.python.org how?

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.4: Cherry-picking into rc2 and final

[Georg Brandl]

Am 19.02.2014 03:46, schrieb Guido van Rossum:
> 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...)

Pushes to hg.python.org repos are fully reversible.

If that is Larry's concern he can even put it on bitbucket, where only he can
push by default.

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.4: Cherry-picking into rc2 and final

[Georg Brandl]

Am 19.02.2014 00:54, schrieb Barry Warsaw:
> 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 emphatically agree.  There is no need at all for secrecy, or paranoia.

And it is very understandable that vendors (or even "just" our binary
building experts) want to make as many tests with what will be RC2 and
then final as they can, to catch possible issues before release.

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] Preview of 3.4 rc2 (so far) is up

[Nick Coghlan]

On 19 Feb 2014 14:05, "Larry Hastings"  wrote:
>
>
>
> 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,

Larry, you announced your preferred release candidate management process
too late to rely on it entirely - you should still audit all the deferred
blockers and release blockers flagged for 3.4, and ask for an update on
their status, with a pointer to the archived python-dev post describing how
to request that the change be included in 3.4.0 rather than being left to
3.4.1. I know at least I have been setting those on the assumption things
would work the same as they have in previous releases, since you hadn't
said anything prior to rc1 about doing things differently.

Regards,
Nick.

>
>
> /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/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] Preview of 3.4 rc2 (so far) is up

[Georg Brandl]

Am 19.02.2014 11:04, schrieb Nick Coghlan:
> 
> On 19 Feb 2014 14:05, "Larry Hastings"  > wrote:
>>
>>
>>
>> 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,
> 
> Larry, you announced your preferred release candidate management process too
> late to rely on it entirely - you should still audit all the deferred blockers
> and release blockers flagged for 3.4, and ask for an update on their status,
> with a pointer to the archived python-dev post describing how to request that
> the change be included in 3.4.0 rather than being left to 3.4.1. I know at 
> least
> I have been setting those on the assumption things would work the same as they
> have in previous releases, since you hadn't said anything prior to rc1 about
> doing things differently.

To be fair this isn't really different from 3.3.0, just that I didn't require a
specific format for issues and went through all changes manually.

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

[Lennart Regebro]

On Tue, Feb 18, 2014 at 5:10 PM, 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? :)

I think this is possible already, for the database people. The problem
is that it will not pass the is None test, which at the very least is
not backwards compatible with how they have used it before.
___
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] Preview of 3.4 rc2 (so far) is up

[Nick Coghlan]

On 19 February 2014 20:09, Georg Brandl  wrote:
> Am 19.02.2014 11:04, schrieb Nick Coghlan:
>>
>> On 19 Feb 2014 14:05, "Larry Hastings" > > wrote:
>>>
>>> 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,
>>
>> Larry, you announced your preferred release candidate management process too
>> late to rely on it entirely - you should still audit all the deferred 
>> blockers
>> and release blockers flagged for 3.4, and ask for an update on their status,
>> with a pointer to the archived python-dev post describing how to request that
>> the change be included in 3.4.0 rather than being left to 3.4.1. I know at 
>> least
>> I have been setting those on the assumption things would work the same as 
>> they
>> have in previous releases, since you hadn't said anything prior to rc1 about
>> doing things differently.
>
> To be fair this isn't really different from 3.3.0, just that I didn't require 
> a
> specific format for issues and went through all changes manually.

That's the part that worries me - if Larry is assuming the post to
python-dev is enough to get people to change their behaviour at short
notice, I'm concerned things that should be release blockers won't end
up blocking doing so.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

[Antoine Pitrou]

On Tue, 18 Feb 2014 18:54:23 -0500
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.

Agreed too. Python isn't developed in private.

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] Python 3.4: Cherry-picking into rc2 and final

[Antoine Pitrou]

On Tue, 18 Feb 2014 18:46:16 -0800
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...)

I don't think I understand the concern. Why is this different from any
other mistake someone may make when pushing code?
Also "rebase" is only really ok on private repos, as soon as something
is published you should use "merge".

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] Preview of 3.4 rc2 (so far) is up

[Antoine Pitrou]

On Tue, 18 Feb 2014 20:03:31 -0800
Larry Hastings  wrote:
> 
> Only thirty cherry-picked revisions so far.  Gosh, you're making my life 
> easy, guys,

That's a large number of cherry-picked revisions. How many are actually
release-critical?

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] Python 3.4: Cherry-picking into rc2 and final

[Hrvoje Niksic]

On 02/19/2014 01:20 PM, Antoine Pitrou wrote:

On Tue, 18 Feb 2014 18:46:16 -0800
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...)


I don't think I understand the concern. Why is this different from any
other mistake someone may make when pushing code?
Also "rebase" is only really ok on private repos, as soon as something
is published you should use "merge".


If the branch were private, pushing to it would not count as 
"publishing", but would still provide the benefit of having a redundant 
server-side backup of the data. Being able to rebase without fuss is a 
possible legitimate reason to keep the branch private, which Guido 
provided in response to Matthias's question:


>sorry, but this is so wrong. Is there *any* reason why to keep
>this branch private?

___
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] Preview of 3.4 rc2 (so far) is up

[Yury Selivanov]

About 21 of those are related to asyncio.

On 2/19/2014, 7:42 AM, Antoine Pitrou wrote:

On Tue, 18 Feb 2014 20:03:31 -0800
Larry Hastings  wrote:

Only thirty cherry-picked revisions so far.  Gosh, you're making my life
easy, guys,

That's a large number of cherry-picked revisions. How many are actually
release-critical?

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/yselivanov.ml%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] Python 3.4: Cherry-picking into rc2 and final

[Guido van Rossum]

On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl  wrote:

> Am 19.02.2014 00:54, schrieb Barry Warsaw:
> > 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 emphatically agree.  There is no need at all for secrecy, or paranoia.
>
> And it is very understandable that vendors (or even "just" our binary
> building experts) want to make as many tests with what will be RC2 and
> then final as they can, to catch possible issues before release.
>

That's why it's RC2 and not 3.4final, right? Once Larry says it's baked,
everyone *will* have a chance to test it. What value is a preview of the
preview really going to add? Give Larry some trust and freedom to do things
in the way that makes him comfortable.

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

[Barry Warsaw]

On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote:

>That's why it's RC2 and not 3.4final, right? Once Larry says it's baked,
>everyone *will* have a chance to test it. What value is a preview of the
>preview really going to add? Give Larry some trust and freedom to do things
>in the way that makes him comfortable.

I totally agree that Larry should be given fairly wide discretion.  He's also
feeling out his first big release and deserves some slack.

However, I think Matthias wants read access to the release repo because he's
*also* cherry picking patches into Ubuntu's archive.  We're already seeing
some problems, which we want to investigate, and Matthias has also performed
archive-wide test rebuilds to find Python 3.4 incompatibilities in 3rd party
libraries, most of which we'd like to fix (e.g. main packages, if its not
possible to get to everything in universe).

Matthias just switched the default for Ubuntu 14.04 to Python 3.4 by default,
so this is a great test bed to find problems.

Cheers,
-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

[Guido van Rossum]

On Wed, Feb 19, 2014 at 4:13 AM, Antoine Pitrou  wrote:
> Agreed too. Python isn't developed in private.

That's a ridiculous accusation, bordering on malicious. Larry isn't
"developing Python in private". He is simply working on something that
he'll release when he feels comfortable releasing it.

> I don't think I understand the concern. Why is this different from any
> other mistake someone may make when pushing code?

Maybe because 1000s of people are apparently ready to micro-manage and
criticize Larry's work and waiting for him to screw up? Why are you trying
to tell Larry how to use his tools? Larry *volunteered* to be the release
manager and got widespread support when he did. If you don't trust him, go
fucking fork the release yourself.

> Also "rebase" is only really ok on private repos, as soon as something
> is published you should use "merge".

And that's exactly why Larry is holding off pushing.

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

[Guido van Rossum]

On Wed, Feb 19, 2014 at 8:16 AM, Barry Warsaw  wrote:

> On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote:
>
> >That's why it's RC2 and not 3.4final, right? Once Larry says it's baked,
> >everyone *will* have a chance to test it. What value is a preview of the
> >preview really going to add? Give Larry some trust and freedom to do
> things
> >in the way that makes him comfortable.
>
> I totally agree that Larry should be given fairly wide discretion.  He's
> also
> feeling out his first big release and deserves some slack.
>

Thanks for the support!

However, I think Matthias wants read access to the release repo because he's
> *also* cherry picking patches into Ubuntu's archive.  We're already seeing
> some problems, which we want to investigate, and Matthias has also
> performed
> archive-wide test rebuilds to find Python 3.4 incompatibilities in 3rd
> party
> libraries, most of which we'd like to fix (e.g. main packages, if its not
> possible to get to everything in universe).
>

Again, this is what RC2 is for (and RC1, for that matter; apart from 20+
asyncio patches there really isn't much of a difference between RC1 and
RC2). Larry may legitimately feel uncomfortable with what he's got on his
local drive and prefer to tweak some things before telling people "go ahead
test with this" -- the difference is that if he was working on new *code*,
he could just not commit his work-in-progress, but since here he is
assembling the final sequence of *revisions*, he prefers just not to push.
(Georg alluded to the fact that you can undo changes in a public repo after
they've been pushed, but I suspect he's referring to hg backout, which
creates extra revisions, rather than a remote version of hg strip, which
would go against the philosophy of DVCS. Either way, Larry's use of Hg is a
totally legitimate workflow.)


> Matthias just switched the default for Ubuntu 14.04 to Python 3.4 by
> default,
> so this is a great test bed to find problems.
>

And that's great, of course. But what is really gained by giving Larry
trouble over a few days' worth of delay, at most?

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

[Georg Brandl]

Am 19.02.2014 16:50, schrieb Guido van Rossum:
> On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl  > wrote:
> 
> Am 19.02.2014 00:54, schrieb Barry Warsaw:
> > 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 emphatically agree.  There is no need at all for secrecy, or paranoia.
> 
> And it is very understandable that vendors (or even "just" our binary
> building experts) want to make as many tests with what will be RC2 and
> then final as they can, to catch possible issues before release.
> 
> 
> That's why it's RC2 and not 3.4final, right? Once Larry says it's baked,
> everyone *will* have a chance to test it. What value is a preview of the 
> preview
> really going to add?

Ned told me just a few days ago that he does regular pre-tag builds of the OSX
installers, and as for the Debian/Ubuntu side Barry can say more.  The thing
with the RCs is that as long as you add patches during the RC phase (which is
more or less unavoidable if the schedule is to be kept), the state of the
release branch can only profit from more eyes.

> Give Larry some trust and freedom to do things in the way that makes him
> comfortable.

I have no doubts that Larry will make 3.4 the best Python yet :)  So far he
has discussed most of his procedures with us, so I don't see a reason not to
weigh in here.

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.4: Cherry-picking into rc2 and final

[Georg Brandl]

Am 19.02.2014 19:00, schrieb Georg Brandl:

>> Give Larry some trust and freedom to do things in the way that makes him
>> comfortable.
> 
> I have no doubts that Larry will make 3.4 the best Python yet :)  So far he
> has discussed most of his procedures with us, so I don't see a reason not to
> weigh in here.

NB, "us" being the previous release managers.

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.4: Cherry-picking into rc2 and final

[Georg Brandl]

Am 19.02.2014 19:00, schrieb Georg Brandl:
> Am 19.02.2014 16:50, schrieb Guido van Rossum:
>> On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl > > wrote:
>> 
>> Am 19.02.2014 00:54, schrieb Barry Warsaw:
>> > 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 emphatically agree.  There is no need at all for secrecy, or paranoia.
>> 
>> And it is very understandable that vendors (or even "just" our binary
>> building experts) want to make as many tests with what will be RC2 and
>> then final as they can, to catch possible issues before release.
>> 
>> 
>> That's why it's RC2 and not 3.4final, right? Once Larry says it's baked,
>> everyone *will* have a chance to test it. What value is a preview of the 
>> preview
>> really going to add?
> 
> Ned told me just a few days ago that he does regular pre-tag builds of the OSX
> installers, and as for the Debian/Ubuntu side Barry can say more.  The thing
> with the RCs is that as long as you add patches during the RC phase (which is
> more or less unavoidable if the schedule is to be kept), the state of the
> release branch can only profit from more eyes.

There's even some helpful people on #python-dev (like Arfrever from Gentoo) who
frequently do post-push reviews, catching embarrassing bugs before they can
sneak their way into a release (thank you Arfrever!).

OK, that's my reasoning, I'm going to fucking shut up now.

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

[Glenn Linderman]

On 2/19/2014 2:53 AM, Lennart Regebro wrote:

On Tue, Feb 18, 2014 at 5:10 PM, 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? :)

I think this is possible already, for the database people. The problem
is that it will not pass the is None test, which at the very least is
not backwards compatible with how they have used it before.


The new singleton will be called something else, likely with Null in the 
name, so that's what I'll call it here... Null.


So when switching from None to Null, you must also switch from "is None" 
to "is Null".


Of course it is not backwards compatible... but once all the "database 
related None usage" is switched to "Null usage" it should work the same 
as before, but with proper (for some database's definition of proper) 
semantics.
___
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

[Nick Coghlan]

On 20 Feb 2014 04:18, "Georg Brandl"  wrote:
>
> Am 19.02.2014 19:00, schrieb Georg Brandl:
> > Am 19.02.2014 16:50, schrieb Guido van Rossum:
> >> On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl  >> > wrote:
> >>
> >> Am 19.02.2014 00:54, schrieb Barry Warsaw:
> >> > 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 emphatically agree.  There is no need at all for secrecy, or
paranoia.
> >>
> >> And it is very understandable that vendors (or even "just" our
binary
> >> building experts) want to make as many tests with what will be RC2
and
> >> then final as they can, to catch possible issues before release.
> >>
> >>
> >> That's why it's RC2 and not 3.4final, right? Once Larry says it's
baked,
> >> everyone *will* have a chance to test it. What value is a preview of
the preview
> >> really going to add?
> >
> > Ned told me just a few days ago that he does regular pre-tag builds of
the OSX
> > installers, and as for the Debian/Ubuntu side Barry can say more.  The
thing
> > with the RCs is that as long as you add patches during the RC phase
(which is
> > more or less unavoidable if the schedule is to be kept), the state of
the
> > release branch can only profit from more eyes.
>
> There's even some helpful people on #python-dev (like Arfrever from
Gentoo) who
> frequently do post-push reviews, catching embarrassing bugs before they
can
> sneak their way into a release (thank you Arfrever!).
>
> OK, that's my reasoning, I'm going to fucking shut up now.

I suspect everyone is also highly aware of the fact that there are some
ambitious changes in 3.4, the release of rc1 is bringing the usual wave of
additional third party testing that has picked up some interesting
regressions and usability issues (e.g. the Alembic test suite found a fun
one in the inspect module, while the pip installation doesn't currently
play nice with UAC on Windows), and the Ubuntu 14.04 deadline restricts our
ability to add a 3rd rc.

That brings with it a strong desire to parallelise things as much as
possible, and read only access to the upcoming release helps greatly in
knowing which regressions have already been addressed, allowing third party
testers to more easily focus on any remaining issues.

A "user beware, this may be rebased without warning" clone would be fine
for that purpose, and I suspect in most cases just running rc2 -> final
with such a clone available (preserving Larry's current workflow until rc2)
would be sufficient to address most concerns.

Regards,
Nick.

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

[Python-Dev] PEPs don't redirect on python.org

[Chris Angelico]

Apologies if this is misdirected!

I notice the switch to the new python.org web site has happened; but
now PEPs are simply 404:

http://www.python.org/dev/peps/pep-0008/

However, trimming the URL offers a redirect:

http://www.python.org/dev/peps/

->

http://legacy.python.org/dev/peps/

from which the content can be found. Can a blanket redirect rule be
put in that makes all the PEPs at least go to /dev/peps/ ?

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

Re: [Python-Dev] PEPs don't redirect on python.org

[Chris Angelico]

On Thu, Feb 20, 2014 at 10:25 AM, Chris Angelico  wrote:
> I notice the switch to the new python.org web site has happened; but
> now PEPs are simply 404:
>
> http://www.python.org/dev/peps/pep-0008/
>
> However, trimming the URL offers a redirect:
>
> http://www.python.org/dev/peps/
>
> ->
>
> http://legacy.python.org/dev/peps/

Oh! Must have been a transitional period. The PEPs now redirect too.
Thanks, whoever did that! Makes the linking much easier. :)

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

Re: [Python-Dev] Preview of 3.4 rc2 (so far) is up

[Larry Hastings]

On 02/19/2014 02:04 AM, Nick Coghlan wrote:



On 19 Feb 2014 14:05, "Larry Hastings" > wrote:

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


Larry, you announced your preferred release candidate management 
process too late to rely on it entirely - you should still audit all 
the deferred blockers and release blockers flagged for 3.4, and ask 
for an update on their status, with a pointer to the archived 
python-dev post describing how to request that the change be included 
in 3.4.0 rather than being left to 3.4.1. I know at least I have been 
setting those on the assumption things would work the same as they 
have in previous releases, since you hadn't said anything prior to rc1 
about doing things differently.




The release is still about a month away.  And yes I still plan to go 
through the release blockers.



//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] Preview of 3.4 rc2 (so far) is up

[Larry Hastings]

On 02/19/2014 07:20 AM, Yury Selivanov wrote:

About 21 of those are related to asyncio.

On 2/19/2014, 7:42 AM, Antoine Pitrou wrote:

On Tue, 18 Feb 2014 20:03:31 -0800
Larry Hastings  wrote:
Only thirty cherry-picked revisions so far.  Gosh, you're making my 
life

easy, guys,

That's a large number of cherry-picked revisions. How many are actually
release-critical?

Regards

Antoine.


Yes, I'm allowing in basically all the asyncio changes, because a) 
there's no installed base, and b) Guido is himself very heavily involved 
in those changes.  It's my opinion that asyncio is going to get a lot of 
scrutiny after 3.4.0 ships, so even though it's marked provisional it's 
important to get it right.  And I don't have enough domain knowledge to 
be able to pick and choose their changes.  So I'm relying on Victor / 
Guido / Yury, merging all their changes, and hoping for the best.


I really am hoping it'll settle down soon, though,


//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] Preview of 3.4 rc2 (so far) is up

[Guido van Rossum]

On Wed, Feb 19, 2014 at 4:42 PM, Larry Hastings  wrote:

>  Yes, I'm allowing in basically all the asyncio changes, because a)
> there's no installed base, and b) Guido is himself very heavily involved in
> those changes.  It's my opinion that asyncio is going to get a lot of
> scrutiny after 3.4.0 ships, so even though it's marked provisional it's
> important to get it right.  And I don't have enough domain knowledge to be
> able to pick and choose their changes.  So I'm relying on Victor / Guido /
> Yury, merging all their changes, and hoping for the best.
>
> I really am hoping it'll settle down soon, though,
>

I am actively clamping down on these now. Yuri's and Victor's youthful
enthusiasm is adorable. :-)

-- 
--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] Preview of 3.4 rc2 (so far) is up

[Nick Coghlan]

On 20 February 2014 10:31, Larry Hastings  wrote:
> On 02/19/2014 02:04 AM, Nick Coghlan wrote:
>
> The release is still about a month away.  And yes I still plan to go through
> the release blockers.

Thanks. I confess I had missed that rc2 -> final was already 3 weeks
rather than the 2 weeks between rc1 and rc2, so my mental timeline was
off.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

[Stephen J. Turnbull]

Nick Coghlan writes:

 > I suspect everyone is also highly aware of the fact that there are
 > some ambitious changes in 3.4,

Which is an argument for longer beta and RC periods than usual, or
maybe some of the ambition should have been restrained.  It's not
necessarily a reason why more eyes help (see below).

 > the release of rc1 is bringing the usual wave of additional third
 > party testing that has picked up some interesting regressions and
 > usability issues (e.g. the Alembic test suite found a fun one in
 > the inspect module, while the pip installation doesn't currently
 > play nice with UAC on Windows), and the Ubuntu 14.04 deadline
 > restricts our ability to add a 3rd rc.

OK, but that means we're screwed regardless.  We've decided to release
what we've got on a specific timeline, and a few extra days of testing
is going to make a marginal difference on average.

Remember that under time pressure in bugfixing, the average programmer
introduces a new bug that gets through to a product every ten lines.
OK, so we're[1] 100X better than average, and I suppose for some
subset 1000X better.  Still that means several new bugs, and some of
them may be doozies.

 > That brings with it a strong desire to parallelise things as much
 > as possible, and read only access to the upcoming release helps
 > greatly in knowing which regressions have already been addressed,
 > allowing third party testers to more easily focus on any remaining
 > issues.

Sure, but it *doesn't* help in knowing which ones are *correctly*
addressed.  These *are* ambitious changes; some of the remaining bugs
may be very deep.  The obvious fixes may do more harm than good.  Ie,
"more eyes" is (a) mostly a fallacy (as Heinlein put it, the wisdom of
a group is less than or equal to the maximum of the wisdom of the
members) and (b) in any case the "more eyes" effect is diluted if
people are deliberately looking at different parts of the code.

 > A "user beware, this may be rebased without warning" clone would be
 > fine for that purpose, and I suspect in most cases just running rc2
 > -> final with such a clone available (preserving Larry's current
 > workflow until rc2) would be sufficient to address most concerns.

Larry's already providing tarballs as I understand it.

The argument that a "read-only, no cherrypicking by committers" repo
is nothing but a better tarball is valid, but as I say, AFAICS the
expected gain is pretty marginal.  The conflict here is not Larry's
process, it's the decision to make an ambitious release on a short
time schedule.  I sympathize with Ubuntu to some extent -- they have a
business to run, after all.  But should Ubuntu desires be distorting a
volunteer RE's process?  Was Larry told that commercial interests
should be respected in designing his process?


Footnotes: 
[1]  FVO "we" not containing "me".  You'll notice I'm not submitting
patches.


___
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] A misredirected ticket link in hg.python.org/cpython

[Vajrasky Kok]

Go to any commit link in hg.python.org/cpython, for example
http://hg.python.org/cpython/rev/d11ca14c9a61.

You have this commit message:

Issue #6815: os.path.expandvars() now supports non-ASCII Unicode
environment variables names and values. [#6815]

The [#6815] link is going to http://bugs.python.org/6815. If you
follow that link, it redirects to http://legacy.python.org/sf/ and you
get message: You did not provide a report number. The link should be
http://bugs.python.org/issue6815.

Cheers,
Vajrasky Kok
___
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

[Barry Warsaw]

On Feb 20, 2014, at 10:24 AM, Stephen J. Turnbull wrote:

>But should Ubuntu desires be distorting a volunteer RE's process?

Ubuntu 14.04 final freeze is April 10[1], so I think that's the drop dead date
for getting 3.4 final into Ubuntu 14.04.  Matthias may correct me, but I think
if we can hit that date (well, maybe a day or two early to be safe) we're good.

Missing that date probably isn't catastrophic, especially if there are few to
no changes between the last Python 3.4 rc before our final freeze, and Python
3.4 final.  What it means is that 14.04 won't ship with the final Python 3.4
and we'll have to do a "stable release update" after 14.04 to catch up to the
Python 3.4 final release.  It does mean that many Ubuntu users won't see it
until 14.04.1, whenever that is, if at all.  But if the only difference is a
version string and sys.version_info, then I don't think that's so bad.  And
ultimately we'll have to do that anyway to get the LTS users Python 3.4.1,
3.4.2, and so on.

Two notes: Matthias just enabled Python 3.4 as the default Python 3, and
there's no going back.  Also, we have aligned the Python release schedules
with external schedules before, most notably Apple a couple of times.  I think
it's reasonable to do so *if* we can do it without sacrificing the quality of
Python 3.4's final release.

Cheers,
-Barry

[1] https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
___
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

[Ethan Furman]

On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote:


The conflict here is not Larry's
process, it's the decision to make an ambitious release on a short
time schedule.  I sympathize with Ubuntu to some extent -- they have a
business to run, after all.  But should Ubuntu desires be distorting a
volunteer RE's process?  Was Larry told that commercial interests
should be respected in designing his process?


When talk of slipping the final date again was discussed, Guido basically said 
no.

--
~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.4: Cherry-picking into rc2 and final

[Nick Coghlan]

On 20 Feb 2014 12:26, "Ethan Furman"  wrote:
>
> On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote:
>>
>>
>> The conflict here is not Larry's
>> process, it's the decision to make an ambitious release on a short
>> time schedule.  I sympathize with Ubuntu to some extent -- they have a
>> business to run, after all.  But should Ubuntu desires be distorting a
>> volunteer RE's process?  Was Larry told that commercial interests
>> should be respected in designing his process?
>
>
> When talk of slipping the final date again was discussed, Guido basically
said no.

Guido said no more to the additional Argument Clinic related changes,
rather than to an extra rc in general.

Note that I made my comment before Larry pointed out the existing schedule
was a week longer than I thought, and Barry clarified that there *is* still
room for a third rc if Larry decides that would be appropriate.

Cheers,
Nick.

>
> --
> ~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/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] python 3 niggle: None < 1 raises TypeError

[Greg Ewing]

On 20/02/14 08:23, Glenn Linderman wrote:

Of course it is not backwards compatible... but once all the "database related
None usage" is switched to "Null usage" it should work the same as before,


My problem with this is that there is no clear distinction
between "database-related None usage" and None usage in general.

Data retrieved from a database is often passed to other code
that has nothing to do with databases, and data received from
other code is inserted into databases. Somewhere in between
someone is going to have to be careful to translate back and
forth between Nones and Nulls. This is a recipe for chaos.

--
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.4: Cherry-picking into rc2 and final

[Larry Hastings]

On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote:

Nick Coghlan writes:
  > A "user beware, this may be rebased without warning" clone would be
  > fine for that purpose, and I suspect in most cases just running rc2
  > -> final with such a clone available (preserving Larry's current
  > workflow until rc2) would be sufficient to address most concerns.

Larry's already providing tarballs as I understand it.


Yep.  Well, just "tarball" so far ;-)

As for a "user beware" clone: I worry about providing anything that 
looks/tastes/smells like a repo.  Someone could still inadvertently push 
those revisions back to trunk, and then we'd have a real mess on our 
hands.  Publishing tarballs drops the possibility down to about zero.




The conflict here is not Larry's
process, it's the decision to make an ambitious release on a short
time schedule.  I sympathize with Ubuntu to some extent -- they have a
business to run, after all.  But should Ubuntu desires be distorting a
volunteer RE's process?  Was Larry told that commercial interests
should be respected in designing his process?


I haven't seen anything that makes me think we're in trouble.  Every 
release has its bumps; that's what the rc period is for.  I remind you 
we're still a month away.


I grant you asyncio is still evolving surprisingly rapidly for an rc.  
But it doesn't have an installed base yet, and it's provisional anyway, 
so it's not making me anxious.


Worst case, we issue a 3.4.1 on a very accelerated schedule.  But it 
doesn't seem like it'll be necessary.



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

[Stephen J. Turnbull]

Larry Hastings writes:

 > Someone could still inadvertently push those revisions back to
 > trunk, and then we'd have a real mess on our hands.  Publishing
 > tarballs drops the possibility down to about zero.

Note: I see no reason for you to change your process for the 3.4.0
release.  I just want to record my comments in this thread for
future reference.

I don't think any of the above is true.  First, although
"possibility of inadvertant push" as written is obviously correct,
I don't think the implication that the *probability* of an
*inadvertant* push is any higher is correct (somebody else --
Antoine? Guido? -- already pointed this out).  The reasoning is
that if somebody clones from a mirror of your release branch, they
will have to make a deliberate decision to push to trunk, or a
deliberate decision to merge or cherrypick from your branch into a
branch destined for trunk, to cause a problem.  That's actually
safer than if they apply a patch from the tracker by hand, since
in the case of a patch there will be no metadata to indicate that
the conflict was caused by concurrent cherrypicks, and if they're
sufficiently incautious, the actual change data may be different.
That is messy.

Second, what "real mess"?  "VCS means never having to say 'Oh,
shit!'"  If such a thing happens, you just take your branch, do an
"ours" merge with trunk obsoleting the trunk, and then cherrypick
everything appropriate from obs-trunk.  Tedious, yes.  Somewhat
error-prone, I suppose.  Keep the buildbots very busy for a while,
for sure.  Real mess?  IMHO, no.  The fact that the repair procedure
uses only "proper merges" (vs. rebase) means that rebase confusion
can't propagate silently, nor can committed changes (in anybody's
branch) be inadvertantly lost.  (There are better strategies than
the above, which I'll be happy to discuss if and when necessary.
And for tedium reduction, there are features like git's filter-branch,
which a Mercurial dev assures me can be done with hg too.)

Third, tarballs don't drop the possibility to zero.  We know that
patch reviewers have those patches in local workspaces.  In some
cases you can diff a file from the tarball and get the patch you
want (mostly, as mentioned above) and apply that to your feature
branch.  In the case of asyncio, some such path to a duplicate
cherrypick seems quite probable (compared with "near zero",
anyway).

 > I haven't seen anything that makes me think we're in trouble.

Your evaluation is plenty good enough for me.  But the actual
information that your assessment is based on is almost private to
you, and that's the reason other folks want access to a repo.  By
"almost private" I mean that the manipulation of revision
information that DVCSes make so convenient is unavailable to them.

___
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

[Stephen J. Turnbull]

Greg Ewing writes:

 > Data retrieved from a database is often passed to other code
 > that has nothing to do with databases, and data received from
 > other code is inserted into databases. Somewhere in between
 > someone is going to have to be careful to translate back and
 > forth between Nones and Nulls.

Sure.  The suggestion is to assign responsibility for such careful
translation to implementers of the DB API.

 > This is a recipe for chaos.

If it is, then chaos is already upon us because you can't be careful
even if you want to.

I don't know if fixing it is worth the work and confusion involved in
the fixing process, but fixing it will conserve (and maybe reduce)
chaos, not create it.
___
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] A misredirected ticket link in hg.python.org/cpython

[Ned Deily]

In article 
,
 Vajrasky Kok  wrote:

> Go to any commit link in hg.python.org/cpython, for example
> http://hg.python.org/cpython/rev/d11ca14c9a61.
> 
> You have this commit message:
> 
> Issue #6815: os.path.expandvars() now supports non-ASCII Unicode
> environment variables names and values. [#6815]
> 
> The [#6815] link is going to http://bugs.python.org/6815. If you
> follow that link, it redirects to http://legacy.python.org/sf/ and you
> get message: You did not provide a report number. The link should be
> http://bugs.python.org/issue6815.

Thanks!  I've reported the problem to Noah on the infrastructure team.

-- 
 Ned Deily,
 n...@acm.org

___
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: What to do about the Derby patches

[Nick Coghlan]

On 20 February 2014 16:42, Ronald Oussoren  wrote:
>
> On 17 Feb 2014, at 00:43, Nick Coghlan  wrote:
>
>>
>> On 17 Feb 2014 08:36, "Greg Ewing"  wrote:
>> >
>> > Larry Hastings wrote:
>> >
>> >> 3) We hold off on merging the rest of the Derby patches until after 3.4.0 
>> >> final ships, then we merge them into the 3.4 maintenance branch so they 
>> >> go into 3.4.1.
>> >
>> >
>> > But wouldn't that be introducing a new feature into a
>> > maintenance release? (I.e. some functions that didn't
>> > have introspectable signatures before would gain them.)
>>
>> From a compatibility point of view, 3.4.0 will already force introspection 
>> users and tool developers to cope with the fact that some, but not all, 
>> builtin and extension types provide valid signature data. Additional clinic 
>> conversions that don't alter semantics then just move additional callables 
>> into the "supports programmatic introspection" category.
>>
>> It's certainly in a grey area, but "What's in the best interest of end 
>> users?" pushes me in the direction of counting clinic conversions that don't 
>> change semantics as bug fixes - they get improved introspection support 
>> sooner, and it shouldn't make life any harder for tool developers because 
>> all of the adjustments for 3.4 will be to the associated functional changes 
>> in the inspect module.
>>
>> The key thing is to make sure to postpone any changes that impact 
>> *semantics* (like adding keyword argument support).
>
> But there is a semantic change: some functions without a signature in 3.4.0 
> would have a signature in 3.4.1. That's unlikely to affect user code much 
> because AFAIK signatures aren't used a lot yet, but it is a semantic change 
> non the less :-)

Heh, you must have managed to miss all the Argument Clinic debates -
"semantics" there is shorthand for "the semantics of the call" :)

It turns out there are some current C signatures where we either need
to slightly change the semantics of the API or else add new features
to the inspect module before we can represent them properly at the
Python layer. So, for the life of Python 3.4, those are off limits for
conversion, and we'll sort them out as part of PEP 457 for 3.5.

However, there are plenty of others where the signature *can* be
adequately represented in 3.4, they just aren't (yet). So the approach
Larry has taken is to declare that "could expose valid signature data,
but doesn't" counts as a bug fix for Python 3.4 maintenance release
purposes. We'll make sure the porting section of the What's New guide
addresses that explicitly for the benefit of anyone porting
introspection tools to Python 3.4 (having all of the argument
introspection in the inspect module be based on inspect.signature and
various enhancements to inspect.signature itself has significantly
increased the number of callables that now support introspection).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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: What to do about the Derby patches

[Ronald Oussoren]

On 20 Feb 2014, at 08:09, Nick Coghlan  wrote:

> On 20 February 2014 16:42, Ronald Oussoren  wrote:
>> 
>> On 17 Feb 2014, at 00:43, Nick Coghlan  wrote:
>> 
>>> 
>>> On 17 Feb 2014 08:36, "Greg Ewing"  wrote:
 
 Larry Hastings wrote:
 
> 3) We hold off on merging the rest of the Derby patches until after 3.4.0 
> final ships, then we merge them into the 3.4 maintenance branch so they 
> go into 3.4.1.
 
 
 But wouldn't that be introducing a new feature into a
 maintenance release? (I.e. some functions that didn't
 have introspectable signatures before would gain them.)
>>> 
>>> From a compatibility point of view, 3.4.0 will already force introspection 
>>> users and tool developers to cope with the fact that some, but not all, 
>>> builtin and extension types provide valid signature data. Additional clinic 
>>> conversions that don't alter semantics then just move additional callables 
>>> into the "supports programmatic introspection" category.
>>> 
>>> It's certainly in a grey area, but "What's in the best interest of end 
>>> users?" pushes me in the direction of counting clinic conversions that 
>>> don't change semantics as bug fixes - they get improved introspection 
>>> support sooner, and it shouldn't make life any harder for tool developers 
>>> because all of the adjustments for 3.4 will be to the associated functional 
>>> changes in the inspect module.
>>> 
>>> The key thing is to make sure to postpone any changes that impact 
>>> *semantics* (like adding keyword argument support).
>> 
>> But there is a semantic change: some functions without a signature in 3.4.0 
>> would have a signature in 3.4.1. That's unlikely to affect user code much 
>> because AFAIK signatures aren't used a lot yet, but it is a semantic change 
>> non the less :-)
> 
> Heh, you must have managed to miss all the Argument Clinic debates -
> "semantics" there is shorthand for "the semantics of the call" :)

I skipped most of that discussion, due to the sheer volume and limited time to 
add something meaningful to that discussion.

> 
> It turns out there are some current C signatures where we either need
> to slightly change the semantics of the API or else add new features
> to the inspect module before we can represent them properly at the
> Python layer. So, for the life of Python 3.4, those are off limits for
> conversion, and we'll sort them out as part of PEP 457 for 3.5.

That much I noticed, and IIRC it was noticed fairly early on in Argument 
Clinic’s history that there are C functions that have an API that cannot easily 
be represented in a pure Python function (other than using ‘*args, **kw’ and 
manually parsing the argument list). 

I totally agree that changing the signature of functions should wait for 3.5, 
but that’s the easy bit.

> 
> However, there are plenty of others where the signature *can* be
> adequately represented in 3.4, they just aren't (yet). So the approach
> Larry has taken is to declare that "could expose valid signature data,
> but doesn't" counts as a bug fix for Python 3.4 maintenance release
> purposes. We'll make sure the porting section of the What's New guide
> addresses that explicitly for the benefit of anyone porting
> introspection tools to Python 3.4 (having all of the argument
> introspection in the inspect module be based on inspect.signature and
> various enhancements to inspect.signature itself has significantly
> increased the number of callables that now support introspection).

I can live with that, but don’t really agree that exposing new signature data 
is a bug fix. But maybe I’m just too conservative :-)

To end on a positive not, I do like signature objects, and have added support 
for them to PyObjC to enrich its introspection capabilities.

Ronald

> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia

___
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: What to do about the Derby patches

[Ronald Oussoren]

On 17 Feb 2014, at 00:43, Nick Coghlan  wrote:

> 
> On 17 Feb 2014 08:36, "Greg Ewing"  wrote:
> >
> > Larry Hastings wrote:
> >
> >> 3) We hold off on merging the rest of the Derby patches until after 3.4.0 
> >> final ships, then we merge them into the 3.4 maintenance branch so they go 
> >> into 3.4.1.
> >
> >
> > But wouldn't that be introducing a new feature into a
> > maintenance release? (I.e. some functions that didn't
> > have introspectable signatures before would gain them.)
> 
> From a compatibility point of view, 3.4.0 will already force introspection 
> users and tool developers to cope with the fact that some, but not all, 
> builtin and extension types provide valid signature data. Additional clinic 
> conversions that don't alter semantics then just move additional callables 
> into the "supports programmatic introspection" category.
> 
> It's certainly in a grey area, but "What's in the best interest of end 
> users?" pushes me in the direction of counting clinic conversions that don't 
> change semantics as bug fixes - they get improved introspection support 
> sooner, and it shouldn't make life any harder for tool developers because all 
> of the adjustments for 3.4 will be to the associated functional changes in 
> the inspect module.
> 
> The key thing is to make sure to postpone any changes that impact *semantics* 
> (like adding keyword argument support).

But there is a semantic change: some functions without a signature in 3.4.0 
would have a signature in 3.4.1. That’s unlikely to affect user code much 
because AFAIK signatures aren’t used a lot yet, but it is a semantic change non 
the less :-)

Ronald
___
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