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

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

Re: [Python-Dev] (no subject)

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.

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

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

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 syst

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] [Python-checkins] cpython: Update copyright.

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

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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 i

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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 Studi

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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 diff

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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 b

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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 Py

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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 exis

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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 d

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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,

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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 versio

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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 wh

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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

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 hop

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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 chang

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

Re: [Python-Dev] (no subject)

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"

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

[Python-Dev] PEP 370 - per-user scripts directory on Windows

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 o

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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). I

Re: [Python-Dev] (no subject)

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 __

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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 a

Re: [Python-Dev] (no subject)

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 mailin

Re: [Python-Dev] (no subject)

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 developme