Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows
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 which current versions (or, those that will be >> current when 3.5 is released) aren't providing "python2"? > > That wouldn't be a good recommendation for the long term. > Fedora probably won't drop python2 from the default installation > before 3.5 is released, but hopes are high that it'll happen when 3.5 > is still current. Not sure about others. Clarification: If all distros *that provide Python 2.x* provide a "python2" symlink, etc, etc. 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] PEP 370 - per-user scripts directory on Windows
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 "python3". > > 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 which current versions (or, those that will be > current when 3.5 is released) aren't providing "python2"? That wouldn't be a good recommendation for the long term. Fedora probably won't drop python2 from the default installation before 3.5 is released, but hopes are high that it'll happen when 3.5 is still current. Not sure about others. ___ 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] Python 3.4 RPM on AIX
hi I am having problem building Python RPM on AIX and I think there are several bugs in Python .spec files. README file says download the bz2 version, but only gziped and xz version available from Python website so had to convert the .tgz file to bz2 and copy it over to SOURCES directory. %define config_binsuffix was set to 2.6 and not sure why it should be 2.6 when I am working on 3.4 version. had to change it to to pass the error. %define config_binsuffix none Misc/cheatsheet seems to be decommissioned in new version of Python but still in spec file so commented it. The last error that I am receiving and can't figure the resolution is belowwhy it won't create the required direcotory ?Processing files: python-devel-3.4.2-AIX71 File not found by glob: /var/opt/freeware/tmp/python-3.4.2-root/usr/include/python3.4/*.h File not found: /var/opt/freeware/tmp/python-3.4.2-root/usr/lib/python3.4/config PreReq: rpmlib(VersionedDependencies) <= 3.0.3-1 python = 3.4.2 Processing files: python-tools-3.4.2-AIX71 File not found: /var/opt/freeware/tmp/python-3.4.2-root/usr/bin/pydoc File not found: /var/opt/freeware/tmp/python-3.4.2-root/usr/bin/smtpd.py PreReq: rpmlib(VersionedDependencies) <= 3.0.3-1 python = 3.4.2-AIX71 running rpm -bl option to see missing files are below: rpm -bl /opt/freeware/src/packages/SPECS/python-3.4.spec Processing files: python-3.4.2-AIX71 File not found by glob: /var/opt/freeware/tmp/python-3.4.2-root/opt/freeware/man/man1/python.1* File not found: /var/opt/freeware/tmp/python-3.4.2-root/usr/include/python3.4 Processing files: python-devel-3.4.2-AIX71 File not found by glob: /var/opt/freeware/tmp/python-3.4.2-root/usr/include/python3.4/*.h File not found: /var/opt/freeware/tmp/python-3.4.2-root/usr/lib/python3.4/config PreReq: rpmlib(VersionedDependencies) <= 3.0.3-1 python = 3.4.2 Processing files: python-tools-3.4.2-AIX71 File not found: /var/opt/freeware/tmp/python-3.4.2-root/usr/bin/pydoc File not found: /var/opt/freeware/tmp/python-3.4.2-root/usr/bin/smtpd.py PreReq: rpmlib(VersionedDependencies) <= 3.0.3-1 python = 3.4.2-AIX71 Any idea as how I can fix this ? ___ 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 441 - Improving Python ZIP Application Support
On 15 February 2015 at 18:25, Petr Viktorin wrote:
> On POSIXy systems the "python3" symlink is created in all venvs. I
> thought (perhaps naïvely) that Windows doesn't do shebangs natively,
> so there's some Python-specific mechanism around them, which should
> handle "python3".
Windows doesn't have "python2" or "python3" commands, just "python".
To choose which version you use, set PATH or use an explicit path to
the executable.
The launcher offers shebang handling for scripts, and special-cases
the following values for Unix compatibility:
#!/usr/bin/env python
#!/usr/bin/python
#!/usr/local/bin/python
They default to the "default Python" which is normally the latest
Python 2 version available, but which can be configured by the user.
They also support adding an explicit version (python2, python3,
python2.7, python3.4, ...)
As far as I know, this is *identical* behaviour to Unix - even to the
incredibly annoying (to me) choice of Python 2 as a default. So I
reconfigure the default in my personal settings to Python 3. Unix
users can do this too (although it may involve a symlink in a ~/bin
directory rather than an ini file change).
I see no reason for the zipapp module to buck the trend that the
default Python is "the latest 2.X version unless the user configures
it differently themselves". Hence the default of "#!/usr/bin/env
python". Certainly that means that users who use the default have to
be prepared for the fact that they are subject to user configuration
changes, and yes that includes running under either of Python 2 or 3.
If you don't like that, force a particular version with -p, and be
prepared for the *other* issues this may cause (user doesn't have that
version, for example).
The alternative, I guess, is to have *no* default and write no shebang
unless -p is specified. That matches how .py files work (you have to
type the shebang line in if you want it) and works the same way (on
Unix, a file without a shebang must be run with an explicit "python"
command, and on Windows it uses the default Python via the file type
association). Honestly, I'd be happy with this - the Windows
experience is identical, and it saves choosing something inappropriate
("in the face of ambiguity, refuse the temptation to guess" :-))
So, the options I see:
1. Stick with /usr/bin/env python
2. No shebang unless -p is specified
3. Unix users come up with a solution which is the same as the above
for Windows users, but which suits them better.
I don't see changing the Windows behaviour as an option.
If nobody comes up with anything for (3) I'll take the consensus
between (1) or (2). If there's no consensus, I'll pick something.
Probably 1, as why change if nobody has a better idea?
One final thought. This issue is no different from shebang lines in
.py scripts - the only real difference is that it's easy to see and
edit the shebang in a .py script. It may be that what's really needed
here is an option for the user to display and update the shebang line
in a pyz archive. I'll look at adding that to the PEP, regardless of
the conclusion to this debate.
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 441 - Improving Python ZIP Application Support
On 02/16/2015 08:16 AM, Paul Moore wrote: > The alternative, I guess, is to have *no* default and write no shebang > unless -p is specified. This seems to make sense. > So, the options I see: > > 1. Stick with /usr/bin/env python > 2. No shebang unless -p is specified > 3. Unix users come up with a solution which is the same as the above > for Windows users, but which suits them better. +1 on 2 +0.5 on 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 441 - Improving Python ZIP Application Support
On 16 February 2015 at 16:34, Steve Dower wrote: >> As far as I know, this is *identical* behaviour to Unix - even to the >> incredibly >> annoying (to me) choice of Python 2 as a default. So I reconfigure the >> default >> in my personal settings to Python 3. Unix users can do this too (although it >> may >> involve a symlink in a ~/bin directory rather than an ini file change). > > We could also add special-cases for "#!/usr/...python3" in the launcher on > Windows. The launcher handles that. It runs the same thing as "py -3" runs. Which may not be the same as what "py" runs (in my case it runs 3.5a1 where py runs 3.4). Arguably that's an odd choice, but it's simply that I only use "py" in the normal course of events so I only set the "python" default, not the "python3" default. My point is that on Windows, users typically don't change the executable name they use[1], but rather configure the "python" (or "py") command to do what they want. So I think that on Windows we should follow that convention and execute whatever "python"/"py" execute. Paul [1] As usual with anything like this, it's hard to get a sense of what's "typical" so if hordes of Windows users suddenly post saying they routinely use "python2" and "python3" commands, I'll happily concede I'm not the norm here and ask someone to step up and document recommended practices on Windows better, and I'll update the PEP to follow them :-) ___ 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 441 - Improving Python ZIP Application Support
I don't know what anyone else does, but in cases where I have both on my windows box, I do use python2(.x) and python3(.y) . If I only have one version on the box, I use the generic name of course. (I don't often have only one version on my boxes though. 2.x inevitably gets drug in in for some reason or another and I hardly ever uninstall old versions of 3.x) I don't use the launcher though, so I might be out-of-scope entirely. (in which case, sorry for the noise) ___ 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 441 - Improving Python ZIP Application Support
Paul Moore wrote: > On 15 February 2015 at 18:25, Petr Viktorin wrote: >> On POSIXy systems the "python3" symlink is created in all venvs. I >> thought (perhaps naïvely) that Windows doesn't do shebangs natively, >> so there's some Python-specific mechanism around them, which should >> handle "python3". > > Windows doesn't have "python2" or "python3" commands, just "python". > To choose which version you use, set PATH or use an explicit path to the > executable. > > The launcher offers shebang handling for scripts, and special-cases the > following values for Unix compatibility: > > #!/usr/bin/env python > #!/usr/bin/python > #!/usr/local/bin/python > > They default to the "default Python" which is normally the latest Python 2 > version available, but which can be configured by the user. > They also support adding an explicit version (python2, python3, python2.7, > python3.4, ...) > > As far as I know, this is *identical* behaviour to Unix - even to the > incredibly > annoying (to me) choice of Python 2 as a default. So I reconfigure the default > in my personal settings to Python 3. Unix users can do this too (although it > may > involve a symlink in a ~/bin directory rather than an ini file change). We could also add special-cases for "#!/usr/...python3" in the launcher on Windows. Cheers, 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] PEP 441 - Improving Python ZIP Application Support
On 16 February 2015 at 16:42, Paul Moore wrote: > My point is that on Windows, users typically don't change the > executable name they use[1], but rather configure the "python" (or > "py") command to do what they want. So I think that on Windows we > should follow that convention and execute whatever "python"/"py" > execute. One other thought. We could add "short form" options for -p to the zipapp command: -p X[.Y]Use "#!/usr/bin/env pythonX[.Y]" as the shebang. I'd definitely want the default to be "python" in that case, though, as it's the one you can't specify in a short form otherwise. 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 441 - Improving Python ZIP Application Support
On 16 February 2015 at 17:00, Mark Young wrote: > I don't know what anyone else does, but in cases where I have both on my > windows box, I do use python2(.x) and python3(.y) . If I only have one > version on the box, I use the generic name of course. (I don't often have > only one version on my boxes though. 2.x inevitably gets drug in in for some > reason or another and I hardly ever uninstall old versions of 3.x) I don't > use the launcher though, so I might be out-of-scope entirely. (in which > case, sorry for the noise) No, that's good to know. One clarification, though - if you only have Python 3, I get the impression you use "python" and not "python3" then...? 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 441 - Improving Python ZIP Application Support
If I only have one version on my box, yes, I only use "python". But like I said, for me personally, that situation doesn't last very long. ___ 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] [Python-checkins] cpython (3.4): Issue #23446: Use PyMem_New instead of PyMem_Malloc to avoid possible integer
On Mon, Feb 16, 2015 at 11:35:52AM +, serhiy.storchaka wrote:
> diff --git a/Modules/_testbuffer.c b/Modules/_testbuffer.c
> --- a/Modules/_testbuffer.c
> +++ b/Modules/_testbuffer.c
> @@ -850,7 +850,7 @@
> Py_ssize_t *dest;
> Py_ssize_t x, i;
>
> -dest = PyMem_Malloc(len * (sizeof *dest));
> +dest = PyMem_New(Py_ssize_t, len);
> if (dest == NULL) {
> PyErr_NoMemory();
> return NULL;
This, too, was already protected by len == ndim <= 64.
Stefan Krah
___
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 441 - Improving Python ZIP Application Support
Paul Moore wrote: The alternative, I guess, is to have *no* default and write no shebang unless -p is specified. +1. That sounds like a very good idea to me. -- Greg ___ 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] [Python-checkins] cpython (3.4): Issue #23446: Use PyMem_New instead of PyMem_Malloc to avoid possible integer
2015-02-16 17:34 GMT+01:00 Stefan Krah :
>
> On Mon, Feb 16, 2015 at 11:35:52AM +, serhiy.storchaka wrote:
>> diff --git a/Modules/_testbuffer.c b/Modules/_testbuffer.c
>> --- a/Modules/_testbuffer.c
>> +++ b/Modules/_testbuffer.c
>> @@ -850,7 +850,7 @@
>> Py_ssize_t *dest;
>> Py_ssize_t x, i;
>>
>> -dest = PyMem_Malloc(len * (sizeof *dest));
>> +dest = PyMem_New(Py_ssize_t, len);
>> if (dest == NULL) {
>> PyErr_NoMemory();
>> return NULL;
>
> This, too, was already protected by len == ndim <= 64.
I don't understand why you don't want to use PyMem_New() even if it
cannot overflow. PyMem_New() is more readable no?
Victor
___
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 441 - Improving Python ZIP Application Support
On 15 February 2015 at 17:46, Daniel Holth wrote: > Go ahead, make my pep. > > I will appreciate seeing it happen. Here is a draft update for PEP 441. It's still a work in progress - in particular I want to wait for consensus on the issue of the default interpreter before finalising it. But I thought it would be worth having a full spec available for people. PEP: 441 Title: Improving Python ZIP Application Support Version: $Revision$ Last-Modified: $Date$ Author: Daniel Holth , Paul Moore Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30 March 2013 Post-History: 30 March 2013, 1 April 2013, 16 February 2015 Improving Python ZIP Application Support Python has had the ability to execute directories or ZIP-format archives as scripts since version 2.6 [1]_. When invoked with a zip file or directory as its first argument the interpreter adds that directory to sys.path and executes the __main__ module. These archives provide a great way to publish software that needs to be distributed as a single file script but is complex enough to need to be written as a collection of modules. This feature is not as popular as it should be mainly because it was not promoted as part of Python 2.6 [2]_, so that it is relatively unknown, but also because the Windows installer does not register a file extension (other than .py) for this format of file, to associate with the launcher. This PEP proposes to fix these problems by re-publicising the feature, defining the .pyz and .pyzw extensions as “Python ZIP Applications” and “Windowed Python ZIP Applications”, and providing some simple tooling to manage the format. A New Python ZIP Application Extension == The Python 3.5 installer will associate .pyz and .pyzw “Python ZIP Applications” with the platform launcher so they can be executed. A .pyz archive is a console application and a .pyzw archive is a windowed application, indicating whether the console should appear when running the app. For UNIX users, .pyz applications should typically be prefixed with a #! line pointing to the correct Python interpreter and an optional explanation:: #!/usr/bin/env python3 # Python application packed with zipapp module (binary contents of archive) However, it is always possible to execute a .pyz application by supplying the filename to the Python interpreter directly. As background, ZIP archives are defined with a footer containing relative offsets from the end of the file. They remain valid when concatenated to the end of any other file. This feature is completely standard and is how self-extracting ZIP archives and the bdist_wininst installer format work. Minimal Tooling: The zipapp Module == This PEP also proposes including a module for working with these archives. The module will contain functions for working with Python zip application archives, and a command line interface (via ``python -m zipapp``) for their creation and manipulation. Module Interface The zipapp module will provide the following functions: ``pack(target, directory, interpreter=None, main=None)`` Writes an application archive called ``target``, containing the contents of ``directory``. If ``interpreter`` is specified, it will be written to the start of the archive as a shebang line and the file will be made executable (if no interpreter is specified, the shebang line will be omitted). If the directory contains no ``__main__.py`` file, the function will construct a ``__main__.py`` which calls the function specified in the ``main`` argument (which should be in the form ``"pkg.mod:fn"``). It is an error to specify ``main`` if the directory contains a ``__main__.py``, or to omit ``main`` when there is no ``__main__.py`` (as that will result in an archive which has no main function and so cannot be executed). ``get_interpreter(archive)`` Returns the interpreter specified in the shebang line of the archive. If there is no shebang, the function returns None. ``set_interpreter(archive, new_archive, interpreter=None)`` Modifies the archive's shebang line to contain the specified interpreter, and writes the updated archive to new_archive. If the interpreter is None, removes the shebang line. Command Line Usage -- The zipapp module can be run with the python -m flag. The command line interface is as follows:: python -m zipapp [options] directory Create an archive from the contents of the given directory. By default, an archive will be created with the same name as the source directory, with a .pyz extension. The following options can be specified: -o archive The destination archive will have the specified name. -p interpreter The given interpreter will be written to the shebang line of the archive. If this option is not gi
[Python-Dev] Python 3.4 RPM on AIX
Blaxton writes: > I am having problem building Python RPM on AIX and I think there > are several bugs in Python .spec files. This list is for development *of* Python, not development *with* Python. In this case, you would probably be better off with an AIX list devoted to packaging, an RPM-specific list, or failing those two, a Red Hat/Fedora list on packaging. All of the issues you list are related to generic distro packaging issues, and not to Python itself. ___ 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] Python 3.4 RPM on AIX
I am using the spec file that comes with Python source code which downloaded from python.org website source file is set on spec file to file with bz2 format while there is only .xz and zipped are available to download. I thought somehow some one from development team has wrote that .spec fileand maybe supporting it. This is like no support. From: Stephen J. Turnbull To: Blaxton Cc: "python-dev@python.org" Sent: Monday, February 16, 2015 10:02 PM Subject: [Python-Dev] Python 3.4 RPM on AIX Blaxton writes: > I am having problem building Python RPM on AIX and I think there > are several bugs in Python .spec files. This list is for development *of* Python, not development *with* Python. In this case, you would probably be better off with an AIX list devoted to packaging, an RPM-specific list, or failing those two, a Red Hat/Fedora list on packaging. All of the issues you list are related to generic distro packaging issues, and not to Python itself. ___ 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] Python 3.4 RPM on AIX
On Mon, Feb 16, 2015 at 10:50 PM, Blaxton wrote: > I am using the spec file that comes with Python source code which downloaded > from python.org website > source file is set on spec file to file with bz2 format while there is only > .xz and zipped are available to download. > > > I thought somehow some one from development team has wrote that .spec file > and maybe supporting it. > > This is like no support. The spec file in Misc/RPM has not been maintained in quite some time; the last change to that file that wasn't just a version bump was one [1] whose commit message was "#5776: fix mistakes in python specfile. (Nobody probably uses it anyway.)" and was committed four and a half years ago. It's not unlikely that you're the first person to use the file since then :). We should probably just remove the file, but if you manage to get it working and would like to provide a patch on bugs.python.org, it would probably be accepted. [1] https://hg.python.org/cpython/rev/ef75ecd0e1a7 -- Zach ___ 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
