On Mon, Feb 16, 2015 at 12:00 AM, Chris Angelico wrote:
> On Sat, Feb 14, 2015 at 11:07 AM, Nick Coghlan 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
On Mon, Feb 16, 2015 at 10:47 PM, Petr Viktorin 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 distros in w
On Sat, Feb 14, 2015 at 11:07 AM, Nick Coghlan 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" symlink, the
On 15 February 2015 at 21:00, Vinay Sajip 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 added later, by y
- Original Message -
From: Paul Moore
> 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 later, by you! See
On 15 February 2015 at 19:23, Vinay Sajip wrote:
> Paul Moore 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
>> bu
Paul Moore 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 the depend
On 14 Feb 2015 01:47, "Paul Moore" wrote:
>
> On 13 February 2015 at 14:27, Steve Dower
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
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 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 specified
> in the original PEP
o:v+pyt...@g.nevcal.com>
Cc: Python Dev<mailto: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 wrote:
> Maybe restricting it to running ".py" files or ".exe" files would
On 13 February 2015 at 10:15, Glenn Linderman 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).
>
> The WINDOWS
On 2/13/2015 1:13 AM, Paul Moore wrote:
On 13 February 2015 at 06:59, Thomas Heller 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
On 13 February 2015 at 09:47, Vinay Sajip 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
> folder is on it -
- 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").
I just thought of something ... as far as I know, we've enabled searching for a
command on the path - since when a v
On 13 February 2015 at 07:25, Nick Coghlan 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, but also more se
On 13 February 2015 at 06:59, Thomas Heller 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 it), without ty
On 13 February 2015 at 00:15, Vinay Sajip 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 too).
At the time
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
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,
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
- 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
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
> 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
- 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
_
> 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/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
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
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
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
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
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-
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
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
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 -
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.
>
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
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
lto:thel...@ctypes.org>
Cc: Python Dev<mailto: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 wrote:
> Maybe I'm more or less alone with the way I work, but I don't like
> python.
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'.
les to be able
to use it).
Cheers,
Steve
Top-posted from my Windows Phone
From: Thomas Heller<mailto:thel...@ctypes.org>
Sent: 2/12/2015 0:03
To: python-dev@python.org<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] PEP 370 - per-user script
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.
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
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
>>>
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
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
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
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
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
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
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
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 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,
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
ogh...@gmail.com>; Python
Dev<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows
On 10 February 2015 at 14:13, Steve Dower wrote:
> The installer will also need some changes to add it to PATH, which should be
> fairly straightforward,
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
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
ts to change it.)
Cheers,
Steve
Top-posted from my Windows Phone
From: Paul Moore<mailto:p.f.mo...@gmail.com>
Sent: 2/10/2015 5:40
To: Nick Coghlan<mailto:ncogh...@gmail.com>
Cc: Python Dev<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] PEP
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
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
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
61 matches
Mail list logo
