[Python-Dev] Issue 22619 at bugs.python.org

2015-01-06 Thread Dmitry Kazakov 
Greetings.

I'm sorry if I'm too insistent, but it's not truly rewarding to
constantly improve a patch that no one appears to need. Again, I
understand people are busy working and/or reviewing critical patches,
but 2 months of inactivity is not right. Yes, I posted a message
yesterday, but no one seemed to be bothered. In any case, I'll respect
your decision about this patch and will never ask for a review of this
patch again.

Regards, Dmitry.
___
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] python 2.7.9 regression in argparse?

2015-01-06 Thread anatoly techtonik 
https://github.com/nickstenning/honcho/pull/121

-- 
anatoly t.
___
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] Issue 22619 at bugs.python.org

2015-01-06 Thread Victor Stinner 
http://bugs.python.org/issue22619
"Possible implementation of negative limit for traceback functions"

I see that Serhiy Storchaka reviewed a patch.

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] python 2.7.9 regression in argparse?

2015-01-06 Thread Victor Stinner 
More context:

2014-12-19 12:43 GMT+01:00 anatoly techtonik :
> https://github.com/nickstenning/honcho/pull/121

The link mentions the following changeset:
---
changeset:   93122:1a3143752db2
branch:  2.7
parent:  93112:927cca0b9337
user:R David Murray 
date:Fri Oct 17 20:07:08 2014 -0400
files:   Lib/argparse.py Lib/test/test_argparse.py Misc/NEWS
description:
#9351: set_defaults on subparser is no longer ignored if set on parent.

Before, if a default was set on the parent parser, any default for that
variable set via set_defaults on a subparser would be ignored.  Now
the subparser set_defaults is honored.

Patch by Jyrki Pullianinen.


diff -r 927cca0b9337 -r 1a3143752db2 Lib/argparse.py
--- a/Lib/argparse.py   Fri Oct 17 16:20:15 2014 -0500
+++ b/Lib/argparse.py   Fri Oct 17 20:07:08 2014 -0400
@@ -1089,7 +1089,14 @@ class _SubParsersAction(Action):
 # parse all the remaining options into the namespace
 # store any unrecognized options on the object, so that the top
 # level parser can decide what to do with them
-namespace, arg_strings = parser.parse_known_args(arg_strings,
namespace)
+
+# In case this subparser defines new defaults, we parse them
+# in a new namespace object and then update the original
+# namespace for the relevant parts.
+subnamespace, arg_strings = parser.parse_known_args(arg_strings, None)
+for key, value in vars(subnamespace).items():
+setattr(namespace, key, value)
+
 if arg_strings:
 vars(namespace).setdefault(_UNRECOGNIZED_ARGS_ATTR, [])
 getattr(namespace, _UNRECOGNIZED_ARGS_ATTR).extend(arg_strings)
---

Which is related to http://bugs.python.org/issue9351

Maybe argparse just became more strict? I don't understand the issue.

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] Issue 22619 at bugs.python.org

2015-01-06 Thread Stefan Ring 
On Tue, Jan 6, 2015 at 8:52 AM, Dmitry Kazakov  wrote:
> Greetings.
>
> I'm sorry if I'm too insistent, but it's not truly rewarding to
> constantly improve a patch that no one appears to need. Again, I
> understand people are busy working and/or reviewing critical patches,
> but 2 months of inactivity is not right. Yes, I posted a message
> yesterday, but no one seemed to be bothered. In any case, I'll respect
> your decision about this patch and will never ask for a review of this
> patch again.

The later patches seem to miss the Mercurial header that would allow
the integrated review functionality on bugs.python.org to kick in (I
presume) and thus make it much easier to review.
___
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] New Windows installer for Python 3.5

2015-01-06 Thread Nick Coghlan 
On 5 January 2015 at 18:17, Paul Moore  wrote:
> On 5 January 2015 at 01:20, Steve Dower  wrote:
>> I think this means the best way to make multiple versions work properly is 
>> to rename python.exe to python3.5.exe, then install the launcher as 
>> python.exe and python3.exe (with some logic to look at its own name) so it 
>> can resolve the right version. Maybe we can even extend the launcher to 
>> resolve launchers in Scripts (pip.exe, etc.) and have consistent rules there 
>> too?
>
> This was a big debate over on distutils-sig. I advocated "py -m pip"
> for portable use, but got basically nowhere. People want "pip" to
> work, for compatibility with Unix (and hence ease of documentation).

"pip" is problematic on Linux as well (due to the pip/pip3 split at
the system level). Hence this section in the stdlib docs:
https://docs.python.org/3/installing/#work-with-multiple-versions-of-python-installed-in-parallel

> If we can't get PATH sorted out, we need to do something about this,
> IMO. I don't know what (believe me, I tried to find a solution)
> unfortunately.

I personally believe we should aim to make the "Windows" section in
the above link universal (i.e. working across *nix, Windows, and
virtual environments). That's the only one that can feasibly be made
universal - all the other alternatives are already known to be
incompatible with particular scenarios.

It's a fair bit of work to make it happen though, so it will likely
remain a "wish list" item unless someone gets particularly inspired to
do something about it :)

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] New Windows installer for Python 3.5

2015-01-06 Thread Paul Moore 
On 6 January 2015 at 13:56, Nick Coghlan  wrote:
>> If we can't get PATH sorted out, we need to do something about this,
>> IMO. I don't know what (believe me, I tried to find a solution)
>> unfortunately.
>
> I personally believe we should aim to make the "Windows" section in
> the above link universal (i.e. working across *nix, Windows, and
> virtual environments). That's the only one that can feasibly be made
> universal - all the other alternatives are already known to be
> incompatible with particular scenarios.

Making it the universally recommended approach is one thing. Getting
people to actually work that way is another thing entirely :-(

Also, the "Windows recommendation" (currently) doesn't work properly
with virtualenv - there's no way to get py.exe to use "the currently
active virtualenv" (i.e., the default version from PATH). It should be
possible to fix this - the difficulty is likely to be designing a
viable interface.

As a first cut, I think py.exe should default to (in the following order):

1. The first version of Python on PATH that "looks like a virtualenv"
(need to consider both venv and virtualenv styles).
2. The default version of Python set in the ini file.
3. The latest version of Python installed on the machine (no longer
preferring Python 2 over Python 3!)

A #! line in a script being run will override all of these, of course,
as will explicit command line flags.

Does this seem reasonable? I could work on a patch if it does.

Paul
___
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] New Windows installer for Python 3.5

2015-01-06 Thread Antoine Pitrou 
On Tue, 6 Jan 2015 23:56:30 +1000
Nick Coghlan  wrote:

> On 5 January 2015 at 18:17, Paul Moore  wrote:
> > On 5 January 2015 at 01:20, Steve Dower  wrote:
> >> I think this means the best way to make multiple versions work properly is 
> >> to rename python.exe to python3.5.exe, then install the launcher as 
> >> python.exe and python3.exe (with some logic to look at its own name) so it 
> >> can resolve the right version. Maybe we can even extend the launcher to 
> >> resolve launchers in Scripts (pip.exe, etc.) and have consistent rules 
> >> there too?
> >
> > This was a big debate over on distutils-sig. I advocated "py -m pip"
> > for portable use, but got basically nowhere. People want "pip" to
> > work, for compatibility with Unix (and hence ease of documentation).
> 
> "pip" is problematic on Linux as well (due to the pip/pip3 split at
> the system level). Hence this section in the stdlib docs:
> https://docs.python.org/3/installing/#work-with-multiple-versions-of-python-installed-in-parallel

Why doesn't it recommend "pip3.4", etc. instead? Am I missing something
about it?

Thanks

Antoine.


___
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] Issue 22619 at bugs.python.org

2015-01-06 Thread Mason Hill 
Thank you for pointing this out. That's what I meant when I asked to
"say what's wrong with it " :-) I fixed the latest patch and uploaded
it.

On Tue, Jan 6, 2015 at 7:48 AM, Stefan Ring  wrote:
> On Tue, Jan 6, 2015 at 8:52 AM, Dmitry Kazakov  wrote:
>> Greetings.
>>
>> I'm sorry if I'm too insistent, but it's not truly rewarding to
>> constantly improve a patch that no one appears to need. Again, I
>> understand people are busy working and/or reviewing critical patches,
>> but 2 months of inactivity is not right. Yes, I posted a message
>> yesterday, but no one seemed to be bothered. In any case, I'll respect
>> your decision about this patch and will never ask for a review of this
>> patch again.
>
> The later patches seem to miss the Mercurial header that would allow
> the integrated review functionality on bugs.python.org to kick in (I
> presume) and thus make it much easier to review.
___
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] New Windows installer for Python 3.5

2015-01-06 Thread Nick Coghlan 
On 7 January 2015 at 00:12, Antoine Pitrou  wrote:
> On Tue, 6 Jan 2015 23:56:30 +1000
> Nick Coghlan  wrote:
>> "pip" is problematic on Linux as well (due to the pip/pip3 split at
>> the system level). Hence this section in the stdlib docs:
>> https://docs.python.org/3/installing/#work-with-multiple-versions-of-python-installed-in-parallel
>
> Why doesn't it recommend "pip3.4", etc. instead? Am I missing something
> about it?

Those assume a pip-binary-per-Python-implementation model which isn't
a valid assumption once Jython, PyPy, etc come into consideration.
Indirecting through the Python implementation name helps ensure
compatibility with a wider range of scenarios.

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] python 2.7.9 regression in argparse?

2015-01-06 Thread Terry Reedy 

On 1/6/2015 7:39 AM, Victor Stinner wrote:

More context:

2014-12-19 12:43 GMT+01:00 anatoly techtonik :

https://github.com/nickstenning/honcho/pull/121


The link mentions the following changeset:
---
changeset:   93122:1a3143752db2
branch:  2.7
parent:  93112:927cca0b9337
user:R David Murray 
date:Fri Oct 17 20:07:08 2014 -0400
files:   Lib/argparse.py Lib/test/test_argparse.py Misc/NEWS
description:
#9351: set_defaults on subparser is no longer ignored if set on parent.

Before, if a default was set on the parent parser, any default for that
variable set via set_defaults on a subparser would be ignored.  Now
the subparser set_defaults is honored.

Patch by Jyrki Pullianinen.


diff -r 927cca0b9337 -r 1a3143752db2 Lib/argparse.py
--- a/Lib/argparse.py   Fri Oct 17 16:20:15 2014 -0500
+++ b/Lib/argparse.py   Fri Oct 17 20:07:08 2014 -0400
@@ -1089,7 +1089,14 @@ class _SubParsersAction(Action):
  # parse all the remaining options into the namespace
  # store any unrecognized options on the object, so that the top
  # level parser can decide what to do with them
-namespace, arg_strings = parser.parse_known_args(arg_strings,
namespace)
+
+# In case this subparser defines new defaults, we parse them
+# in a new namespace object and then update the original
+# namespace for the relevant parts.
+subnamespace, arg_strings = parser.parse_known_args(arg_strings, None)
+for key, value in vars(subnamespace).items():
+setattr(namespace, key, value)
+
  if arg_strings:
  vars(namespace).setdefault(_UNRECOGNIZED_ARGS_ATTR, [])
  getattr(namespace, _UNRECOGNIZED_ARGS_ATTR).extend(arg_strings)
---

Which is related to http://bugs.python.org/issue9351

Maybe argparse just became more strict? I don't understand the issue.


Steven Bethard, the argparse maintainer, defined the old behavior of 
ignoring subparser defaults (where there are also top level defaults) as 
a bug "counter to what people probably expect".  If the old behavior had 
been documented, changing it in a bug-fix release would have been a 
mistake.  But looking at the patch, the doc seems to have been silent on 
the issue.


This is not the first time someone considered a 'bug fix' to be a 
'regression', which it might be from their viewpoint.  The last comment 
on the github thread suggests that an easy fix was found.


--
Terry Jan Reedy

___
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] python 2.7.9 regression in argparse?

2015-01-06 Thread Guido van Rossum 
There's an obligatory XKCD reference for this: http://xkcd.com/1172/

On Tue, Jan 6, 2015 at 12:25 PM, Terry Reedy  wrote:

> On 1/6/2015 7:39 AM, Victor Stinner wrote:
>
>> More context:
>>
>> 2014-12-19 12:43 GMT+01:00 anatoly techtonik :
>>
>>> https://github.com/nickstenning/honcho/pull/121
>>>
>>
>> The link mentions the following changeset:
>> ---
>> changeset:   93122:1a3143752db2
>> branch:  2.7
>> parent:  93112:927cca0b9337
>> user:R David Murray 
>> date:Fri Oct 17 20:07:08 2014 -0400
>> files:   Lib/argparse.py Lib/test/test_argparse.py Misc/NEWS
>> description:
>> #9351: set_defaults on subparser is no longer ignored if set on parent.
>>
>> Before, if a default was set on the parent parser, any default for that
>> variable set via set_defaults on a subparser would be ignored.  Now
>> the subparser set_defaults is honored.
>>
>> Patch by Jyrki Pullianinen.
>>
>>
>> diff -r 927cca0b9337 -r 1a3143752db2 Lib/argparse.py
>> --- a/Lib/argparse.py   Fri Oct 17 16:20:15 2014 -0500
>> +++ b/Lib/argparse.py   Fri Oct 17 20:07:08 2014 -0400
>> @@ -1089,7 +1089,14 @@ class _SubParsersAction(Action):
>>   # parse all the remaining options into the namespace
>>   # store any unrecognized options on the object, so that the top
>>   # level parser can decide what to do with them
>> -namespace, arg_strings = parser.parse_known_args(arg_strings,
>> namespace)
>> +
>> +# In case this subparser defines new defaults, we parse them
>> +# in a new namespace object and then update the original
>> +# namespace for the relevant parts.
>> +subnamespace, arg_strings = parser.parse_known_args(arg_strings,
>> None)
>> +for key, value in vars(subnamespace).items():
>> +setattr(namespace, key, value)
>> +
>>   if arg_strings:
>>   vars(namespace).setdefault(_UNRECOGNIZED_ARGS_ATTR, [])
>>   getattr(namespace, _UNRECOGNIZED_ARGS_ATTR).
>> extend(arg_strings)
>> ---
>>
>> Which is related to http://bugs.python.org/issue9351
>>
>> Maybe argparse just became more strict? I don't understand the issue.
>>
>
> Steven Bethard, the argparse maintainer, defined the old behavior of
> ignoring subparser defaults (where there are also top level defaults) as a
> bug "counter to what people probably expect".  If the old behavior had been
> documented, changing it in a bug-fix release would have been a mistake.
> But looking at the patch, the doc seems to have been silent on the issue.
>
> This is not the first time someone considered a 'bug fix' to be a
> 'regression', which it might be from their viewpoint.  The last comment on
> the github thread suggests that an easy fix was found.
>
> --
> Terry Jan Reedy
>
>
> ___
> 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] python 2.7.9 regression in argparse?

2015-01-06 Thread Ryan Gonzalez 
I thought of this exact comment when I read the "bug fix considered a
regression."

On Tue, Jan 6, 2015 at 2:41 PM, Guido van Rossum  wrote:

> There's an obligatory XKCD reference for this: http://xkcd.com/1172/
>
> On Tue, Jan 6, 2015 at 12:25 PM, Terry Reedy  wrote:
>
>> On 1/6/2015 7:39 AM, Victor Stinner wrote:
>>
>>> More context:
>>>
>>> 2014-12-19 12:43 GMT+01:00 anatoly techtonik :
>>>
 https://github.com/nickstenning/honcho/pull/121

>>>
>>> The link mentions the following changeset:
>>> ---
>>> changeset:   93122:1a3143752db2
>>> branch:  2.7
>>> parent:  93112:927cca0b9337
>>> user:R David Murray 
>>> date:Fri Oct 17 20:07:08 2014 -0400
>>> files:   Lib/argparse.py Lib/test/test_argparse.py Misc/NEWS
>>> description:
>>> #9351: set_defaults on subparser is no longer ignored if set on parent.
>>>
>>> Before, if a default was set on the parent parser, any default for that
>>> variable set via set_defaults on a subparser would be ignored.  Now
>>> the subparser set_defaults is honored.
>>>
>>> Patch by Jyrki Pullianinen.
>>>
>>>
>>> diff -r 927cca0b9337 -r 1a3143752db2 Lib/argparse.py
>>> --- a/Lib/argparse.py   Fri Oct 17 16:20:15 2014 -0500
>>> +++ b/Lib/argparse.py   Fri Oct 17 20:07:08 2014 -0400
>>> @@ -1089,7 +1089,14 @@ class _SubParsersAction(Action):
>>>   # parse all the remaining options into the namespace
>>>   # store any unrecognized options on the object, so that the top
>>>   # level parser can decide what to do with them
>>> -namespace, arg_strings = parser.parse_known_args(arg_strings,
>>> namespace)
>>> +
>>> +# In case this subparser defines new defaults, we parse them
>>> +# in a new namespace object and then update the original
>>> +# namespace for the relevant parts.
>>> +subnamespace, arg_strings = parser.parse_known_args(arg_strings,
>>> None)
>>> +for key, value in vars(subnamespace).items():
>>> +setattr(namespace, key, value)
>>> +
>>>   if arg_strings:
>>>   vars(namespace).setdefault(_UNRECOGNIZED_ARGS_ATTR, [])
>>>   getattr(namespace, _UNRECOGNIZED_ARGS_ATTR).
>>> extend(arg_strings)
>>> ---
>>>
>>> Which is related to http://bugs.python.org/issue9351
>>>
>>> Maybe argparse just became more strict? I don't understand the issue.
>>>
>>
>> Steven Bethard, the argparse maintainer, defined the old behavior of
>> ignoring subparser defaults (where there are also top level defaults) as a
>> bug "counter to what people probably expect".  If the old behavior had been
>> documented, changing it in a bug-fix release would have been a mistake.
>> But looking at the patch, the doc seems to have been silent on the issue.
>>
>> This is not the first time someone considered a 'bug fix' to be a
>> 'regression', which it might be from their viewpoint.  The last comment on
>> the github thread suggests that an easy fix was found.
>>
>> --
>> Terry Jan Reedy
>>
>>
>> ___
>> 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/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] Any volunteers to implement PEP 479?

2015-01-06 Thread Guido van Rossum 
There's a proof of concept patch in http://bugs.python.org/issue22906, but
it doesn't have the __future__ import and probably gets other details wrong.

Reference:
PEP 479 -- Change StopIteration handling inside generators


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