On 10/20/18, Terry Reedy wrote:
>
> On Windows, there is a better solution: the py launcher.
> > py # launches the most most recent version installed*
> > py -x # launches the most recent x.y
> > py -x.y # launches x.y if installed, else lists installed versions
>
> * At first, 2.x took
On Sun, Oct 21, 2018 at 12:41 PM Peter via Python-list
wrote:
>
> I'd imagine the PEP would stay as active, but changed so that:
>
> python2 -> always refers to python v2
> python3 -> always refers to python v3
> python -> which currently refers to python v2 will change to point to
> python v3
12:57:45 +1100
Ben Finney skrev:
Anders Wegge Keller writes:
Short and simple: Do you expect PEP 394 to change status
The status of PEP 394 today is “Active”. What change of status would you
expect in this Informational PEP?
One possible change would be that it would become archive
On 10/19/2018 3:03 AM, Anders Wegge Keller wrote:
Short and simple: Do you expect PEP 394 to change status or
recommendation when official support for Python2 ends in 13½ months time, or
at least some time thereafter?
For those that don't have the habit of memorizing PEPs, 394 is the one
På Sat, 20 Oct 2018 12:57:45 +1100
Ben Finney skrev:
> Anders Wegge Keller writes:
>
> > Short and simple: Do you expect PEP 394 to change status
>
> The status of PEP 394 today is “Active”. What change of status would you
> expect in this Informational PEP?
One
Anders Wegge Keller writes:
> Short and simple: Do you expect PEP 394 to change status
The status of PEP 394 today is “Active”. What change of status would you
expect in this Informational PEP?
> or recommendation when official support for Python2 ends in 13½ months
> time, or at l
On 19/10/2018 18:38, Marko Rauhamaa wrote:
> Thomas Jollans :
>
>> On 2018-10-19 12:06, Marko Rauhamaa wrote:
>>> Anders Wegge Keller :
* python3 will refer to some version of Python 3.x.
>>>
>>> Untrue for macOS, ArchLinux, RHEL and CentOS.
>>
>> Sure it's true for *EL (it's just that
Thomas Jollans :
> On 2018-10-19 12:06, Marko Rauhamaa wrote:
>> Anders Wegge Keller :
>>> * python3 will refer to some version of Python 3.x.
>>
>> Untrue for macOS, ArchLinux, RHEL and CentOS.
>
> Sure it's true for *EL (it's just that python3 might not be installed by
> default even on EL7)
On 2018-10-19 12:06, Marko Rauhamaa wrote:
> Anders Wegge Keller :
>> * python2 will refer to some version of Python 2.x.
>
> Untrue for macOS.
>
>> * python3 will refer to some version of Python 3.x.
>
> Untrue for macOS, ArchLinux, RHEL and CentOS.
Sure it's true for *EL (it's just that
the time being, all distributions should ensure that python, if
>> installed, refers to the same target as python2, unless the user
>> deliberately overrides this or a virtual environment is active.
> Should, would, could.
>
Some platforms not being 394-compliant doesn't change wha
Anders Wegge Keller :
> * python2 will refer to some version of Python 2.x.
Untrue for macOS.
> * python3 will refer to some version of Python 3.x.
Untrue for macOS, ArchLinux, RHEL and CentOS.
> * for the time being, all distributions should ensure that python, if
> installed, refers to the
Short and simple: Do you expect PEP 394 to change status or
recommendation when official support for Python2 ends in 13½ months time, or
at least some time thereafter?
For those that don't have the habit of memorizing PEPs, 394 is the one
stating
* python2 will refer to some version of Python
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 499796937b7a by Ned Deily in branch '2.7':
Issue #12627: Implement PEP 394 for OS X framework builds.
http://hg.python.org/cpython/rev/499796937b7a
--
nosy: +python-dev
Ned Deily n...@acm.org added the comment:
Changeset 499796937b7a implements PEP 394 for OS X framework builds on Python
2.7. OS X framework builds already created versioned symlinks for all
executables and scripts installed in the framework bin directory, of the
general form ${cmd} - ${cmd
Nick Coghlan ncogh...@gmail.com added the comment:
No automatic link, since I neglected to mention the issue number in the checkin
messages:
2.7: http://hg.python.org/cpython/rev/a65a71aa9436
3.3: http://hg.python.org/cpython/rev/dc721f28f168
I deliberately *didn't* make the change in 3.2. As
Changes by Nick Coghlan ncogh...@gmail.com:
Removed file: http://bugs.python.org/file22738/version33_links.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12627
___
Nick Coghlan ncogh...@gmail.com added the comment:
I removed the 3.3 patch, since all the previous version did was change symbolic
links to hard links, and the latest round of discussions favoured retaining the
symlinks since they're much easier to introspect.
However, it turns out there is
Nick Coghlan ncogh...@gmail.com added the comment:
Actually, the Python 3 Makefile.pre.in is currently broken if $(EXE) is ever
non-empty - in a few places it uses $(PYTHON)$(VERSION)$(EXE) and
$(PYTHON)3$(EXE).
Those are wrong, because the definition of $(PYTHON) at the top of the file is
Nick Coghlan ncogh...@gmail.com added the comment:
New patch that aims to create the appropriate symlinks in make bininstall. I
don't currently have a sacrificial VM set up to test it in though.
--
Added file: http://bugs.python.org/file24530/pep394_python27_symlinks.diff
Changes by Nick Coghlan ncogh...@gmail.com:
Removed file: http://bugs.python.org/file22737/version27_links.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12627
___
Martin v. Löwis mar...@v.loewis.de added the comment:
The 2.7 patch needs to remove an existing python2 link before creating it.
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12627
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12627
___
___
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12627
___
___
Python-bugs-list
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12627
___
___
Python-bugs-list
Changes by Jeremy Bicha jbi...@ubuntu.com:
--
nosy: +jbicha
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12627
___
___
Python-bugs-list mailing
Éric Araujo mer...@netwok.org added the comment:
Some scripts are installed by setup.py
I’ll find time to read the latest version of the PEP in the coming days.
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
Changes by Petri Lehtinen pe...@digip.org:
--
nosy: +petri.lehtinen
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12627
___
___
Python-bugs-list
New submission from Kerrick Staley m...@kerrickstaley.com:
This issue was opened to track the implementation of PEP 394, which governs the
way the python command and commands like python2 and python3 work on Unix-like
systems.
--
components: Installation
messages: 141034
nosy
Kerrick Staley m...@kerrickstaley.com added the comment:
Here is a patch that will update the Makefile.pre.in file for 2.7, causing it
to install python2 and python2-config when run with make install (or just
make bininstall). This does not update any documentation. Also, it appears
that Idle
Kerrick Staley m...@kerrickstaley.com added the comment:
This updates the links created by make install or make bininstall in Python
3 so that they're in agreement with the recommendations of PEP 394; it's the
equivalent of version27_links.patch but is for Python 3.
--
Added file
Changes by Ned Deily n...@acm.org:
--
nosy: +ned.deily
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12627
___
___
31 matches
Mail list logo
