Re: [Python-Dev] undocumented help() function change in Python 3.4?

2014-03-11 Thread Ned Deily 
In article ,
 Georg Brandl  wrote:

> Am 11.03.2014 06:31, schrieb Ned Deily:
> > In article 
> > ,
> >  Nick Coghlan  wrote:
> >> On 11 March 2014 11:29, R. David Murray  wrote:
> >> > The whatsnew updates (including the one for help) weren't copied into
> >> > rc3.  They will be in final though, unless Larry forgets.
> >> 
> >> Oh, cool - yes, it will be good to have an up to date What's New
> >> shipped, especially as part of the compiled Windows docs.
> > 
> > I was going to bring that point up today. How are all the new whatsnew 
> > updates going to get into the 3.4.0 release?  They've, correctly, been 
> > being pushed to the default branch.  But, AFAIK, for them to show up in 
> > the 3.4.0 released docs we ship, all of the doc changes are going to 
> > need to be cherry picked (or a big mass diff from the default branch) 
> > into the 3.4 release branch, otherwise they will not be part of the 
> > release.  (They certainly won't be part of the docs included with the 
> > installers I build unless they are in the 3.4 releasing branch.)
> 
> Copying the file from default and doing just one commit in the releasing
> branch should be the easiest way.

That covers the whatsnew file but the changes RDM have been making 
affect other parts of the documentation and Misc/NEWS, too.

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] undocumented help() function change in Python 3.4?

2014-03-11 Thread Georg Brandl 
Am 11.03.2014 08:00, schrieb Ned Deily:
> In article ,
>  Georg Brandl  wrote:
> 
>> Am 11.03.2014 06:31, schrieb Ned Deily:
>> > In article 
>> > ,
>> >  Nick Coghlan  wrote:
>> >> On 11 March 2014 11:29, R. David Murray  wrote:
>> >> > The whatsnew updates (including the one for help) weren't copied into
>> >> > rc3.  They will be in final though, unless Larry forgets.
>> >> 
>> >> Oh, cool - yes, it will be good to have an up to date What's New
>> >> shipped, especially as part of the compiled Windows docs.
>> > 
>> > I was going to bring that point up today. How are all the new whatsnew 
>> > updates going to get into the 3.4.0 release?  They've, correctly, been 
>> > being pushed to the default branch.  But, AFAIK, for them to show up in 
>> > the 3.4.0 released docs we ship, all of the doc changes are going to 
>> > need to be cherry picked (or a big mass diff from the default branch) 
>> > into the 3.4 release branch, otherwise they will not be part of the 
>> > release.  (They certainly won't be part of the docs included with the 
>> > installers I build unless they are in the 3.4 releasing branch.)
>> 
>> Copying the file from default and doing just one commit in the releasing
>> branch should be the easiest way.
> 
> That covers the whatsnew file but the changes RDM have been making 
> affect other parts of the documentation and Misc/NEWS, too.

NEWS can also be copied of course.  As long as the others aren't critical
updates, just skip it for the final.

Most people read the online docs anyway.

Georg

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

2014-03-11 Thread Victor Stinner 
Hi,

Thanks David! I added a summary of security improvements:
http://docs.python.org/dev/whatsnew/3.4.html#summary-release-highlights

Can someone please review it? Don't hesitate to modify the text
directly. Check also if the summary is complete.

Victor

2014-03-11 3:05 GMT+01:00 R. David Murray :
> Well, I think What's New for 3.4 is done.  I've been through all of the
> NEWS items from the start of 3.4 through the beta1 release.  I've gone
> over the list of changes Serhiy found via the versionadded/versionchanged
> in the docs.  (Since he marked some that didn't turn out to be 3.4
> changes, I assume he was over-inclusive rather than under-inclusive
> and am not going to re-run that particular check myself...thanks
> Serhiy for doing it!).
>
> In addition to the items in Serhiy's list that didn't have news entries,
> there were a couple of features that were added after Beta1.  So there
> might be some other features with missing versionadded/changed tags in
> the NEWS sections I didn't go through, but I hope not.  Slightly more
> worrisome is the possibility that I'm missing porting notes from the
> beta/rc phases.  But, I'm pretty much out of time for this project since
> Final is almost upon us.  I'll be making at least one more copy-edit
> pass over the document, and may reformat some stuff, but the content is
> pretty much set at this point.
>
> If anyone knows of anything that is missing, please let me know about
> it.
>
> --David
>
> I track my time as a habit, so for the curious I can tell you with
> a fair degree of accuracy how long this little project took: about 73
> hours total, starting on 12/20 last year.  Let me tell you, it felt even
> longer than that :)
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

2014-03-11 Thread Nick Coghlan 
On 11 March 2014 12:05, R. David Murray  wrote:
> In addition to the items in Serhiy's list that didn't have news entries,
> there were a couple of features that were added after Beta1.  So there
> might be some other features with missing versionadded/changed tags in
> the NEWS sections I didn't go through, but I hope not.  Slightly more
> worrisome is the possibility that I'm missing porting notes from the
> beta/rc phases.  But, I'm pretty much out of time for this project since
> Final is almost upon us.  I'll be making at least one more copy-edit
> pass over the document, and may reformat some stuff, but the content is
> pretty much set at this point.

Thank you for that!

I was thinking of adding a new "Migrating from Python 2" section at
the end of the porting guide, noting the changed recommendations in
the migration guide (i.e. people that read it a while ago should read
it again), as well as the restoration of the binary and text transform
codec aliases. Sound reasonable?

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

2014-03-11 Thread Victor Stinner 
2014-03-11 13:28 GMT+01:00 Nick Coghlan :
> I was thinking of adding a new "Migrating from Python 2" section at
> the end of the porting guide, noting the changed recommendations in
> the migration guide (i.e. people that read it a while ago should read
> it again), as well as the restoration of the binary and text transform
> codec aliases. Sound reasonable?

Such info is useful, but I don't think that the What's New in Python
3.4 document is the right place. Or maybe add a link to another
document.

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] undocumented help() function change in Python 3.4?

2014-03-11 Thread R. David Murray 
On Tue, 11 Mar 2014 10:15:21 +0100, Georg Brandl  wrote:
> Am 11.03.2014 08:00, schrieb Ned Deily:
> > In article ,
> >  Georg Brandl  wrote:
> > 
> >> Am 11.03.2014 06:31, schrieb Ned Deily:
> >> > In article 
> >> > ,
> >> >  Nick Coghlan  wrote:
> >> >> On 11 March 2014 11:29, R. David Murray  wrote:
> >> >> > The whatsnew updates (including the one for help) weren't copied into
> >> >> > rc3.  They will be in final though, unless Larry forgets.
> >> >> 
> >> >> Oh, cool - yes, it will be good to have an up to date What's New
> >> >> shipped, especially as part of the compiled Windows docs.
> >> > 
> >> > I was going to bring that point up today. How are all the new whatsnew 
> >> > updates going to get into the 3.4.0 release?  They've, correctly, been 
> >> > being pushed to the default branch.  But, AFAIK, for them to show up in 
> >> > the 3.4.0 released docs we ship, all of the doc changes are going to 
> >> > need to be cherry picked (or a big mass diff from the default branch) 
> >> > into the 3.4 release branch, otherwise they will not be part of the 
> >> > release.  (They certainly won't be part of the docs included with the 
> >> > installers I build unless they are in the 3.4 releasing branch.)
> >> 
> >> Copying the file from default and doing just one commit in the releasing
> >> branch should be the easiest way.
> > 
> > That covers the whatsnew file but the changes RDM have been making 
> > affect other parts of the documentation and Misc/NEWS, too.
> 
> NEWS can also be copied of course.  As long as the others aren't critical
> updates, just skip it for the final.
> 
> Most people read the online docs anyway.

I don't think the NEWS changes are that important to copy either.  None
of the changes I made outside of whatsnew are substantive, they were
either adding or fixing version tags, fixing formatting, or fixing
typos or other copy-edit type things.  At least, I can't remember
anything that was substantive :)

Oh, there was one thing that might be worth cherry picking: the change
to the email docs.  The new EmailMessage class was documented as being
in the wrong module.  But even that isn't a big deal, since it's
a provisional class, and as Georg said most people read the online
docs anyway, since they get the ongoing updates between releases.

--David
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] undocumented help() function change in Python 3.4?

2014-03-11 Thread Guido van Rossum 
I'm not sure I agree completely with this lax attitude about the contents
of the docs, and especially the What's New parts of it (both Misc/NEWS and
Doc/whatsnew/3.4.rst). I find it very useful to have these pinpoint
*exactly* what made it into the tarball or zipfile or whatever other form I
happen to find the release -- you don't always have the full hg logs lying
around, nor do you always know from which exact revision or tag a tree was
built.

Of course it's fine to improve the docs in an ongoing fashion, and if it's
just a wording change to NEWS or whatsnew I don't mind missing it. But for
specific entries I'd like to strive for completeness in each branch/tag/rc.

Also, tonds of thanks to RDM for his work on the new whatsnew!


On Tue, Mar 11, 2014 at 6:52 AM, R. David Murray wrote:

> On Tue, 11 Mar 2014 10:15:21 +0100, Georg Brandl  wrote:
> > Am 11.03.2014 08:00, schrieb Ned Deily:
> > > In article ,
> > >  Georg Brandl  wrote:
> > >
> > >> Am 11.03.2014 06:31, schrieb Ned Deily:
> > >> > In article
> > >> >  >,
> > >> >  Nick Coghlan  wrote:
> > >> >> On 11 March 2014 11:29, R. David Murray 
> wrote:
> > >> >> > The whatsnew updates (including the one for help) weren't copied
> into
> > >> >> > rc3.  They will be in final though, unless Larry forgets.
> > >> >>
> > >> >> Oh, cool - yes, it will be good to have an up to date What's New
> > >> >> shipped, especially as part of the compiled Windows docs.
> > >> >
> > >> > I was going to bring that point up today. How are all the new
> whatsnew
> > >> > updates going to get into the 3.4.0 release?  They've, correctly,
> been
> > >> > being pushed to the default branch.  But, AFAIK, for them to show
> up in
> > >> > the 3.4.0 released docs we ship, all of the doc changes are going to
> > >> > need to be cherry picked (or a big mass diff from the default
> branch)
> > >> > into the 3.4 release branch, otherwise they will not be part of the
> > >> > release.  (They certainly won't be part of the docs included with
> the
> > >> > installers I build unless they are in the 3.4 releasing branch.)
> > >>
> > >> Copying the file from default and doing just one commit in the
> releasing
> > >> branch should be the easiest way.
> > >
> > > That covers the whatsnew file but the changes RDM have been making
> > > affect other parts of the documentation and Misc/NEWS, too.
> >
> > NEWS can also be copied of course.  As long as the others aren't critical
> > updates, just skip it for the final.
> >
> > Most people read the online docs anyway.
>
> I don't think the NEWS changes are that important to copy either.  None
> of the changes I made outside of whatsnew are substantive, they were
> either adding or fixing version tags, fixing formatting, or fixing
> typos or other copy-edit type things.  At least, I can't remember
> anything that was substantive :)
>
> Oh, there was one thing that might be worth cherry picking: the change
> to the email docs.  The new EmailMessage class was documented as being
> in the wrong module.  But even that isn't a big deal, since it's
> a provisional class, and as Georg said most people read the online
> docs anyway, since they get the ongoing updates between releases.
>
> --David
> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

2014-03-11 Thread Eric V. Smith 
On 3/11/2014 9:05 AM, Victor Stinner wrote:
> 2014-03-11 13:28 GMT+01:00 Nick Coghlan :
>> I was thinking of adding a new "Migrating from Python 2" section at
>> the end of the porting guide, noting the changed recommendations in
>> the migration guide (i.e. people that read it a while ago should read
>> it again), as well as the restoration of the binary and text transform
>> codec aliases. Sound reasonable?
> 
> Such info is useful, but I don't think that the What's New in Python
> 3.4 document is the right place. Or maybe add a link to another
> document.

I think if the guidance has changed over time, then mentioning it in a
What's New document, with a pointer to other documentation, is reasonable.

Eric.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Issue 20891 - PyGILState_Ensure on non-Python thread causes fatal error

2014-03-11 Thread Steve Dower 
Hi python-dev

Just wanted to draw some attention to http://bugs.python.org/issue20891, which 
I just created. (I hope I got the right people on the nosy list, but going 
broad just to be safe.)

Details and the discussion can go on there, but the basic gist is that C 
threads can't safely call PyGILState_Ensure() any more unless 
PyEval_InitThreads() has been called from an existing Python thread - you get a 
fatal error because there is no current thread state. Since PyGILState_Ensure 
is supposed to create this thread state, I believe this is a serious regression 
and would really like to see it fixed before 3.4 is released.

Cheers,
Steve

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] undocumented help() function change in Python 3.4?

2014-03-11 Thread Georg Brandl 
Am 11.03.2014 15:54, schrieb Guido van Rossum:
> I'm not sure I agree completely with this lax attitude about the contents of 
> the
> docs, and especially the What's New parts of it (both Misc/NEWS and
> Doc/whatsnew/3.4.rst).

I don't think anyone here suggested not to update the whatsnew document.

> I find it very useful to have these pinpoint *exactly*
> what made it into the tarball or zipfile or whatever other form I happen to 
> find
> the release -- you don't always have the full hg logs lying around, nor do you
> always know from which exact revision or tag a tree was built.

In any case, I like to think it's not a lax attitude, but a consistent one: we
basically don't want ANY non-critical changes in the RCs, so insufficient docs
should be treated like any other bugfix that's not a release blocker:
unfortunate, but not world-ending.

That exceptions can be and are made (e.g. for the whatsnew document) is because
for the docs the potential breakage is lower.

> Of course it's fine to improve the docs in an ongoing fashion, and if it's 
> just
> a wording change to NEWS or whatsnew I don't mind missing it. But for specific
> entries I'd like to strive for completeness in each branch/tag/rc.
> 
> Also, tonds of thanks to RDM for his work on the new whatsnew!

Definitely.

Georg

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

2014-03-11 Thread Nick Coghlan 
On 12 Mar 2014 02:21, "Eric V. Smith"  wrote:
>
> On 3/11/2014 9:05 AM, Victor Stinner wrote:
> > 2014-03-11 13:28 GMT+01:00 Nick Coghlan :
> >> I was thinking of adding a new "Migrating from Python 2" section at
> >> the end of the porting guide, noting the changed recommendations in
> >> the migration guide (i.e. people that read it a while ago should read
> >> it again), as well as the restoration of the binary and text transform
> >> codec aliases. Sound reasonable?
> >
> > Such info is useful, but I don't think that the What's New in Python
> > 3.4 document is the right place. Or maybe add a link to another
> > document.
>
> I think if the guidance has changed over time, then mentioning it in a
> What's New document, with a pointer to other documentation, is reasonable.

Yeah, that's what I meant - Brett already updated the guide, this would
just be a pointer to that.

I'll commit something tonight.

Cheers,
Nick.

>
> Eric.
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] undocumented help() function change in Python 3.4?

2014-03-11 Thread R. David Murray 
On Tue, 11 Mar 2014 19:57:36 +0100, Georg Brandl  wrote:
> Am 11.03.2014 15:54, schrieb Guido van Rossum:
> > I'm not sure I agree completely with this lax attitude about the contents 
> > of the
> > docs, and especially the What's New parts of it (both Misc/NEWS and
> > Doc/whatsnew/3.4.rst).
> 
> I don't think anyone here suggested not to update the whatsnew document.
> 
> > I find it very useful to have these pinpoint *exactly*
> > what made it into the tarball or zipfile or whatever other form I happen to 
> > find
> > the release -- you don't always have the full hg logs lying around, nor do 
> > you
> > always know from which exact revision or tag a tree was built.

As far as NEWS goes, I fixed some issue callouts so they'll be links in
the online version, I deleted a couple redundant entries, I fixed wording
here and there, and I added...three?...entries that were missing but I
found the commits from the versionadded or versionchanged doc updates
they contained that Serhiy found.  I'm sure there are other missing NEWS
entries that weren't caught, so wanting to know *exactly* what is in the
release is a lost cause unless you look at the commit log :) Especially
since the revision that contains the commit related to those added
news entries does *not* contain the news entry I added, so if you had
a tarball built from that revision you wouldn't have that news entry...

--David

PS: Also, sad to say I picked up the What's New task late in the 3.3
release cycle, and even with doing additional work *after* final I did
not finish.  So that document may be missing stuff...and in any case,
What's New never promises to include *everything*.  I have been more
completest in 3.4 than Raymond (intentionally) was for 3.2, but it still
doesn't have *every* enhancement.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] undocumented help() function change in Python 3.4?

2014-03-11 Thread Guido van Rossum 
On Tue, Mar 11, 2014 at 2:59 PM, R. David Murray wrote:

> On Tue, 11 Mar 2014 19:57:36 +0100, Georg Brandl  wrote:
> > Am 11.03.2014 15:54, schrieb Guido van Rossum:
> > > I'm not sure I agree completely with this lax attitude about the
> contents of the
> > > docs, and especially the What's New parts of it (both Misc/NEWS and
> > > Doc/whatsnew/3.4.rst).
> >
> > I don't think anyone here suggested not to update the whatsnew document.
> >
> > > I find it very useful to have these pinpoint *exactly*
> > > what made it into the tarball or zipfile or whatever other form I
> happen to find
> > > the release -- you don't always have the full hg logs lying around,
> nor do you
> > > always know from which exact revision or tag a tree was built.
>
> As far as NEWS goes, I fixed some issue callouts so they'll be links in
> the online version, I deleted a couple redundant entries, I fixed wording
> here and there, and I added...three?...entries that were missing but I
> found the commits from the versionadded or versionchanged doc updates
> they contained that Serhiy found.  I'm sure there are other missing NEWS
> entries that weren't caught, so wanting to know *exactly* what is in the
> release is a lost cause unless you look at the commit log :) Especially
> since the revision that contains the commit related to those added
> news entries does *not* contain the news entry I added, so if you had
> a tarball built from that revision you wouldn't have that news entry...
>

OK, understood. The thing is that I like the granularity of Misc/NEWS -- it
doesn't cover everything, but it covers pretty much everything you might
care about. The changelog is way too verbose.

--David
>
> PS: Also, sad to say I picked up the What's New task late in the 3.3
> release cycle, and even with doing additional work *after* final I did
> not finish.  So that document may be missing stuff...and in any case,
> What's New never promises to include *everything*.  I have been more
> completest in 3.4 than Raymond (intentionally) was for 3.2, but it still
> doesn't have *every* enhancement.
> 
>

I think that's a feature. What's New has always been an opinionated
document -- it goes from most to least important, and has a structure that
makes "skimming" particularly efficient.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why not make frames? [was: Alternative forms [was: PEP 463: Exception-catching expressions]]

2014-03-11 Thread Ethan Furman 

On 03/09/2014 07:16 PM, Jim J. Jewett wrote:


because I cannot imagine reading an embedded version of either of those
without having to mentally re-parse at the colon.  An example assuming
a precedence level that may not be what the PEP proposes:

 if myfunc(5, expr1 except expr2: expr3, "label"):
 for i in range(3, 3*max(data) except TypeError: 9, 3):
...

 if myfunc(5, (expr1 except expr2: expr3), "label"):
 for i in range(3, (3*max(data) except TypeError: 9), 3):
...

 if myfunc(5, expr1 except (expr2: expr3), "label"):
 for i in range(3, 3*max(data) except (TypeError: 9), 3):
...

 if myfunc(5, expr1 except (expr2: expr3), "label"):
 for i in range(3, 3*max(data) (except TypeError: 9), 3):
...

 if myfunc(5, expr1 except (expr3 if expr3), "label"):
 for i in range(3, 3*max(data) (except 9 if TypeError), 3):
...

 if myfunc(5, expr1 except (expr3 if expr3), "label"):
 for i in range(3, 3*max(data) except (9 if TypeError), 3):

 myarg = expr1 except (expr3 if expr2)
 if myfunc(5, myarg, "label"):
 limit = 3*max(data) except (9 if TypeError)
 for i in range(3, limit, 3):

Yes, I would prefer to create a variable naming those expressions,
but these are all still simple enough that I would expect to have
to read them.  (I like constructions that get ugly just a bit faster
than they get hard to understand.)  If I have to parse any of them,
the ones at the bottom are less difficult than the ones at the top.


I totally disagree.  I found the second one the easiest to read, and outside a function call (or other complexity, the 
parens wouldn't be needed.


--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

2014-03-11 Thread Ethan Furman 
I sure hope this is accepted.  I could have used it at least a half-dozen times in the last week -- which is more often 
than I would have used the ternary-if!  :)


--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

2014-03-11 Thread Chris Angelico 
On Wed, Mar 12, 2014 at 2:20 PM, Ethan Furman  wrote:
> I sure hope this is accepted.  I could have used it at least a half-dozen
> times in the last week -- which is more often than I would have used the
> ternary-if!  :)

Where do we go from here? I've not made any edits for some time - no
material edits for a good while - how do I request pronouncement?

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions

2014-03-11 Thread Chris Angelico 
PEP 463, Exception-catching expressions, is stable and I believe ready
for pronouncement. Drumroll please...

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

PEP: 463
Title: Exception-catching expressions
Version: $Revision$
Last-Modified: $Date$
Author: Chris Angelico 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Feb-2014
Python-Version: 3.5
Post-History: 20-Feb-2014, 16-Feb-2014


Abstract


Just as PEP 308 introduced a means of value-based conditions in an
expression, this system allows exception-based conditions to be used
as part of an expression.


Motivation
==

A number of functions and methods have parameters which will cause
them to return a specified value instead of raising an exception.  The
current system is ad-hoc and inconsistent, and requires that each
function be individually written to have this functionality; not all
support this.

* dict.get(key, default) - second positional argument in place of
  KeyError

* next(iter, default) - second positional argument in place of
  StopIteration

* list.pop() - no way to return a default

* seq[index] - no way to handle a bounds error

* min(sequence, default=default) - keyword argument in place of
  ValueError

* statistics.mean(data) - no way to handle an empty iterator

Had this facility existed early in Python's history, there would have been
no need to create dict.get() and related methods; the one obvious way to
handle an absent key would be to respond to the exception.  One method is
written which signals the absence in one way, and one consistent technique
is used to respond to the absence.  Instead, we have dict.get(), and as of
Python 3.4, we also have min(... default=default), and myriad others.  We
have a LBYL syntax for testing inside an expression, but there is currently
no EAFP notation; compare the following::

# LBYL:
if key in dic:
process(dic[key])
else:
process(None)
# As an expression:
process(dic[key] if key in dic else None)

# EAFP:
try:
process(dic[key])
except KeyError:
process(None)
# As an expression:
process(dic[key] except KeyError: None)

Python generally recommends the EAFP policy, but must then proliferate
utility functions like dic.get(key,None) to enable this.


Rationale
=

The current system requires that a function author predict the need
for a default, and implement support for it.  If this is not done, a
full try/except block is needed.

Since try/except is a statement, it is impossible to catch exceptions
in the middle of an expression.  Just as if/else does for conditionals
and lambda does for function definitions, so does this allow exception
catching in an expression context.

This provides a clean and consistent way for a function to provide a
default: it simply raises an appropriate exception, and the caller
catches it.

With some situations, an LBYL technique can be used (checking if some
sequence has enough length before indexing into it, for instance). This is
not safe in all cases, but as it is often convenient, programmers will be
tempted to sacrifice the safety of EAFP in favour of the notational brevity
of LBYL. Additionally, some LBYL techniques (eg involving getattr with
three arguments) warp the code into looking like literal strings rather
than attribute lookup, which can impact readability. A convenient EAFP
notation solves all of this.

There's no convenient way to write a helper function to do this; the
nearest is something ugly using either lambda::

def except_(expression, exception_list, default):
try:
return expression()
except exception_list:
return default()
value = except_(lambda: 1/x, ZeroDivisionError, lambda: float("nan"))

which is clunky, and unable to handle multiple exception clauses; or
eval::

def except_(expression, exception_list, default):
try:
return eval(expression, globals_of_caller(), locals_of_caller())
except exception_list as exc:
l = locals_of_caller().copy()
l['exc'] = exc
return eval(default, globals_of_caller(), l)

def globals_of_caller():
return sys._getframe(2).f_globals

def locals_of_caller():
return sys._getframe(2).f_locals

value = except_("""1/x""",ZeroDivisionError,""" "Can't divide by zero" """)

which is even clunkier, and relies on implementation-dependent hacks.
(Writing globals_of_caller() and locals_of_caller() for interpreters
other than CPython is left as an exercise for the reader.)

Raymond Hettinger `expresses`__ a desire for such a consistent
API. Something similar has been `requested`__ `multiple`__ `times`__
in the past.

__ https://mail.python.org/pipermail/python-ideas/2014-February/025443.html
__ https://mail.python.org/pipermail/python-ideas/2013-March/019760.html
__ https://mail.python.org/pipermail/python-ideas/2009-August/005441.html
__ https://mail.python.org/pipermail/