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

Am 10.02.2015 um 18:45 schrieb Steve Dower: 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.

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

You're not alone, that's exactly how I do it too. I'm writing up a PEP for the activate-py command I suggested earlier that will temporarily set your PATH. If that goes well then we'll be able to ship that with the py.exe launcher (I'm particularly excited for batch files to be able to use it).

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

On 12 February 2015 at 08:05, Thomas Heller wrote: > Maybe I'm more or less alone with the way I work, but I don't like > python.exe on my PATH (and py.exe alloes me to do this). > I start python scripts from the command line either with 'script.py' > or 'py -3.4 script.py' or 'py -2.7 script.py'.

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

If venv's activate script sets it, I say go ahead and write it up. If it's just virtualenv, I'd rather not explicitly depend on it, especially since PEP 397's stated aim is file associations and not command line. I've been making changes to py.exe in hg.p.o, so I hope the standalone one is trac

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

On 12 February 2015 at 15:37, Steve Dower wrote: > If venv's activate script sets it, I say go ahead and write it up. If it's > just virtualenv, I'd rather not explicitly depend on it, especially since > PEP 397's stated aim is file associations and not command line. Yep, venv uses it too (see ht

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

Am 10.02.15 um 18:45 schrieb Steve Dower: > So I've enumerated the problems with PATH on Windows before (and my > subsequent dislike for modifying it through the installer) It's quite comforting to hear this - I was arguing against that addition for years (to the point of refusing to implement it

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

Paul Moore wrote: > > On 12 February 2015 at 15:37, Steve Dower wrote: >> If venv's activate script sets it, I say go ahead and write it up. If >> it's just virtualenv, I'd rather not explicitly depend on it, >> especially since PEP 397's stated aim is file associations and not command > line. >

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

Am 12.02.2015 um 15:46 schrieb Paul Moore: On 12 February 2015 at 08:05, Thomas Heller wrote: Maybe I'm more or less alone with the way I work, but I don't like python.exe on my PATH (and py.exe alloes me to do this). I start python scripts from the command line either with 'script.py' or 'py -

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

On 02/12/2015 12:05 AM, Thomas Heller wrote: > Could not py.exe be extended so that it allows starting scripts in a > somewhat similar way? 'py-script -2.7 myscript foo bar baz' ??? > Which would execute the script myscript.exe, myscript.bat, myscript.py, > myscript.cmd or whatever is in the Scri

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

On 12 February 2015 at 17:13, Thomas Heller wrote: >> This is how I worked for a long time after py.exe became available. >> But then I discovered virtualenv, and started using that, and needing >> to use 2 completely different command sets for "when I'm in a >> virtualenv" vs "when I'm not" becam

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

On 12 February 2015 at 17:39, Ethan Furman wrote: > I'm pretty sure py.exe should only start .py files, not .bat, .cmd, or > .anything-else. Agreed. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-

[Python-Dev] PEP 486: Make the Python Launcher aware of virtual environments

On 12 February 2015 at 14:46, Paul Moore wrote: > If py.exe detected when the environment variable VIRTUAL_ENV was set, > and used that virtualenv as the default Python rather than the > "system" python it normally used, this would be perfect. > > I think I'll write a PEP for this. Do people think

Re: [Python-Dev] PEP 486: Make the Python Launcher aware of virtual environments

Looks well thought-out. +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/pyt

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

On 12 February 2015 at 16:42, Steve Dower wrote: > None of my installer changes so far have had a PEP, and only a few people > have complained about that :) (it does have more documentation than I've ever > written for an installer before though) :-) You shouldn't bet on my judgement of what ne

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

On 2/12/2015 9:39 AM, Ethan Furman wrote: On 02/12/2015 12:05 AM, Thomas Heller wrote: Could not py.exe be extended so that it allows starting scripts in a somewhat similar way? 'py-script -2.7 myscript foo bar baz' ??? Which would execute the script myscript.exe, myscript.bat, myscript.py, my

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

On 02/12/2015 11:44 AM, Glenn Linderman wrote: > On 2/12/2015 9:39 AM, Ethan Furman wrote: >> On 02/12/2015 12:05 AM, Thomas Heller wrote: >> >>> Could not py.exe be extended so that it allows starting scripts in a >>> somewhat similar way? 'py-script -2.7 myscript foo bar baz' ??? >>> Which would

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

On 12 February 2015 at 20:11, Ethan Furman wrote: > I believe you are correct; however, as the PEP for the launcher stated [1] > "use as a general-purpose (aka non-python) > launcher is explicitly not supported". Yes, I once used it to start Perl scripts, just because it appealed to the perverse

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

On 12/02/2015 20:23, Paul Moore wrote: On 12 February 2015 at 20:11, Ethan Furman wrote: I believe you are correct; however, as the PEP for the launcher stated [1] "use as a general-purpose (aka non-python) launcher is explicitly not supported". Yes, I once used it to start Perl scripts, jus

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

> I've been making changes to py.exe in hg.p.o, so I hope the standalone one > is tracking. The msi for it as part of the official build can also > standalone, so maybe we should merge the two? > Hmm, sadly I don't think it is. Originally the standalone one was (I > believe) provided by Vinay for

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

- Original Message - From: Steve Dower > I believe are the purpose of those extensions. If "py.exe spam.pyz" > already works, I don't see any need for a PEP to add the association in > the installer. That would be my view, too. Regards, Vinay Sajip _

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

> Actually, I've just remembered, it's already in PEP 441, > which hasn't been approved but which goes further and > includes a stdlib tool to create pyz files. I'm not sure > if that changes things at all... Actually, I developed the pyzzer tool (which Paul may remember - he made some helpful su

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

On 12 February 2015 at 21:44, Vinay Sajip wrote: > Off to read the whole thread on python-dev now I'd also appreciate your views on the spin-off thread and PEP 486 ("Make the Python Launcher aware of virtual environments"). Paul ___ Python-Dev mailing

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

- Original Message - From: Paul Moore > I'd also appreciate your views on the spin-off thread and PEP 486 > ("Make the Python Launcher aware of virtual environments"). On an initial reading it seems quite reasonable. I'll sleep on it and see if any other things spring to mind. By the

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

Vinay Sajip wrote: > By the way, although I turned over the standalone launcher to pypa, I forked > that repo, and do development on my fork [1]. I remembered that I added a > feature (with the help of Pawel Jasinski) to allow e.g. py -ipy to pick a > command 'ipy' configured in the .ini file (this

[Python-Dev] subclassing builtin data structures

I suspect the last big hurdle to making built-in data structures nicely subclassable is the insistence of such types to return new instances as the base class instead of the derived class. In case that wasn't clear ;) --> class MyInt(int): ... def __repr__(self): ... return 'MyInt(%d)' % s

Re: [Python-Dev] subclassing builtin data structures

On Thu, Feb 12, 2015 at 4:36 PM, Ethan Furman wrote: > I suspect the last big hurdle to making built-in data structures nicely > subclassable is the insistence of such types to > return new instances as the base class instead of the derived class. > > In case that wasn't clear ;) > > --> class My

Re: [Python-Dev] subclassing builtin data structures

On 02/12/2015 04:55 PM, Guido van Rossum wrote: > On Thu, Feb 12, 2015 at 4:36 PM, Ethan Furman > wrote: > > I suspect the last big hurdle to making built-in data structures nicely > subclassable is the insistence of such types to > return new instances as the

Re: [Python-Dev] subclassing builtin data structures

On 2015-02-13 00:55, Guido van Rossum wrote: On Thu, Feb 12, 2015 at 4:36 PM, Ethan Furman mailto:et...@stoneleaf.us>> wrote: I suspect the last big hurdle to making built-in data structures nicely subclassable is the insistence of such types to return new instances as the base class

Re: [Python-Dev] subclassing builtin data structures

On 02/12/2015 05:46 PM, MRAB wrote: > On 2015-02-13 00:55, Guido van Rossum wrote: >> On Thu, Feb 12, 2015 at 4:36 PM, Ethan Furman > > wrote: >> >> I suspect the last big hurdle to making built-in data structures >> nicely subclassable is the insistence of such t

Re: [Python-Dev] subclassing builtin data structures

On Thu, Feb 12, 2015 at 7:55 PM, Guido van Rossum wrote: > the problem is that the base class (e.g. int) doesn't know how to > construct an instance of the subclass -- there is no reason (in general) > why the signature of a subclass constructor should match the base class > constructor, and it o

Re: [Python-Dev] subclassing builtin data structures

On Fri, Feb 13, 2015 at 12:46 PM, MRAB wrote: class BaseInt: > ... def __init__(self, value): > ... self._value = value > ... def __add__(self, other): > ... return type(self)(self._value + other) On Fri, Feb 13, 2015 at 11:55 AM, Guido van Rossum wrote: > ... there

Re: [Python-Dev] subclassing builtin data structures

On Thu, Feb 12, 2015 at 06:14:22PM -0800, Ethan Furman wrote: > On 02/12/2015 05:46 PM, MRAB wrote: > > On 2015-02-13 00:55, Guido van Rossum wrote: > >> Actually, the problem is that the base class (e.g. int) doesn't know how > >> to construct an instance of the subclass -- there is no reason (in

Re: [Python-Dev] subclassing builtin data structures

> On Feb 12, 2015, at 18:40, Chris Angelico wrote: > > On Fri, Feb 13, 2015 at 12:46 PM, MRAB wrote: > class BaseInt: >> ... def __init__(self, value): >> ... self._value = value >> ... def __add__(self, other): >> ... return type(self)(self._value + other) > >> O

Re: [Python-Dev] subclassing builtin data structures

On 02/12/2015 06:57 PM, Steven D'Aprano wrote: > On Thu, Feb 12, 2015 at 06:14:22PM -0800, Ethan Furman wrote: >> On 02/12/2015 05:46 PM, MRAB wrote: >>> On 2015-02-13 00:55, Guido van Rossum wrote: > Actually, the problem is that the base class (e.g. int) doesn't know how to construct a

Re: [Python-Dev] subclassing builtin data structures

On 02/12/2015 06:39 PM, Alexander Belopolsky wrote: > In my view, a constructor is no different from any other method. If the > designers of the subclass decided to change the > signature in an incompatible way, they should either override all methods > that create new objects or live with trac

Re: [Python-Dev] subclassing builtin data structures

On Thu, Feb 12, 2015 at 7:41 PM, Ethan Furman wrote: > On 02/12/2015 06:39 PM, Alexander Belopolsky wrote: > > > In my view, a constructor is no different from any other method. If the > designers of the subclass decided to change the > > signature in an incompatible way, they should either over

Re: [Python-Dev] subclassing builtin data structures

On 02/12/2015 08:01 PM, Guido van Rossum wrote: > On Thu, Feb 12, 2015 at 7:41 PM, Ethan Furman wrote: >> >> 2) always use the type of self when creating new instances >> >>cons: >> - if constructor signatures change, must override all methods which >>create new objec

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

Am 12.02.2015 um 18:39 schrieb Ethan Furman: On 02/12/2015 12:05 AM, Thomas Heller wrote: Could not py.exe be extended so that it allows starting scripts in a somewhat similar way? 'py-script -2.7 myscript foo bar baz' ??? Which would execute the script myscript.exe, myscript.bat, myscript.py,

Re: [Python-Dev] PEP 486: Make the Python Launcher aware of virtual environments

On 13 February 2015 at 05:47, Ethan Furman wrote: > Looks well thought-out. > > +1 I don't see any holes in the proposed behaviour either, so +1 from me. Procedurally, since it's a Windows specific change, and assuming Guido doesn't want to pronounce on this one himself, perhaps Steve Dower woul

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

On 13 February 2015 at 05:50, Paul Moore wrote: > On 12 February 2015 at 16:42, Steve Dower wrote: >> IIRC, there was a PEP for executing ZIP files directly (2.6-era?), which I >> believe are the purpose of those extensions. If "py.exe spam.pyz" already >> works, I don't see any need for a PEP