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

[Thomas Heller]

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.


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

I even like running scripts in this way:
'py -2.7 -m pip install whatever'.  However, this only works when the 
script also can be started as package.  Some packages allow this,

some don't.

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 Scripts directory on the Python 2.7
installation, without changing PATH presistently?

Thanks,
Thomas

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

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

Cheers,
Steve

Top-posted from my Windows Phone

From: Thomas Heller
Sent: ‎2/‎12/‎2015 0:03
To: python-dev@python.org
Subject: 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.

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

I even like running scripts in this way:
'py -2.7 -m pip install whatever'.  However, this only works when the
script also can be started as package.  Some packages allow this,
some don't.

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 Scripts directory on the Python 2.7
installation, without changing PATH presistently?

Thanks,
Thomas

___
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 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'.

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" became completely unusable.

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 it's a reasonable idea?

(On that note, is there any relationship between the py.exe shipped
with Python and the standalone version Vinay used to maintain but
which now appears to be hosted at
https://bitbucket.org/pypa/pylauncher? The two seem to be different,
for example the pypa version registers pyz/pyzw extensions).

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]

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 
tracking. The msi for it as part of the official build can also standalone, so 
maybe we should merge the two?

Top-posted from my Windows Phone

From: Paul Moore
Sent: ‎2/‎12/‎2015 6:48
To: Thomas Heller
Cc: Python Dev
Subject: 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'.

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" became completely unusable.

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 it's a reasonable idea?

(On that note, is there any relationship between the py.exe shipped
with Python and the standalone version Vinay used to maintain but
which now appears to be hosted at
https://bitbucket.org/pypa/pylauncher? The two seem to be different,
for example the pypa version registers pyz/pyzw extensions).

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 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
https://hg.python.org/cpython/file/9e10c4255277/Lib/venv/scripts/nt/activate.bat).

As people like Thomas (and me, until this issue stopped me :-)) are
using the launcher for command line use, I think it's fair to broaden
the scope to make command line usage more convenient. I agree that PEP
397 was originally focused mainly on file associations, but I think
it's worth looking beyond that now.

> 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 people using Pythons that didn't have
it bundled, and to add features (such as the new file extensions) on a
quicker timescale than Python releases. But since he passed it to the
pypa umbrella I don't think he's been keeping the two in sync. I've
copied him in case I'm completely wrong on this.

Personally if we now have a standalone launcher MSI, I'd like to
discontinue the external one completely, and officially publish the
standalone launcher MSI on python.org as a service for users of older
Pythons. There seems little reason to maintain 2 repos if we don't
have to. We could merge in changes from the external repo before
discontinuing it, but I'm not sure how controversial that would be
(for example, would it need a PEP to include the 2 new extensions?)

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 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).
So you are certainly not alone here, either.

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]

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.
> 
> Yep, venv uses it too (see
> https://hg.python.org/cpython/file/9e10c4255277/Lib/venv/scripts/nt/activate.bat).
> 
> As people like Thomas (and me, until this issue stopped me :-)) are using the
> launcher for command line use, I think it's fair to broaden the scope to make
> command line usage more convenient. I agree that PEP
> 397 was originally focused mainly on file associations, but I think it's worth
> looking beyond that now.

That's roughly the premise behind my activate-py proposal. Use `activate` to 
make a virtualenv/venv the default, and `activate-py [-x[.y[-32]]]` to make a 
non-venv the default. I have proof of concept implementations already for 
cmd.exe and PowerShell and it's fairly simple, but writing up the rationale is 
time consuming (and also the main point - it's worth having all the problems 
with PATH documented in one place).

>> 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 people using Pythons that didn't have it 
> bundled,
> and to add features (such as the new file extensions) on a quicker timescale
> than Python releases. But since he passed it to the pypa umbrella I don't 
> think
> he's been keeping the two in sync. I've copied him in case I'm completely 
> wrong
> on this.
> 
> Personally if we now have a standalone launcher MSI, I'd like to discontinue 
> the
> external one completely, and officially publish the standalone launcher MSI on
> python.org as a service for users of older Pythons. There seems little reason 
> to
> maintain 2 repos if we don't have to. We could merge in changes from the
> external repo before discontinuing it, but I'm not sure how controversial that
> would be (for example, would it need a PEP to include the 2 new extensions?)

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)

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 to add the association in the installer.

Cheers,
Steve

> 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

[Thomas Heller]

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 -3.4 script.py' or 'py -2.7 script.py'.


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" became completely unusable.


I'm normally not using virtual environments, so my understanding might
be wrong.  Isn't it the case that in virtual envs you don't have these
problems at all?  The 'correct' python.exe is on the PATH as well as the
Scripts directory:  this is what activate.bat does.

Thomas

___
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/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 Scripts directory on the Python 2.7
> installation, without changing PATH presistently?

I'm pretty sure py.exe should only start .py files, not .bat, .cmd, or 
.anything-else.

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

[Paul Moore]

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" became completely unusable.
>
> I'm normally not using virtual environments, so my understanding might
> be wrong.  Isn't it the case that in virtual envs you don't have these
> problems at all?  The 'correct' python.exe is on the PATH as well as the
> Scripts directory:  this is what activate.bat does.

Yes, but that's essentially the problem. I don't want to use "py" to
start Python, but when I'm in a virtualenv, have to switch to using
"python". That was what I used to do, and I found that I was forever
running "py" in a virtualenv and wondering why the packages I'd
installed weren't available...

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 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-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Paul Moore]

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 it's a reasonable idea?

OK, here we go. https://www.python.org/dev/peps/pep-0486/

Reproduced inline below for ease of reading / commenting. It's also
available on github at https://github.com/pfmoore/peps should people
want to submit corrections or anything there.

PEP: 486
Title: Make the Python Launcher aware of virtual environments
Version: $Revision$
Last-Modified: $Date$
Author: Paul Moore 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 12-Feb-2015
Python-Version: 3.5
Post-History:


Abstract


The Windows installers for Python include a launcher that locates the
correct Python interpreter to run (see PEP 397).  However, the
launcher is not aware of virtual environments (virtualenv [1]_ or PEP
405 based), and so cannot be used to run commands from the active
virtualenv.

This PEP proposes making the launcher "virtualenv aware".  This means
that when run without specifying an explicit Python interpreter to
use, the launcher will use the currently active virtualenv, if any,
before falling back to the configured default Python.


Rationale
=

Windows users with multiple copies of Python installed need a means of
selecting which one to use.  The Python launcher provides this
facility by means of a ``py`` command that can be used to run either a
configured "default" Python or a specific interpreter, by means of
command line arguments.  So typical usage would be::

# Run the Python interactive interpreter
py

# Execute an installed module
py -m pip install pytest
py -m pytest

When using virtual environments, the ``py`` launcher is unaware that a
virtualenv is active, and will continue to use the system Python.  So
different command invocations are needed to run the same commands in a
virtualenv::

# Run the Python interactive interpreter
python

# Execute an installed module (these could use python -m,
# which is longer to type but is a little mopre similar to the
# launcher approach)
pip install pytest
py.test

Having to use different commands is is error-prone, and in many cases
the error is difficult to spot immediately. The PEP proposes making
the ``py`` command usable with virtual environments, so that the first
form of command can be used in all cases.


Implementation
==

Both ``virtualenv`` and the core ``venv`` module set an environment
variable ``VIRTUAL_ENV`` when activating a virtualenv.  This PEP
proposes that the launcher checks for the ``VIRTUAL_ENV`` environment
variable whenever it would run the "default" Python interpreter for
the system (i.e., when no specific version flags such as ``py -2.7``
are used) and if present, run the Python interpreter for the
virtualenv rather than the default system Python.

The "default" Python interpreter referred to above is (as per PEP 397)
either the latest version of Python installed on the system, or
a version configured via the ``py.ini`` configuration file.  When the
user specifies an explicit Python version on the command line, this
will always be used (as at present).


Impact on Script Launching
==

As well as interactive use, the launcher is used as the Windows file
association for Python scripts.  In that case, a "shebang" (``#!``)
line at the start of the script is used to identify the interpreter to
run.  A fully-qualified path can be used, or a version-specific Python
(``python3`` or ``python2``, or even ``python3.5``), or the generic
``python``, which means to use the default interpreter.

With the proposed change, scripts that start with ``#!python`` (or one
of its equivalent forms) will be run using an active virtualenv.  This
is a change in behaviour, although it will only affect users running
scripts from the command line with a virtualenv activated.

Under Unix, the ``#!/usr/bin/env python`` shebang line will use the
version of Python found on ``$PATH``, whereas ``#!/usr/bin/python``
will use the system Python.  In order to match Unix behaviour as
closely as possible, it is proposed that the two shebang forms::

#!/usr/bin/env python
#!python

use an active virtualenv, if present, whereas the forms::

#!/usr/bin/python
#!/usr/local/bin/python

use *only* the default system Python, and ignore the ``VIRTUAL_ENV``
environment variable.


Exclusions
==

The PEP makes no attempt to promote the use of the launcher for
running Python on Windows.  Most existing documentation assumes the
user of ``python`` as the command to run Python, and (for example)
``pip`` to run an installed Python command.  This documentation is not
expected to change, and users who choose to manage their ``PATH``
environment varia

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

[Ethan Furman]

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/python-dev/archive%40mail-archive.com

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

[Paul Moore]

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 needs a PEP, I usually
get it wrong...

> 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 to add the association in the installer.

Yes, "py spam.pyz" works fine. +1 on having the associations.
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...

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

[Glenn Linderman]

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,
myscript.cmd or whatever is in the Scripts directory on the Python 2.7
installation, without changing PATH presistently?

I'm pretty sure py.exe should only start .py files, not .bat, .cmd, or 
.anything-else.



IIRC, it already can be configured to start other things. I think I even 
used it for that early on in Vinay's development cycle, just to prove 
it, although the things I used it for then were not things I'm still doing.
___
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/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 execute the script myscript.exe, myscript.bat, myscript.py,
>>> myscript.cmd or whatever is in the Scripts directory on the Python 2.7
>>> installation, without changing PATH presistently?
>> I'm pretty sure py.exe should only start .py files, not .bat, .cmd, or 
>> .anything-else.
>>
> 
> IIRC, it already can be configured to start other things. I think I even used 
> it for that early on in Vinay's
> development cycle, just to prove it, although the things I used it for then 
> were not things I'm still doing.

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

--
~Ethan~

[1] or something to that effect -- basically, it may work, but you're on your 
own if you use it that way.



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

[Paul Moore]

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 instinct in me. Part of me wishes there had been a
problem, so that I could be the one who raised a legitimate bug on
bugs.python.org saying "Python encounters an error when running a Perl
script" :-)

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 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, just because it appealed to
the perverse instinct in me. Part of me wishes there had been a
problem, so that I could be the one who raised a legitimate bug on
bugs.python.org saying "Python encounters an error when running a Perl
script" :-)

Paul



Get thee behind me, Satan.

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

[Vinay Sajip]

> 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 people using Pythons that didn't have
> it bundled, and to add features (such as the new file extensions) on a
> quicker timescale than Python releases. But since he passed it to the
> pypa umbrella I don't think he's been keeping the two in sync. I've
> copied him in case I'm completely wrong on this.


Thanks for copying me in - I haven't been tracking changes to the launcher in 
hg.p.o purely because I have been really busy with consultancy work for the 
past few months, leading to reduced time available for open-source 
contributions. I intend to try and keep things synced up where feasible and 
when time permits, and your email has given me the heads-up to look and see 
what's changed in the hg.p.o version.
> Personally if we now have a standalone launcher MSI, I'd like to
> discontinue the external one completely, and officially publish the
> standalone launcher MSI on python.org as a service for users of older

> Pythons.

The standalone repo/installer is just there for older Pythons where it's not 
bundled (and also to allow trying out features independently of the Python 
release cycle, as you mentioned). If python.org will offer an unbundled MSI 
just to install the launcher on Pythons < 3.3, then I suppose my installer 
could be retired. I don't know if the hg.p.o. installer would be equivalent to 
the standalone one (e.g. when the standalone launcher is uninstalled, the user 
gets a chance to associate file extensions with one of the installed Pythons 
found on the system).

Off to read the whole thread on python-dev now ...

Regards,

Vinay Sajip
___
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

[Vinay Sajip]

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

[Vinay Sajip]

> 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 suggestions to improve it) which does a similar job to PEP 441's pyzaa 
and provides improved Windows support (some of which might be supplanted by 
py.exe support for .pyz/.pyzw, but I have cases where I can't rely on py.exe 
being present).

Regards,

Vinay Sajip
___
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 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 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

[Vinay Sajip]

- 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 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 is used to launch IronPython, 
but it could be used for other things too). In addition, my version has some 
bugfixes (e.g. use of iswspace instead of isspace, which is wrong). Steve's 
changes seem to just be related to adding IP_VERSION - I'm not sure what that's 
about and I haven't looked into it yet; I just skimmed the differences, and 
didn't see anything major in launcher.c (I compared with the version in the 
default branch of cpython).

Regards,

Vinay Sajip

[1] https://bitbucket.org/vinay.sajip/pylauncher
___
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]

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 is used to launch IronPython,
> but it could be used for other things too). In addition, my version has some
> bugfixes (e.g. use of iswspace instead of isspace, which is wrong). Steve's
> changes seem to just be related to adding IP_VERSION - I'm not sure what 
> that's
> about and I haven't looked into it yet; I just skimmed the differences, and
> didn't see anything major in launcher.c (I compared with the version in the
> default branch of cpython).

I thought I did more than that, but maybe that was attempting to make things 
work :) The default branch is the most up to date.

The big change is that the registry key for 32-bit Python now includes the 
"-32" suffix, so that you can install 32-bit and 64-bit versions per-user at 
the same time and we don't have a collision. The launcher needed some updates 
to handle that, since it was assuming that registry key names would never be 
more than three characters long. Probably everything else I did was elsewhere 
in Python or in the installer. (Btw, it sounds like your installer will work 
better as a standalone tool, though my MSI has the advantage that it won't 
collide with a Python 3.5+ installation. I'm not fussed about whose 'wins' 
though.)

Cheers,
Steve

> Regards,
> 
> Vinay Sajip
> 
> [1] https://bitbucket.org/vinay.sajip/pylauncher
___
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] subclassing builtin data structures

[Ethan Furman]

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)' % self
...
--> m = MyInt(42)
--> m
MyInt(42)
--> m + 1
43
--> type(m+1)


Besides the work it would take to rectify this, I imagine the biggest hurdle 
would be the performance hit in always
looking up the type of self.  Has anyone done any preliminary benchmarking?  
Are there other concerns?

--
~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] subclassing builtin data structures

[Guido van Rossum]

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 MyInt(int):
> ...   def __repr__(self):
> ... return 'MyInt(%d)' % self
> ...
> --> m = MyInt(42)
> --> m
> MyInt(42)
> --> m + 1
> 43
> --> type(m+1)
> 
>
> Besides the work it would take to rectify this, I imagine the biggest
> hurdle would be the performance hit in always
> looking up the type of self.  Has anyone done any preliminary
> benchmarking?  Are there other concerns?
>

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 general)
why the signature of a subclass constructor should match the base class
constructor, and it often doesn't.

So this is pretty much a no-go. It's not unique to Python -- it's a basic
issue with OO.

-- 
--Guido van Rossum (python.org/~guido)
___
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] subclassing builtin data structures

[Ethan Furman]

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 base class instead of the derived class.
> 
> In case that wasn't clear ;)
> 
> --> class MyInt(int):
> ...   def __repr__(self):
> ... return 'MyInt(%d)' % self
> ...
> --> m = MyInt(42)
> --> m
> MyInt(42)
> --> m + 1
> 43
> --> type(m+1)
> 
> 
> Besides the work it would take to rectify this, I imagine the biggest 
> hurdle would be the performance hit in always
> looking up the type of self.  Has anyone done any preliminary 
> benchmarking?  Are there other concerns?
> 
> 
> 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 general) why the signature of a subclass constructor 
> should match the base class constructor, and
> it often doesn't.
> 
> So this is pretty much a no-go. It's not unique to Python -- it's a basic 
> issue with OO.

Thank you.

--
~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] subclassing builtin data structures

[MRAB]

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 instead of the derived class.

In case that wasn't clear ;)

--> class MyInt(int):
...   def __repr__(self):
... return 'MyInt(%d)' % self
...
--> m = MyInt(42)
--> m
MyInt(42)
--> m + 1
43
--> type(m+1)


Besides the work it would take to rectify this, I imagine the
biggest hurdle would be the performance hit in always
looking up the type of self.  Has anyone done any preliminary
benchmarking?  Are there other concerns?


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
general) why the signature of a subclass constructor should match the
base class constructor, and it often doesn't.


> So this is pretty much a no-go. It's not unique to Python -- it's a
> basic issue with OO.
>
Really?


>>> class BaseInt:
... def __init__(self, value):
... self._value = value
... def __add__(self, other):
... return type(self)(self._value + other)
... def __repr__(self):
... return '%s(%s)' % (type(self), self._value)
...
>>> class MyInt(BaseInt):
... pass
...
>>>
>>> m = BaseInt(42)
>>> m
(42)
>>> m + 1
(43)
>>> type(m + 1)

>>>
>>> m = MyInt(42)
>>> m
(42)
>>> m + 1
(43)
>>> type(m + 1)

>>>

___
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] subclassing builtin data structures

[Ethan Furman]

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 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)' % self
>> ...
>> --> m = MyInt(42)
>> --> m
>> MyInt(42)
>> --> m + 1
>> 43
>> --> type(m+1)
>> 
>>
>> Besides the work it would take to rectify this, I imagine the
>> biggest hurdle would be the performance hit in always
>> looking up the type of self.  Has anyone done any preliminary
>> benchmarking?  Are there other concerns?
>>
>>
>> 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
>> general) why the signature of a subclass constructor should match the
>> base class constructor, and it often doesn't.
>>
>> So this is pretty much a no-go. It's not unique to Python -- it's a
>> basic issue with OO.
>>
> Really?

What I was asking about, and Guido responded to, was not having to specifically 
override __add__, __mul__, __sub__, and
all the others; if we do override them then there is no problem.

--
~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] subclassing builtin data structures

[Alexander Belopolsky]

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 often doesn't.


I hear this explanation every time we have a discussion about subclassing
of datetime types and I don't really buy this.

Consider this simple subclass:

>>> from datetime import date
>>> class Date(date):
... pass
...

What do you think Date.today() should return?  Since I did not override
todat() in my Date class, it has to be datetime.date instance, right?

However:

>>> Date.today().__class__


Wait, Date "doesn't know how to construct an instance of the subclass .."

Indeed, if I change the constructor signature, Date.today() won't work:

>>> class Date(date):
... def __init__(self, extra):
... pass
...
>>> Date.today()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __init__() takes exactly 2 arguments (4 given)

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

On the other hand, if all I want in my Date class is a better __format__
method, I am forced to override all operators or have my objects silently
degrade in situations like this:

>>> d = Date.today()
>>> d.__class__

>>> d += timedelta(1)
>>> d.__class__


Having binary operations return subclass instances is not without
precedent.  For example, in numpy,

>>> from numpy import ndarray
>>> class Array(ndarray):
... pass
...
>>> a = Array(1)
>>> a[0] = 42
>>> a
Array([ 42.])
>>> a + a
Array([ 84.])

I believe numpy had this behavior since types became subclassable in
Python, so this design is definitely not a "no-go."
___
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] subclassing builtin data structures

[Chris Angelico]

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 is no reason (in general) why
> the signature of a subclass constructor should match the base class
> constructor, and it often doesn't.

You're requiring that any subclass of BaseInt be instantiable with one
argument, namely its value. That's requiring that the signature of the
subclass constructor match the base class constructor.

ChrisA
___
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] subclassing builtin data structures

[Steven D'Aprano]

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
> >> general) why the signature of a subclass constructor should match the
> >> base class constructor, and it often doesn't.
> >>
> >> So this is pretty much a no-go. It's not unique to Python -- it's a
> >> basic issue with OO.
> >>
> > Really?
> 
> What I was asking about, and Guido responded to, was not having to 
> specifically override __add__, __mul__, __sub__, and
> all the others; if we do override them then there is no problem.

I think you have misunderstood MRAB's comment. My interpretation is 
that MRAB is suggesting that methods in the base classes should use 
type(self) rather than hard-coding their own type.

E.g. if int were written in pure Python, it might look something like 
this:

class int(object):
def __new__(cls, arg):
...

def __add__(self, other):
return int(self, other)

(figuratively, rather than literally). But if it looked like this:

def __add__(self, other):
return type(self)(self, other)


then sub-classing would "just work" without the sub-class having to 
override each and every method.



-- 
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] subclassing builtin data structures

[Mark Roberts]

> 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)
> 
>> On Fri, Feb 13, 2015 at 11:55 AM, Guido van Rossum  wrote:
>> ... there is no reason (in general) why
>> the signature of a subclass constructor should match the base class
>> constructor, and it often doesn't.
> 
> You're requiring that any subclass of BaseInt be instantiable with one
> argument, namely its value. That's requiring that the signature of the
> subclass constructor match the base class constructor.
> 
> ChrisA
> ___
> 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/wizzat%40gmail.com

No, it seems like he's asking that the type return a new object of the same 
type instead of one of the superclass. In effect, making the Date class call 
type(self)(*args) instead of datetime.date(*args). He seems completely willing 
to accept the consequences of changing the constructor (namely that he will 
have to override all the methods that call the constructor).

It seems like good object oriented design to me.

-Mark
___
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] subclassing builtin data structures

[Ethan Furman]

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 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 often doesn't.

 So this is pretty much a no-go. It's not unique to Python -- it's a
 basic issue with OO.

>>> Really?
>>
>> What I was asking about, and Guido responded to, was not having to 
>> specifically override __add__, __mul__, __sub__, and
>> all the others; if we do override them then there is no problem.
> 
> I think you have misunderstood MRAB's comment. My interpretation is 
> that MRAB is suggesting that methods in the base classes should use 
> type(self) rather than hard-coding their own type.

That makes more sense, thanks.

--
~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] subclassing builtin data structures

[Ethan Furman]

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

> On the other hand, if all I want in my Date class is a better __format__ 
> method, I am forced to override all operators
> or have my objects silently degrade [...]

So there are basically two choices:

1) always use the type of the most-base class when creating new instances

   pros:
 - easy
 - speedy code
 - no possible tracebacks on new object instantiation

   cons:
 - a subclass that needs/wants to maintain itself must override all
   methods that create new instances, even if the only change is to
   the type of object returned

2) always use the type of self when creating new instances

   pros:
 - subclasses automatically maintain type
 - much less code in the simple cases [1]

   cons:
 - if constructor signatures change, must override all methods which
   create new objects

Unless there are powerful reasons against number 2 (such as performance, or the 
effort to affect the change), it sure
seems like the nicer way to go.

So back to my original question: what other concerns are there, and has anybody 
done any benchmarks?

--
~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] subclassing builtin data structures

[Guido van Rossum]

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 override all
> methods that create new objects or live with tracebacks.
>
> > On the other hand, if all I want in my Date class is a better __format__
> method, I am forced to override all operators
> > or have my objects silently degrade [...]
>
> So there are basically two choices:
>
> 1) always use the type of the most-base class when creating new instances
>
>pros:
>  - easy
>  - speedy code
>  - no possible tracebacks on new object instantiation
>
>cons:
>  - a subclass that needs/wants to maintain itself must override all
>methods that create new instances, even if the only change is to
>the type of object returned
>
> 2) always use the type of self when creating new instances
>
>pros:
>  - subclasses automatically maintain type
>  - much less code in the simple cases [1]
>
>cons:
>  - if constructor signatures change, must override all methods which
>create new objects
>
> Unless there are powerful reasons against number 2 (such as performance,
> or the effort to affect the change), it sure
> seems like the nicer way to go.
>
> So back to my original question: what other concerns are there, and has
> anybody done any benchmarks?
>

Con for #2 is a showstopper. Forget about it.

-- 
--Guido van Rossum (python.org/~guido)
___
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] subclassing builtin data structures

[Ethan Furman]

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 objects
> 
> Con for #2 is a showstopper. Forget about it.

Happy to, but can you explain why requiring the programmer to override the 
necessary methods, or get tracebacks, is a
showstopper?  Is there a previous email thread I can read that discusses it?

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

[Thomas Heller]

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,
myscript.cmd or whatever is in the Scripts directory on the Python 2.7
installation, without changing PATH presistently?


I'm pretty sure py.exe should only start .py files, not .bat, .cmd, or 
.anything-else.


To make it clear: My suggestion is (or was, maybe it isn't a good idea)
to have some way to start 'something' that is in the Scripts
directory of a Python installation (which is usually a python script
or an exe-wrapper for it), without typing in the full path.  And without
changing the PATH envrionment variable.

Thomas

___
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 486: Make the Python Launcher aware of virtual environments

[Nick Coghlan]

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
would be an appropriate BDFL-Delegate?

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

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

[Nick Coghlan]

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 to add the association in the 
>> installer.
>
> Yes, "py spam.pyz" works fine. +1 on having the associations.
> 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...

Zip archive & directory execution support was added in 2.6 by way of a
tracker issue rather than a full PEP, but we didn't realise we left it
out of the What's New docs until a few years later. That meant a lot
of folks missed the addition of the feature.

PEP 441 was aimed at giving the feature more visibility, in addition
to making appropriately designed archives easier to create (IIRC, my
main request for that PEP was to change the proposed module name to
the more prosaic, but also more self-explanatory, "pyzapp", although
it looks like I may have suggested that to Daniel offline rather than
through the mailing list).

Regardless, the PEP's not controversial as far as I am aware, so it
would be nice if someone had the time to get it cleaned up and
formally proposed for 3.5 (assuming Daniel was OK with that).

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