On Mon, Feb 16, 2015 at 10:47 PM, Petr Viktorin encu...@gmail.com wrote:
If *all* distros provide a python2 symlink, then the recommendation
can become use python if it's 2/3 compatible, or python2/python3 to
choose, and then it won't hurt to switch python to be python3.
Are there known
On Mon, Feb 16, 2015 at 12:00 AM, Chris Angelico ros...@gmail.com wrote:
On Sat, Feb 14, 2015 at 11:07 AM, Nick Coghlan ncogh...@gmail.com wrote:
OTOH, it may be time to reconsider our recommendation to distros as well,
suggesting that for Python 3.5+, we will consider it appropriate to have
On 15 February 2015 at 19:23, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at gmail.com writes:
2. It would be a nice, although extremely obscure, feature to be able
to allow people who want to keep Python off their path to set
VIRTUAL_ENV but *not* set PATH, so that py.exe
Paul Moore p.f.moore at gmail.com writes:
2. It would be a nice, although extremely obscure, feature to be able
to allow people who want to keep Python off their path to set
VIRTUAL_ENV but *not* set PATH, so that py.exe does the right thing
but there's *still* no python.exe on PATH. Limit
On Sat, Feb 14, 2015 at 11:07 AM, Nick Coghlan ncogh...@gmail.com wrote:
OTOH, it may be time to reconsider our recommendation to distros as well,
suggesting that for Python 3.5+, we will consider it appropriate to have the
python symlink refer to python3.
If *all* distros provide a python2
- Original Message -
From: Paul Moore p.f.mo...@gmail.com
The original PEP said nothing about a PATH search for #!/usr/bin/env
python, so I mistakenly assumed there was no way currently to write a
script that worked with an activated virtualenv.
Actually the path search was added
On 15 February 2015 at 21:00, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
The original PEP said nothing about a PATH search for #!/usr/bin/env
python, so I mistakenly assumed there was no way currently to write a
script that worked with an activated virtualenv.
Actually the path search was
- Original Message -
From: Paul Moore p.f.mo...@gmail.com
I'd also appreciate your views on the spin-off thread and PEP 486
(Make the Python Launcher aware of virtual environments).
I just thought of something ... as far as I know, we've enabled searching for a
command on the path
On 13 February 2015 at 00:15, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
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
On 13 February 2015 at 06:59, Thomas Heller thel...@ctypes.org wrote:
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
On 13 February 2015 at 07:25, Nick Coghlan ncogh...@gmail.com wrote:
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,
On 13 February 2015 at 09:47, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I just thought of something ... as far as I know, we've enabled searching for
a command on the path - since when a venv is active in the sense of
VIRTUAL_ENV being defined, PATH is also set up so that the venv's Scripts
On 2/13/2015 1:13 AM, Paul Moore wrote:
On 13 February 2015 at 06:59, Thomas Heller thel...@ctypes.org wrote:
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
On 13 February 2015 at 10:15, Glenn Linderman v+pyt...@g.nevcal.com wrote:
Maybe restricting it to running .py files or .exe files would be
reasonable. That covers entry points (which should be the norm for
newer projects) and Python scripts (which are the most likely things
to be portable).
Devmailto:python-dev@python.org
Subject: Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows
On 13 February 2015 at 10:15, Glenn Linderman v+pyt...@g.nevcal.com wrote:
Maybe restricting it to running .py files or .exe files would be
reasonable. That covers entry points (which should
On 02/13/2015 01:57 AM, Paul Moore wrote:
2. It would be a nice, although extremely obscure, feature to be able
to allow people who want to keep Python off their path to set
VIRTUAL_ENV but *not* set PATH, so that py.exe does the right thing
but there's *still* no python.exe on PATH. Limit
On 13 February 2015 at 14:27, Steve Dower steve.do...@microsoft.com wrote:
If py.exe starts defaulting to whatever is on PATH then I don't see the
point of it. Knowing that you'll get the latest 2.x version by default is
quite handy (I'd be quite okay changing that to 3.x, though it is
On 14 Feb 2015 01:47, Paul Moore p.f.mo...@gmail.com wrote:
On 13 February 2015 at 14:27, Steve Dower steve.do...@microsoft.com
wrote:
If py.exe starts defaulting to whatever is on PATH then I don't see the
point of it. Knowing that you'll get the latest 2.x version by default
is
quite
On 12 February 2015 at 16:42, Steve Dower steve.do...@microsoft.com 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
On 12 February 2015 at 17:39, Ethan Furman et...@stoneleaf.us 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
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,
On 12 February 2015 at 17:13, Thomas Heller thel...@ctypes.org 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
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
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.
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
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
On 12 February 2015 at 20:11, Ethan Furman et...@stoneleaf.us 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
On 12/02/2015 20:23, Paul Moore wrote:
On 12 February 2015 at 20:11, Ethan Furman et...@stoneleaf.us 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
- Original Message -
From: Steve Dower steve.do...@microsoft.com
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
On 12 February 2015 at 21:44, Vinay Sajip vinay_sa...@yahoo.co.uk 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
- Original Message -
From: Paul Moore p.f.mo...@gmail.com
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
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
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,
On 13 February 2015 at 05:50, Paul Moore p.f.mo...@gmail.com wrote:
On 12 February 2015 at 16:42, Steve Dower steve.do...@microsoft.com 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
it).
Cheers,
Steve
Top-posted from my Windows Phone
From: Thomas Hellermailto:thel...@ctypes.org
Sent: 2/12/2015 0:03
To: python-dev@python.orgmailto:python-dev@python.org
Subject: Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows
Am 10.02.2015 um
On 12 February 2015 at 08:05, Thomas Heller thel...@ctypes.org 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
On 12 February 2015 at 15:37, Steve Dower steve.do...@microsoft.com 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,
Devmailto:python-dev@python.org
Subject: Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows
On 12 February 2015 at 08:05, Thomas Heller thel...@ctypes.org 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
Am 12.02.2015 um 15:46 schrieb Paul Moore:
On 12 February 2015 at 08:05, Thomas Heller thel...@ctypes.org 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
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
Paul Moore wrote:
On 12 February 2015 at 15:37, Steve Dower steve.do...@microsoft.com 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
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
On 10 February 2015 at 14:13, Steve Dower steve.do...@microsoft.com 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
On 10 February 2015 at 14:13, Steve Dower steve.do...@microsoft.com 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
-dev@python.org
Subject: Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows
On 10 February 2015 at 14:13, Steve Dower steve.do...@microsoft.com 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
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,
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
Am 10.02.15 um 15:43 schrieb Paul Moore:
On 10 February 2015 at 14:13, Steve Dower steve.do...@microsoft.com 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)?
On 10 February 2015 at 12:38, Paul Moore p.f.mo...@gmail.com 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
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
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
On 10 Feb 2015 22:40, Paul Moore p.f.mo...@gmail.com 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
On 10 February 2015 at 13:34, Nick Coghlan ncogh...@gmail.com 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
On 10 February 2015 at 20:50, Paul Moore p.f.mo...@gmail.com wrote:
On 10 February 2015 at 17:45, Steve Dower steve.do...@microsoft.com 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
On 10/02/2015 20:47, Paul Moore wrote:
On 10 February 2015 at 12:38, Paul Moore p.f.mo...@gmail.com 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
Paul Moore wrote:
On 10 February 2015 at 20:50, Paul Moore p.f.mo...@gmail.com wrote:
On 10 February 2015 at 17:45, Steve Dower steve.do...@microsoft.com 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
On 10 February 2015 at 12:38, Paul Moore p.f.mo...@gmail.com 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
On 10 February 2015 at 17:45, Steve Dower steve.do...@microsoft.com 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
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
On 11 Feb 2015 03:47, Steve Dower steve.do...@microsoft.com 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
to change it.)
Cheers,
Steve
Top-posted from my Windows Phone
From: Paul Mooremailto:p.f.mo...@gmail.com
Sent: 2/10/2015 5:40
To: Nick Coghlanmailto:ncogh...@gmail.com
Cc: Python Devmailto:python-dev@python.org
Subject: Re: [Python-Dev] PEP 370 - per-user scripts
61 matches
Mail list logo
