Re: [Python-Dev] (no subject)

[Victor Stinner]

Le 10 févr. 2015 06:48, "Greg Ewing"  a écrit :
> It could potentially be a little more efficient by
> eliminating the construction of an intermediate list.

Is it the case in the implementation? If it has to create a temporary
list/tuple, I will prefer to not use it.

After long years of development, I chose to limit myself to one instruction
per line. It is for different reason:
- I spend more time to read code than to write code, readability matters
- it's easier to debug: most debugger work line by line, or at least it's a
convinient way to use them. If you use instruction per instruction, usually
you have to read assember/bytecode to get the current instruction
- profilers computes statistics per line,not per instruction (it's also the
case for tracemalloc)
- tracebacks only give the line number, not the column
- etc.

So I now prefer more verbise code even it is longer to write and may look
less efficient.

> Same again, multiple ** avoids construction of an
> itermediate dict.

Again, is it the case in the implementation. It may be possible to modify
CPython to really avoid a temporary dict (at least for some kind of Python
functions), but it would a large refactoring.

Usually, if an operation is not efficient, it's not implement, so users
don't try to use it and may even try to write their code differently (to
avoid the performance issue).

(But slow operations exist like list.remove.)

Victor
___
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] (no subject)

[Serhiy Storchaka]

On 10.02.15 04:06, Ethan Furman wrote:

 return func(*(args + fargs), **{**keywords, **fkeywords})


We don't use [*args, *fargs] for concatenating lists, but args + fargs. 
Why not use "+" or "|" operators for merging dicts?



___
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] (no subject)

[Antoine Pitrou]

On Tue, 10 Feb 2015 19:04:03 +1300
Greg Ewing  wrote:
> Donald Stufft wrote:
> > 
> > perhaps a better 
> > solution is to simply make it so that something like ``a_list + 
> > an_iterable`` is valid and the iterable would just be consumed and +’d 
> > onto the list.
> 
> I don't think I like the asymmetry that this would
> introduce into + on lists. Currently
> 
> [1, 2, 3] + (4, 5, 6)
> 
> is an error because it's not clear whether the
> programmer intended the result to be a list or
> a tuple.

>>> bytearray(b"a") + b"bc"
bytearray(b'abc')
>>> b"a" + bytearray(b"bc")
b'abc'

It's quite convenient. In many contexts lists and tuples are quite
interchangeable (for example when unpacking).

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] (no subject)

[Antoine Pitrou]

On Mon, 09 Feb 2015 18:06:02 -0800
Ethan Furman  wrote:
> On 02/09/2015 05:14 PM, Victor Stinner wrote:
> > 
> > def partial(func, *args, **keywords):
> > def newfunc(*fargs, **fkeywords):
> > return func(*(args + fargs), **keywords, **fkeywords)
> > ...
> > return newfunc
> > 
> > The new code behaves differently since Neil said that an error is
> > raised if fkeywords and keywords have keys in common. By the way, this
> > must be written in the PEP.
> 
> 
> That line should read
> 
> return func(*(args + fargs), **{**keywords, **fkeywords})
> 
> to avoid the duplicate key error and keep the original functionality.

While losing readability. What's the point exactly?
One line over 112055 (as shown by Victor) can be collapsed away?
Wow, that's sure gonna change Python programming in a massively
beneficial way...

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] (no subject)

[Terry Reedy]

On 2/9/2015 7:29 PM, Neil Girdhar wrote:

For some reason I can't seem to reply using Google groups, which is is
telling "this is a read-only mirror" (anyone know why?)


I presume spam prevention.  Most spam on python-list comes from the 
read-write GG mirror.


--
Terry Jan Reedy

___
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] (no subject)

[Paul Moore]

On 10 February 2015 at 00:29, Neil Girdhar  wrote:
>> > function(**kw_arguments, **more_arguments)
>> If the key "key1" is in both dictionaries, more_arguments wins, right?
>
>
> There was some debate and it was decided that duplicate keyword arguments
> would remain an error (for now at least).  If you want to merge the
> dictionaries with overriding, then you can still do:
>
> function(**{**kw_arguments, **more_arguments})
>
> because **-unpacking in dicts overrides as you guessed.

Eww. Seriously, function(**{**kw_arguments, **more_arguments}) feels
more like a Perl "executable line noise" construct than anything I'd
ever want to see in Python. And taking something that doesn't work and
saying you can make it work by wrapping **{...} round it just seems
wrong.

Paul
___
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] (no subject)

[Paul Moore]

On 10 February 2015 at 01:48, Donald Stufft  wrote:
> I am really really -1 on the comprehension syntax.

[... omitting because gmail seems to have messed up the quoting ...]

> I don’t think * means “loop” anywhere else in Python and I would never
> “guess” that [*item for item in iterable] meant that. It’s completely non
> intuitive. Anywhere else you see *foo it’s unpacking a tuple not making an
> inner loop. That means that anywhere else in Python *item is the same thing
> as item[0], item[1], item[2], …, but this PEP makes it so just inside of a
> comprehension it actually means “make a second, inner loop” instead of what
> I think anyone who has learned that syntax would expect, which is it should
> be equivalent to [(item[0], item[1], item[2], …) for item in iterable].

I agree completely with Donald here. The comprehension syntax has
consistently been the part of the proposal that has resulted in
confused questions from reviewers, and I don't think it's at all
intuitive.

Is it allowable to vote on parts of the PEP separately? If not, then
the comprehension syntax is enough for me to reject the whole
proposal. If we can look at parts in isolation, I'm OK with saying -1
to the comprehension syntax and then we can look at whether the other
parts of the PEP add enough to be worth it (the comprehension side is
enough of a distraction that I haven't really considered the other
bits yet).

Paul
___
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] PEP 370 - per-user scripts directory on Windows

[Paul Moore]

tl;dr - Having a shared per-user scripts directory on Windows
(%APPDATA%/Python/Scripts) causes a number of potential issues when
users install the same package in multiple Python versions. I'd like
to suggest that this be changed to a versioned directory
(%APPDATA%/PythonXY/Scripts) to match all other Python directories on
Windows.

This issue originally started as a discussion on the pip tracker
around making --user the default for pip. See
https://github.com/pypa/pip/issues/1668 for details. However, because
the user scripts directory is shared across all Python versions, this
poses a number of issues:

1. If we "pip install" something like pytest, which version gets the
name "py.test.exe" works on a "last install wins" basis, which is not
ideal.
2. The above behaviour (and more generally the shared site scripts
directory) does not respect the user's "Make this my default Python"
choice from the installer, in potentially surprising ways.
3. Uninstalling a package which has been installed in 2 pythons will
likely fail, because either the checksum of an installed script does
not match what's in the RECORD file, or because a file that should be
present has already been uninstalled via a different Python version
[1].

I suggest that the per-user scripts directory should be versioned, in
exactly the same way as every other Python-related directory on
Windows. So we would have %APPDATA%\PythonXY\Scripts alongside
%APPDATA%\PythonXY\site-packages. This is a familiar pattern for
Windows users, and should not cause significant confusion.

It would be good to get this added for Python 3.5, *before* making
user installs the default (needed for 3.5 as the default install
location for 3.5 will need admin privileges to write).

Some additional points:

1. This is a Windows-specific proposal, because Unix has always had
scripts installed in a common location (e.g., /usr/local/bin) and
commonly-understood solutions already exist on that platform
(versioned command names, python -m, system package management, etc).
However, these solutions would be a significant change for Windows
users.

2. Packages which recommend a user install specifically so that their
commands are available regardless of which Python is on PATH would
have to find an alternative solution. I doubt there are many such
packages, but this should be considered.

3. This proposal does not affect the Python launcher for Windows.
People using the launcher exclusively may be currently using "py -m
pip" (or whatever) to launch applications, in which case the change of
user script directory won't affect them.

4. I am not aware of any tools that rely on the location of the user
scripts directory. Such scripts should be using sysconfig in any case.

5. The problems mentioned exist in current Python versions, but
haven't been flagged up, presumably because very few people use the
user install location - precisely because it's not the default in pip.
Changing the pip default would cause more people to encounter the
issues, but I don't propose backporting this change, as it's not a bug
fix. If it becomes a major issue for pip users on older versions, we
can either reconsider this, or pip can decide on its own workaround.

Comments? If this is acceptable, I would be willing to prepare a patch
for Python 3.5 implementing this.

Paul

[1] Checking of checksums is not currently implemented, AFAIK, but it
is the purpose of the checksums in the RECORD file, and could be
implemented in future versions of pip.
___
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] (no subject)

[Nick Coghlan]

On 10 Feb 2015 19:24, "Terry Reedy"  wrote:
>
> On 2/9/2015 7:29 PM, Neil Girdhar wrote:
>>
>> For some reason I can't seem to reply using Google groups, which is is
>> telling "this is a read-only mirror" (anyone know why?)
>
>
> I presume spam prevention.  Most spam on python-list comes from the
read-write GG mirror.

There were also problems with Google Groups getting the reply-to headers
wrong (so if someone flipped the mirror to read-only: thank you!)

With any luck, we'll have a native web gateway later this year after
Mailman 3 is released, so posting through Google Groups will be less
desirable.

Cheers,
Nick.

>
> --
> Terry Jan Reedy
>
>
> ___
> 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] (no subject)

[Eli Bendersky]

On Tue, Feb 10, 2015 at 1:33 AM, Paul Moore  wrote:

> On 10 February 2015 at 00:29, Neil Girdhar  wrote:
> >> > function(**kw_arguments, **more_arguments)
> >> If the key "key1" is in both dictionaries, more_arguments wins, right?
> >
> >
> > There was some debate and it was decided that duplicate keyword arguments
> > would remain an error (for now at least).  If you want to merge the
> > dictionaries with overriding, then you can still do:
> >
> > function(**{**kw_arguments, **more_arguments})
> >
> > because **-unpacking in dicts overrides as you guessed.
>
> Eww. Seriously, function(**{**kw_arguments, **more_arguments}) feels
> more like a Perl "executable line noise" construct than anything I'd
> ever want to see in Python. And taking something that doesn't work and
> saying you can make it work by wrapping **{...} round it just seems
> wrong.
>

+1 to this and similar reasoning

I find the syntax proposed in PEP 448 incredibly obtuse, and I don't think
it's worth it. Python has never placed terseness of expression as its
primary goal, but this is mainly what the PEP is aiming at. -1 on the PEP
for me, at least in its current form.

Eli
___
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] (no subject)

[Antoine Pitrou]

On Tue, 10 Feb 2015 23:16:38 +1000
Nick Coghlan  wrote:
> On 10 Feb 2015 19:24, "Terry Reedy"  wrote:
> >
> > On 2/9/2015 7:29 PM, Neil Girdhar wrote:
> >>
> >> For some reason I can't seem to reply using Google groups, which is is
> >> telling "this is a read-only mirror" (anyone know why?)
> >
> >
> > I presume spam prevention.  Most spam on python-list comes from the
> read-write GG mirror.
> 
> There were also problems with Google Groups getting the reply-to headers
> wrong (so if someone flipped the mirror to read-only: thank you!)
> 
> With any luck, we'll have a native web gateway later this year after
> Mailman 3 is released, so posting through Google Groups will be less
> desirable.

There is already a Web and NNTP gateway with Gmane:
http://news.gmane.org/gmane.comp.python.devel

No need to rely on Google's mediocre services.

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] (no subject)

[Nick Coghlan]

On 10 Feb 2015 19:41, "Paul Moore"  wrote:
>
> I agree completely with Donald here. The comprehension syntax has
> consistently been the part of the proposal that has resulted in
> confused questions from reviewers, and I don't think it's at all
> intuitive.
>
> Is it allowable to vote on parts of the PEP separately? If not, then
> the comprehension syntax is enough for me to reject the whole
> proposal. If we can look at parts in isolation, I'm OK with saying -1
> to the comprehension syntax and then we can look at whether the other
> parts of the PEP add enough to be worth it (the comprehension side is
> enough of a distraction that I haven't really considered the other
> bits yet).

It occurs to me that the PEP effectively changes the core of a generator
expression from "yield x" to "yield from x" if the tuple expansion syntax
is used. If we rejected the "yield *x" syntax for standalone yield
expressions, I don't think it makes sense to now add it for generator
expressions.

So I guess that adds me to the -1 camp on the comprehension/generator
expression part of the story - it doesn't make things all that much easier
to write than the relevant nested loop, and it makes them notably harder to
read.

I haven't formed an opinion on the rest of the PEP yet, as it's been a
while since I read the full text. I'll read through the latest version
tomorrow.

Regards,
Nick.

>
> Paul
> ___
> 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] PEP 370 - per-user scripts directory on Windows

[Nick Coghlan]

On 10 Feb 2015 22:40, "Paul Moore"  wrote:
>
> tl;dr - Having a shared per-user scripts directory on Windows
> (%APPDATA%/Python/Scripts) causes a number of potential issues when
> users install the same package in multiple Python versions. I'd like
> to suggest that this be changed to a versioned directory
> (%APPDATA%/PythonXY/Scripts) to match all other Python directories on
> Windows.
>
> This issue originally started as a discussion on the pip tracker
> around making --user the default for pip. See
> https://github.com/pypa/pip/issues/1668 for details.

For the reasons Paul gives, I'm personally +1 on making the change.

I was actually surprised it didn't already work that way, given that almost
everything else on Windows is version specific.

Cheers,
Nick.
___
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] (no subject)

[Mark Lawrence]

On 10/02/2015 13:23, Antoine Pitrou wrote:

On Tue, 10 Feb 2015 23:16:38 +1000
Nick Coghlan  wrote:

On 10 Feb 2015 19:24, "Terry Reedy"  wrote:


On 2/9/2015 7:29 PM, Neil Girdhar wrote:


For some reason I can't seem to reply using Google groups, which is is
telling "this is a read-only mirror" (anyone know why?)



I presume spam prevention.  Most spam on python-list comes from the

read-write GG mirror.

There were also problems with Google Groups getting the reply-to headers
wrong (so if someone flipped the mirror to read-only: thank you!)

With any luck, we'll have a native web gateway later this year after
Mailman 3 is released, so posting through Google Groups will be less
desirable.


There is already a Web and NNTP gateway with Gmane:
http://news.gmane.org/gmane.comp.python.devel

No need to rely on Google's mediocre services.

Regards

Antoine.



Highly recommended as effectively zero spam.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
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] PEP 370 - per-user scripts directory on Windows

[Paul Moore]

On 10 February 2015 at 13:34, Nick Coghlan  wrote:
> I was actually surprised it didn't already work that way, given that almost
> everything else on Windows is version specific.

That's actually a point I missed making. While I wouldn't class myself
as "typical", when I went looking for the user-scripts directory on my
machine, I automatically looked in %APPDATA%\PythonXY. I suspect that
many people would assume this was how it worked anyway, and be
surprised by the current behaviour.

Paul
___
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] PEP 370 - per-user scripts directory on Windows

[Steve Dower]

I was also surprised as I was working on the installer, so +1 on changing it.

The installer will also need some changes to add it to PATH, which should be 
fairly straightforward, but ping me if you need/want pointers. (It's checked in 
now, so I consider it fair game for anyone who wants to change it.)

Cheers,
Steve

Top-posted from my Windows Phone

From: Paul Moore
Sent: ‎2/‎10/‎2015 5:40
To: Nick Coghlan
Cc: Python Dev
Subject: Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

On 10 February 2015 at 13:34, Nick Coghlan  wrote:
> I was actually surprised it didn't already work that way, given that almost
> everything else on Windows is version specific.

That's actually a point I missed making. While I wouldn't class myself
as "typical", when I went looking for the user-scripts directory on my
machine, I automatically looked in %APPDATA%\PythonXY. I suspect that
many people would assume this was how it worked anyway, and be
surprised by the current behaviour.

Paul
___
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/steve.dower%40microsoft.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] PEP 370 - per-user scripts directory on Windows

[Paul Moore]

On 10 February 2015 at 14:13, Steve Dower  wrote:
> The installer will also need some changes to add it to PATH, which should be
> fairly straightforward, but ping me if you need/want pointers. (It's checked
> in now, so I consider it fair game for anyone who wants to change it.)

I was sort of hoping you'd be doing that independently, but never mind
:-) I'll give it a go and shout if I get stuck.

Paul
___
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] PEP 370 - per-user scripts directory on Windows

[Paul Moore]

On 10 February 2015 at 14:13, Steve Dower  wrote:
> I was also surprised as I was working on the installer, so +1 on changing
> it.

On a procedural note, does this require a change to the PEP (assuming
it's generally acceptable)? Or is a patch to the code and docs
sufficient?
Paul
___
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] PEP 370 - per-user scripts directory on Windows

[Steve Dower]

One of my main engineering concerns is lack of shared knowledge a.k.a. the 
truck factor (not CPython specific, btw, just every project I work on). So I'm 
always keen to get multiple people working on new code asap. I also prefer 
installers to be treated as part of the product and updated with whatever 
changes affect it, though that basically never happens in my experience :)

I assume the PEP will need updating if it specifies the exact path, and the 
installer readme may have a reference too. Presumably it'll only affect 3.5, as 
previous versions wouldn't use the directory for anything other than installing 
scripts.

Cheers,
Steve

Top-posted from my Windows Phone

From: Paul Moore
Sent: ‎2/‎10/‎2015 6:41
To: Steve Dower
Cc: Nick Coghlan; Python 
Dev
Subject: Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

On 10 February 2015 at 14:13, Steve Dower  wrote:
> The installer will also need some changes to add it to PATH, which should be
> fairly straightforward, but ping me if you need/want pointers. (It's checked
> in now, so I consider it fair game for anyone who wants to change it.)

I was sort of hoping you'd be doing that independently, but never mind
:-) I'll give it a go and shout if I get stuck.

Paul
___
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] PEP 370 - per-user scripts directory on Windows

[Paul Moore]

On 10 February 2015 at 12:38, Paul Moore  wrote:
> tl;dr - Having a shared per-user scripts directory on Windows
> (%APPDATA%/Python/Scripts) causes a number of potential issues when
> users install the same package in multiple Python versions. I'd like
> to suggest that this be changed to a versioned directory
> (%APPDATA%/PythonXY/Scripts) to match all other Python directories on
> Windows.

Making the full detail explicit (based on a comment made on the pip
issue), the default PATH should match the behaviour of sys.path (so
that "pip" and "python -m pip" always execute the same thing).

So we have C:\PythonXY before %APPDATA%\PythonXY\Scripts before
C:\PythonXY\Scripts (matching stdlib before user site-packages before
system site-packages). And user site-packages is versioned because
everything else is.

The PATH setting is purely an installer change, of course - only
versioning the user scripts directory affects the core.
Paul
___
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] PEP 370 - per-user scripts directory on Windows

[Martin v. Löwis]

Am 10.02.15 um 16:41 schrieb Steve Dower:
> One of my main engineering concerns is lack of shared knowledge a.k.a. the 
> truck factor (not CPython specific, btw, just every project I work on).

Wrt. the installer, I think this is a lost cause. IIUC, you aren't
really getting familiar with msi.py, and you are the one who has the
highest chances - so I was the only real maintainer of it.
Likewise, the Wise installer was only maintained by Tim Peters.

So chances are really high that you will be the only one making
substantial changes to the WiX files, although some people might learn
how to build the installer.

Regards,
Martin

___
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] PEP 370 - per-user scripts directory on Windows

[Steve Dower]

Martin v. Löwis wrote:
> Am 10.02.15 um 16:41 schrieb Steve Dower:
>> One of my main engineering concerns is lack of shared knowledge a.k.a. the
>> truck factor (not CPython specific, btw, just every project I work on).
> 
> Wrt. the installer, I think this is a lost cause. IIUC, you aren't really
> getting familiar with msi.py, and you are the one who has the highest chances 
> -
> so I was the only real maintainer of it.
> Likewise, the Wise installer was only maintained by Tim Peters.
> 
> So chances are really high that you will be the only one making substantial
> changes to the WiX files, although some people might learn how to build the
> installer.

Aww, come on. Let me have a little bit of hope ;)

> Regards,
> Martin
___
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] PEP 370 - per-user scripts directory on Windows

[Martin v. Löwis]

Am 10.02.15 um 15:43 schrieb Paul Moore:
> On 10 February 2015 at 14:13, Steve Dower  wrote:
>> I was also surprised as I was working on the installer, so +1 on changing
>> it.
> 
> On a procedural note, does this require a change to the PEP (assuming
> it's generally acceptable)? Or is a patch to the code and docs
> sufficient?

There should be a PEP if the change is likely controversial. In any
case, there should be documentation of the rationale for the change, and
the docs itself is the wrong place for it. The commit message could be
the right place, but if the rationale is a bit more verbose, a bug
tracker item would be right. All IMO, of course.

Martin


___
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] PEP 370 - per-user scripts directory on Windows

[Ethan Furman]

On 02/10/2015 04:38 AM, Paul Moore wrote:
>
> tl;dr - Having a shared per-user scripts directory on Windows
> (%APPDATA%/Python/Scripts) causes a number of potential issues when
> users install the same package in multiple Python versions. I'd like
> to suggest that this be changed to a versioned directory
> (%APPDATA%/PythonXY/Scripts) to match all other Python directories on
> Windows.

+1

--
~Ethan~ 



signature.asc
Description: OpenPGP digital signature
___
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] PEP 370 - per-user scripts directory on Windows

[Steve Dower]

So I've enumerated the problems with PATH on Windows before (and my subsequent 
dislike for modifying it through the installer), but here's the dot-point 
summary for those who haven't seen it.

* System-wide values always precede per-user values
* Most-recently-installed values always precede existing values (within the 
system/user separation above)
* It's impossible to specify per-user values from a system-wide installer
* The system-wide value has a length limit that silently breaks PATH if you 
exceed it
* It's difficult for users to modify PATH themselves (mostly due to bad UI in 
Windows)

The py.exe launcher solves many of these problems, but does not help with 
installed scripts. It's trivially easy to end up in a place where this would 
fail:

pip install --user spam
spam

The *only* case where this will work reliably (without manual user 
configuration) is where Python 3.5 is the only installed version on the 
machine, and it was installed by the current user just for them.

As we've seen from earlier discussions, the main beneficiaries of having Python 
on PATH are those using the command-line. Most scripts are going to make 
assumptions or work unnecessarily hard to find the actual location of the 
Python version they need.

My best idea for dealing with this is to add another script alongside the 
py.exe launcher called `activate-py`.[1] This script would take the same 
command-line version argument as py.exe and use it to update the current 
prompt's PATH correctly. Specifically, I expect the script would actually use 
py.exe to invoke the requested Python and get the paths directly from 
sysconfig, which will ensure that the order of precedence always matches.

Users would need to run `activate-py`, `activate-py -2` or `activate-py -3.5` 
(etc.) when they start their session.[2] This parallels venv's `activate` 
command, though because this would be a global command I believe the `-py` 
suffix is necessary. The example above becomes:

activate-py -3.5
pip install --user spam
spam

A `deactivate-py` command would also be added to revert the changes, though I 
don't expect that to be part of most workflows.

Another benefit is that shell scripts could call `activate-py` rather than 
trying to detect whether Python is already on the path or requiring a PYTHON 
variable to be set. (I seem to write these scripts all the time and know that 
I'd benefit from it.)

This is yet another attempt to try and change user behaviour, which I'm not 
thrilled about, but I'm really starting to feel that this is the best way out 
of a bad situation. It differs from the solutions used on Linux, though there 
may be some value in this approach there too. Thought/votes/suggestions?

Cheers,
Steve


[1]: Actually multiple scripts to handle cmd.exe/PowerShell, but this is an 
implementation detail. Users would simply type `activate-py` and the shells 
know which one to use.

[2]: We can easily add Start Menu shortcuts (e.g. "Python 3.5 (32-bit) Command 
Prompt") and run it for them, though that is not a critical part of this 
proposal.
___
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] PEP 370 - per-user scripts directory on Windows

[Paul Moore]

On 10 February 2015 at 12:38, Paul Moore  wrote:
> Comments? If this is acceptable, I would be willing to prepare a patch
> for Python 3.5 implementing this.

See http://bugs.python.org/issue23437

As yet untested, as I just realised I need to get Visual Studio 2015
installed to be able to build Python 3.5. I'll try to get that sorted
out, but I thought it would be worth putting the patch up anyway -
it's pretty simple.

Paul
___
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] PEP 370 - per-user scripts directory on Windows

[Paul Moore]

On 10 February 2015 at 17:45, Steve Dower  wrote:
> This is yet another attempt to try and change user behaviour, which I'm not 
> thrilled
> about, but I'm really starting to feel that this is the best way out of a bad 
> situation.
> It differs from the solutions used on Linux, though there may be some value 
> in this
> approach there too. Thought/votes/suggestions?

I have to admit, I agree with you. But before the "Add Python to PATH"
option was added to the installer, we repeatedly got requests for it
and it was apparently a constant source of confusion for beginners. If
we're going to revert that change, we'll need to be very careful how
we present 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] PEP 370 - per-user scripts directory on Windows

[Paul Moore]

On 10 February 2015 at 20:50, Paul Moore  wrote:
> On 10 February 2015 at 17:45, Steve Dower  wrote:
>> This is yet another attempt to try and change user behaviour, which I'm not 
>> thrilled
>> about, but I'm really starting to feel that this is the best way out of a 
>> bad situation.
>> It differs from the solutions used on Linux, though there may be some value 
>> in this
>> approach there too. Thought/votes/suggestions?
>
> I have to admit, I agree with you. But before the "Add Python to PATH"
> option was added to the installer, we repeatedly got requests for it
> and it was apparently a constant source of confusion for beginners. If
> we're going to revert that change, we'll need to be very careful how
> we present it.

Drat - hit "Send" too soon.

Also, the proposed scripts won't be on PATH, so users will have to run
them using explicit paths, which is both inconvenient and poses a
discoverability issue (Tools/scripts/win_add2path.py has been round
for ages, but AFAIK hardly anyone uses it). I wonder if there's a way
to get the launcher (py.exe) to help? For powershell, we could have
"py --setpath" write the appropriate path setting command to stdout,
and users could use "Invoke-Expression $(py --setpath)", for example.
That's a bit clumsy, and doesn't work for cmd.exe, but maybe there's
possibilities... Essentially, py.exe is the only command guaranteed to
be on PATH for any install (or is it? for a user install, is it stuck
somewhere in the user's APPDATA?)

It's fair enough to say that installers shouldn't be in the business
of messing with PATH, but nevertheless, people expect to run an
installer and have the installed programs available for use. Command
line utilities like Mercurial do it, so people will expect Python to.
Unfortunately.

Sorry, all problems, no real answers here.
Paul
___
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] PEP 370 - per-user scripts directory on Windows

[Mark Lawrence]

On 10/02/2015 20:47, Paul Moore wrote:

On 10 February 2015 at 12:38, Paul Moore  wrote:

Comments? If this is acceptable, I would be willing to prepare a patch
for Python 3.5 implementing this.


See http://bugs.python.org/issue23437

As yet untested, as I just realised I need to get Visual Studio 2015
installed to be able to build Python 3.5. I'll try to get that sorted
out, but I thought it would be worth putting the patch up anyway -
it's pretty simple.

Paul



Visual Studio 2013 is fine for building 3.5.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
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] PEP 370 - per-user scripts directory on Windows

[Steve Dower]

Paul Moore wrote:
> On 10 February 2015 at 20:50, Paul Moore  wrote:
>> On 10 February 2015 at 17:45, Steve Dower  wrote:
>>> This is yet another attempt to try and change user behaviour, which I'm not 
>>> thrilled
>>> about, but I'm really starting to feel that this is the best way out of a 
>>> bad situation.
>>> It differs from the solutions used on Linux, though there may be some value 
>>> in this
>>> approach there too. Thought/votes/suggestions?
>>
>> I have to admit, I agree with you. But before the "Add Python to PATH"
>> option was added to the installer, we repeatedly got requests for it
>> and it was apparently a constant source of confusion for beginners. If
>> we're going to revert that change, we'll need to be very careful how
>> we present it.
> 
> Drat - hit "Send" too soon.
> 
> Also, the proposed scripts won't be on PATH, so users will have to run
> them using explicit paths, which is both inconvenient and poses a
> discoverability issue (Tools/scripts/win_add2path.py has been round
> for ages, but AFAIK hardly anyone uses it). I wonder if there's a way
> to get the launcher (py.exe) to help? For powershell, we could have
> "py --setpath" write the appropriate path setting command to stdout,
> and users could use "Invoke-Expression $(py --setpath)", for example.
> That's a bit clumsy, and doesn't work for cmd.exe, but maybe there's
> possibilities... Essentially, py.exe is the only command guaranteed to
> be on PATH for any install (or is it? for a user install, is it stuck
> somewhere in the user's APPDATA?)

(For a user install, I've guaranteed that the launcher will be added to the
user's PATH. But a system-wide launcher will win.)

win_add2path.py does the same thing as the installer, so it isn't a useful
solution.

The `py --setpath` is basically my idea with `activate-py`, though with the
"Invoke-Expression" part handled in the script (and not actually using
Invoke-Expression, but that's implementation details). If these are part of the
launcher, then they'll always be on PATH, and if they're just thin wrappers
around py.exe then they can support all the same versions of Python (in effect,
all of them, though with the 32/64-bit per-user collisions that existed
pre-3.5).

> It's fair enough to say that installers shouldn't be in the business
> of messing with PATH, but nevertheless, people expect to run an
> installer and have the installed programs available for use. Command
> line utilities like Mercurial do it, so people will expect Python to.
> Unfortunately.

And Python does, as long as that installed program is "py". The problem is that
people expect "python" to be there and be the correct one (for a totally
arbitrary definition of "correct") as well as pip, easy_install and anything
installed by those two tools, whether they were installed for all users or just
the current one. It's far more complex than a single app (especially when you
realise that a system-wide install is effectively trying to make Python look
like part of the OS - we only get that about 50% right now...).

> Sorry, all problems, no real answers here.
> Paul

Yeah, same. `activate-py` is the best I've got.

Cheers,
Steve
___
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] PEP 370 - per-user scripts directory on Windows

[Nick Coghlan]

On 11 Feb 2015 03:47, "Steve Dower"  wrote:
>
> This is yet another attempt to try and change user behaviour, which I'm
not thrilled about, but I'm really starting to feel that this is the best
way out of a bad situation. It differs from the solutions used on Linux,
though there may be some value in this approach there too.
Thought/votes/suggestions?

I don't think we have this problem solved on Linux either, we just have a
variety of workarounds in place of varying degrees of clunkiness :)

The thing I find attractive about this specific proposal is that we could
potentially expand it to Linux as well through appropriate use of
environment modules, and I expect that would also cover other POSIX systems.

So if you wanted to draft up an initial PEP with a concrete proposal
covering Windows systems, I'd be happy to tackle the task of getting the
same design to work on Linux (and hopefully POSIX in general) using
environment modules.

Cheers,
Nick.

>
> Cheers,
> Steve
>
>
> [1]: Actually multiple scripts to handle cmd.exe/PowerShell, but this is
an implementation detail. Users would simply type `activate-py` and the
shells know which one to use.
>
> [2]: We can easily add Start Menu shortcuts (e.g. "Python 3.5 (32-bit)
Command Prompt") and run it for them, though that is not a critical part of
this proposal.
> ___
> 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-checkins] cpython: Update copyright.

[Benjamin Peterson]

On Tue, Feb 10, 2015, at 23:37, raymond.hettinger wrote:
> https://hg.python.org/cpython/rev/7d826a6b92a1
> changeset:   94582:7d826a6b92a1
> user:Raymond Hettinger 
> date:Tue Feb 10 22:37:22 2015 -0600
> summary:
>   Update copyright.
> 
> files:
>   Modules/_collectionsmodule.c |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/Modules/_collectionsmodule.c b/Modules/_collectionsmodule.c
> --- a/Modules/_collectionsmodule.c
> +++ b/Modules/_collectionsmodule.c
> @@ -3,7 +3,7 @@
>  
>  /* collections module implementation of a deque() datatype
> Written and maintained by Raymond D. Hettinger 
> -   Copyright (c) 2004-2014 Python Software Foundation.
> +   Copyright (c) 2004-2015 Python Software Foundation.
> All rights reserved.
>  */

How about simply removing this line? The copyight years are well
documented in the LICENSE and README.txt, and it would save you the
trouble of keeping this up to date.
___
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] (no subject)

[Greg Ewing]

Donald Stufft wrote:


1. The statement *item is roughly the same thing as (item[0], item[1], item[n])


No, it's not -- that would make it equivalent to tuple(item),
which is not what it means in any of its existing usages.

What it *is* roughly equivalent to is

   item[0], item[1], item[n]

i.e. *without* the parens, whatever that means in the
context concerned. In the context of a function call,
it has the effect of splicing the sequence in as if
you had written each item out as a separate expression.

You do have a valid objection insofar as this currently
has no meaning at all in a comprehension, i.e. this
is a syntax error:

   [item[0], item[1], item[n] for item in items]

So we would be giving a meaning to something that
doesn't currently have a meaning, rather than changing
an existing meaning, if you see what I mean.

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

[Python-Dev] Problem running ./python -m test -v test_whatever

[Dwight]

  
  
Hi,
      I am primarily a user; but since I can not get a newer
  version
  of firefox for my system I have begun the very long process of
  
  trying to build a newer version of firefox for my system.
      I am using an IBM pSeries system running AIX 7.1.
      I am using gcc and IBM ld.
      All the modules I have built are being installed in a
  directory
  called /opt/alinux.  A lot of linux routines are stored in a
  directory
  called /opt/freeware and of course IBM has some version of
  their
  own which are installed in /usr...  Currently there is only
  one thing
  installed in /usr/local and that is clamscan.
      I have built and installed the tcl.8.6.3, tkl.8.6.3 and
  python 2.7.9 into
  /opt/aluinux.
      I am now trying to build and install python 3.4.2.  So far
  I
  have found a way to compile python successfully.  There are 
  only three features missing (_sqlite3, ossaudiodev and spwd).
      The configure command I ran was:
  ./configure --prefix=/opt/alinux
--exec-prefix=/opt/alinux --enable-shared  --with-system-ffi
--enable-ipv6 \
--with-tcltk-includes='-I/opt/alinux/include'
--with-tcltk-libs='-L/opt/alinux/lib' | tee MYconfig.log
  
      After running gmake test I found:
  Ran 509 tests in 47.407s
FAILED (errors=2, skipped=8)
Ran 49 tests in 0.065s
FAILED (failures=2, skipped=1)
Ran 34 tests in 0.320s
FAILED (errors=2, skipped=6)
Ran 80 tests in 1.040s
FAILED (errors=2, skipped=20)
Ran 10 tests in 0.366s
FAILED (failures=1, skipped=2)
Ran 506 tests in 28.860s
FAILED (failures=6, errors=5, skipped=83)
Ran 97 tests in 21.921s
FAILED (failures=9, skipped=3)
      I then tried to run  ./python -m test -v
  test_whatever
  and got the following error:
  $ pwd
/home/surfer/DownLoadLFNs/HTML/NEWS/BuildFirefox/Python-3.4.2
$ ls -la lib*
-rw-r--r--    1 surfer   Internet   19562608 Feb 10 20:02
libpython3.4m.a
-rwxr-xr-x    1 surfer   Internet   13331408 Feb 10 20:02
libpython3.4m.so
$ ./python -m test -v test_ssl
exec(): 0509-036 Cannot load program ./python because of the
following errors:
    0509-150   Dependent module libpython3.4m.so could not
be loaded.
    0509-022 Cannot load module libpython3.4m.so.
    0509-026 System error: A file or directory in the path
name does not exist.
      I would really appreciate some help in
  determining what I am doing wrong.
      As I said in the beginning I am primarily a user and not a
  developer.  I can solve
  some fairly simple problems; but that about it.
      I am guessing that there is some kind of linking problem;
  but I do not know
  how to solve this problem.
      I tried this:
  $
LDFLAGS=-L/home/surfer/DownLoadLFNs/HTML/NEWS/BuildFirefox/Python-3.4.2

$ export LDFLAGS
  and got the same results.
      
  

  


___
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] (no subject)

[Greg Ewing]

Victor Stinner wrote:
Le 10 févr. 2015 06:48, "Greg Ewing" > a écrit :

 > It could potentially be a little more efficient by
 > eliminating the construction of an intermediate list.

Is it the case in the implementation? If it has to create a temporary 
list/tuple, I will prefer to not use it.


The function call machinery will create a new tuple for
the positional args in any case. But if you manually
combine your * args into a tuple before calling, there
are *two* tuple allocations being done. Passing all the
* args directly into the call would allow one of them
to be avoided.

Similarly for dicts and ** args.

--
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] (no subject)

[Ian Lee]

+1 for adding "+" or "|" operator for merging dicts. To me this operation:

>>> {'x': 1, 'y': 2} + {'z': 3}
{'x': 1, 'y': 2, 'z': 3}

Is very clear.  The only potentially non obvious case I can see then is
when there are duplicate keys, in which case the syntax could just be
defined that last setter wins, e.g.:

>>> {'x': 1, 'y': 2} + {'x': 3}
{'x': 3, 'y': 2}

Which is analogous to the example:

new_dict = dict1.copy()
new_dict.update(dict2)


~ Ian Lee

On Tue, Feb 10, 2015 at 12:11 AM, Serhiy Storchaka 
wrote:

> On 10.02.15 04:06, Ethan Furman wrote:
>
>>  return func(*(args + fargs), **{**keywords, **fkeywords})
>>
>
> We don't use [*args, *fargs] for concatenating lists, but args + fargs.
> Why not use "+" or "|" operators for merging dicts?
>
>
>
> ___
> 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/
> ianlee1521%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] (no subject)

[Greg Ewing]

Antoine Pitrou wrote:

bytearray(b"a") + b"bc"


bytearray(b'abc')


b"a" + bytearray(b"bc")


b'abc'

It's quite convenient.


It's a bit disconcerting that the left operand wins,
rather than one of them being designated as the
"wider" type, as occurs with many other operations on
mixed types, e.g. int + float.

In any case, these seem to be special-case combinations.
It's not so promiscuous as to accept any old iterable
on the right:

>>> b"a" + [1,2,3]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't concat bytes to list
>>> [1,2,3] + b"a"
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can only concatenate list (not "bytes") to list

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

[Python-Dev] Binary concatenation (was Re: (no subject))

[Nick Coghlan]

On 11 February 2015 at 15:45, Greg Ewing  wrote:
> Antoine Pitrou wrote:
>
> bytearray(b"a") + b"bc"
>>
>>
>> bytearray(b'abc')
>>
> b"a" + bytearray(b"bc")
>>
>>
>> b'abc'
>>
>> It's quite convenient.
>
>
> It's a bit disconcerting that the left operand wins,
> rather than one of them being designated as the
> "wider" type, as occurs with many other operations on
> mixed types, e.g. int + float.
>
> In any case, these seem to be special-case combinations.
> It's not so promiscuous as to accept any old iterable
> on the right:

Binary concatenation accepts any bytes-like object (aka buffer API
implementing type), and it's the fact that both bytes and bytearray
interoperate with any bytes-like object that results in the "left
operand wins" behaviour when you use them together.

I don't believe we deliberately designed it that way, it's just an
inherent consequence of having both types implement concatenation
based on the buffer protocol rather than using any kind of type check.

If we *had* tried to define one of the two as encompassing the other,
then we would have also run into http://bugs.python.org/issue11477

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