[Python-Dev] PYTHONSTARTUP and -i
Hello. Python doc says that the PYTHONSTARTUP file is not read when a script is run with the -i option. Is there a reason for this? Is there a way to get the functionality i.e. to be able to run specified Python file just before the first prompt of interactive interpreter? Use case: I want to run my own repl on Windows, because there's a problem with unicode IO in the console. See http://bugs.python.org/issue1602 . Regards, Drekin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2013-02-08 - 2013-02-15) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3845 ( -2) closed 25141 (+53) total 28986 (+51) Open issues with patches: 1664 Issues opened (38) == #6083: Reference counting bug in PyArg_ParseTuple and PyArg_ParseTupl http://bugs.python.org/issue6083 reopened by serhiy.storchaka #17162: Py_LIMITED_API needs a PyType_GenericDealloc http://bugs.python.org/issue17162 opened by bfroehle #17163: Fix test discovery for test_file.py http://bugs.python.org/issue17163 opened by zach.ware #17164: MozillaCookieJar does not handle session cookies http://bugs.python.org/issue17164 opened by piotr.dobrogost #17167: python man page contains $Date$ in page footer http://bugs.python.org/issue17167 opened by ned.deily #17170: string method lookup is too slow http://bugs.python.org/issue17170 opened by gvanrossum #17172: Add turtledemo to IDLE menu http://bugs.python.org/issue17172 opened by rhettinger #17174: Posix os.path.join should raise TypeError when passed unusable http://bugs.python.org/issue17174 opened by thomas.scrace #17175: update PEP 430 http://bugs.python.org/issue17175 opened by tshepang #17176: Document imp.NullImporter is NOT used anymore by import http://bugs.python.org/issue17176 opened by brett.cannon #17177: Document/deprecate imp http://bugs.python.org/issue17177 opened by brett.cannon #17178: In all.__doc__ and any.__doc__ need to clarify the behaviour w http://bugs.python.org/issue17178 opened by py.user #17179: Incorrect use of type function in types.new_class http://bugs.python.org/issue17179 opened by cjw296 #17180: shutil copy* unsafe on POSIX - they preserve setuid/setgit bit http://bugs.python.org/issue17180 opened by milko.krachounov #17181: SSLContext.set_servername_callback should be able to setargum http://bugs.python.org/issue17181 opened by grooverdan #17182: signal.default_int_handler should set signal number on the rai http://bugs.python.org/issue17182 opened by pitrou #17183: Small enhancements to Lib/_markupbase.py http://bugs.python.org/issue17183 opened by guido.reina #17184: re.VERBOSE doesn't respect whitespace in '( ?Pfoo...)' http://bugs.python.org/issue17184 opened by roysmith #17185: create_autospec http://bugs.python.org/issue17185 opened by cjw296 #17186: no way to introspect registered atexit handlers http://bugs.python.org/issue17186 opened by cjw296 #17187: Python segfaults from improperly formed and called function http://bugs.python.org/issue17187 opened by larry #17188: Document 'from None' in raise statement doc. http://bugs.python.org/issue17188 opened by terry.reedy #17189: Add zip64 support to shutil http://bugs.python.org/issue17189 opened by william.mallard #17191: pdb list shows unexpected code when stack frame includes a try http://bugs.python.org/issue17191 opened by AbramClark #17192: libffi-3.0.12 import http://bugs.python.org/issue17192 opened by doko #17193: Use binary prefixes http://bugs.python.org/issue17193 opened by serhiy.storchaka #17197: c/profile refactoring http://bugs.python.org/issue17197 opened by giampaolo.rodola #17198: dbm.whichdb references unitialized 'ndbm' variable http://bugs.python.org/issue17198 opened by pjenvey #17200: telnetlib.read_until() timeout uses the wrong units http://bugs.python.org/issue17200 opened by Reuben.D'Netto #17201: Use allowZip64=True by default http://bugs.python.org/issue17201 opened by serhiy.storchaka #17202: Add .bat line to .hgeol http://bugs.python.org/issue17202 opened by zach.ware #17203: add long option names to unittest discovery docs http://bugs.python.org/issue17203 opened by chris.jerdonek #17204: argparser's subparsers.add_parser() should accept an ArgumentP http://bugs.python.org/issue17204 opened by chris.jerdonek #17206: Py_XDECREF() expands its argument multiple times http://bugs.python.org/issue17206 opened by dmalcolm #17208: add note/warning about daemon threads http://bugs.python.org/issue17208 opened by pitrou #17209: get_wch() doesn't handle KeyboardInterrupt http://bugs.python.org/issue17209 opened by raymontag #17210: documentation of PyUnicode_Format() states wrong argument type http://bugs.python.org/issue17210 opened by scoder #17211: pkgutil.iter_modules and walk_packages should return a namedtu http://bugs.python.org/issue17211 opened by Ramchandra.Apte Most recent 15 issues with no replies (15) == #17211: pkgutil.iter_modules and walk_packages should return a namedtu http://bugs.python.org/issue17211 #17210: documentation of PyUnicode_Format() states wrong argument type http://bugs.python.org/issue17210 #17209: get_wch() doesn't handle KeyboardInterrupt http://bugs.python.org/issue17209 #17204: argparser's subparsers.add_parser() should accept
Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, Feb 3, 2013 at 5:24 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Éric Araujo merwok at netwok.org writes: Looks like we agree that a basic tool able to bootstrap the packaging story is needed :) Agreed. Just because distutils can't easily/reliably build things that are better built with SCons/WAF/tup/whatever, doesn't mean that we shouldn't have the ability to build pure-Python distributions and distributions including C libs and extensions, with the ability to extend easily by third-party tools. It just needs to be done in a way which is easy to build on, so the included battery stays small and simple. Easier said than done, I know :-) Regards, Vinay Sajip Sorry to revive an old-ish discussion--I'm just catching up on things. But I just wanted to add that distutils is still pretty okay for building reasonably complex projects. Although it does not rise to the level of complexity of Numpy or SciPy, the Astropy project (https://github.com/astropy/astropy) has managed to put together a pretty nice build system on top of mostly-plain distutils (it does use distribute but primarily just for 2to3 support). This has necessitated a number of hacks to overcome shortcomings and bugs in distutils, but most of those shortcomings could probably be fixed in distutils within the framework of a slightly lifted freeze. But in any case I haven't found it worthwhile to switch to something like bento when the batteries included in the stdlib have been mostly Good Enough. Having fewer installation dependencies has also made it significantly easier for non-advanced users to install. Even the distribute requirement doesn't add too much overhead, as most users have it on their systems by default now, and for those who don't distribute_setup.py works okay. TL;DR, strong -1 on the stdlib getting out of the build business. Also as I think Nick already mentioned one of the wins of Setup-Requires-Dist is to have a standard way to bring in extra build requirements (such as bento) so if we have better support for a feature like that it's not necessary to bless any preferred tool. Erik ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PYTHONSTARTUP and -i
Hello. Python doc says that the PYTHONSTARTUP file is not read when a script is run with the -i option. Is there a reason for this? Is there a way to get the functionality i.e. to be able to run specified Python file just before the first prompt of interactive interpreter? Use case: I want to run my own repl on Windows, because there's a problem with unicode IO in the console. See http://bugs.python.org/issue1602 . Regards, Drekin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A new webpage promoting Compiler technology for CPython
Hey all, With Numba and Blaze we have been doing a lot of work on what essentially is compiler technology and realizing more and more that we are treading on ground that has been plowed before with many other projects. So, we wanted to create a web-site and perhaps even a mailing list or forum where people could coordinate and communicate about compiler projects, compiler tools, and ways to share efforts and ideas. The website is: http://compilers.pydata.org/ This page is specifically for Compiler projects that either integrate with or work directly with the CPython run-time which is why PyPy is not presently listed. The PyPy project is a great project but we just felt that we wanted to explicitly create a collection of links to compilation projects that are accessible from CPython which are likely less well known. But that is just where we started from. The website is intended to be a community website constructed from a github repository. So, we welcome pull requests from anyone who would like to see the website updated to reflect their related project.Jon Riehl (Mython, PyFront, ROFL, and many other interesting projects) and Stephen Diehl (Blaze) and I will be moderating the pull requests to begin with. But, we welcome others with similar interests to participate in that effort of moderation. The github repository is here: https://github.com/pydata/compilers-webpage This is intended to be a community website for information spreading, and so we welcome any and all contributions. Thank you, Travis Oliphant ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Fri, Feb 15, 2013 at 12:27 PM, Erik Bray erik.m.b...@gmail.com wrote: On Sun, Feb 3, 2013 at 5:24 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Éric Araujo merwok at netwok.org writes: Looks like we agree that a basic tool able to bootstrap the packaging story is needed :) Agreed. Just because distutils can't easily/reliably build things that are better built with SCons/WAF/tup/whatever, doesn't mean that we shouldn't have the ability to build pure-Python distributions and distributions including C libs and extensions, with the ability to extend easily by third-party tools. It just needs to be done in a way which is easy to build on, so the included battery stays small and simple. Easier said than done, I know :-) Regards, Vinay Sajip Sorry to revive an old-ish discussion--I'm just catching up on things. But I just wanted to add that distutils is still pretty okay for building reasonably complex projects. Although it does not rise to the level of complexity of Numpy or SciPy, the Astropy project (https://github.com/astropy/astropy) has managed to put together a pretty nice build system on top of mostly-plain distutils (it does use distribute but primarily just for 2to3 support). This has necessitated a number of hacks to overcome shortcomings and bugs in distutils, but most of those shortcomings could probably be fixed in distutils within the framework of a slightly lifted freeze. But in any case I haven't found it worthwhile to switch to something like bento when the batteries included in the stdlib have been mostly Good Enough. Having fewer installation dependencies has also made it significantly easier for non-advanced users to install. Even the distribute requirement doesn't add too much overhead, as most users have it on their systems by default now, and for those who don't distribute_setup.py works okay. TL;DR, strong -1 on the stdlib getting out of the build business. Also as I think Nick already mentioned one of the wins of Setup-Requires-Dist is to have a standard way to bring in extra build requirements (such as bento) so if we have better support for a feature like that it's not necessary to bless any preferred tool. Distutils is not really going away. We need it to build the existing 28,000 packages. However empirically it seems if you try to write a significant extension to or improvement of distutils then you are likely to get burnt out and switch careers. Instead of literally killing distutils we hope to make it very easy to use other build tools when you need them and not use any build tools at all when you don't. As a thought experiment: what if one of those third party build tools hosted on pypi was distutils itself? What would you need to do to make that happen? The packaging peps PEP-376 and so on are brilliant because they are simple enough to be implemented twice. If we had better ways to separate interface from implementation in Python I'd like to see two of whatever else we come up with for packaging. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new webpage promoting Compiler technology for CPython
Travis Oliphant wrote: With Numba and Blaze we have been doing a lot of work on what essentially is compiler technology and realizing more and more that we are treading on ground that has been plowed before with many other projects. So, we wanted to create a web-site and perhaps even a mailing list or forum where people could coordinate and communicate about compiler projects, compiler tools, and ways to share efforts and ideas. The website is: http://compilers.pydata.org/ This is a rather nice resource. Thank you for letting us know about it! There has been an attempt to record different Python implementations on the Python Wiki, and now that this is available again, I'd like to remind people about it: http://wiki.python.org/moin/PythonImplementations I know that this isn't quite the same thing as a page about compiler technology, but there is a substantial overlap. This page is specifically for Compiler projects that either integrate with or work directly with the CPython run-time which is why PyPy is not presently listed. The PyPy project is a great project but we just felt that we wanted to explicitly create a collection of links to compilation projects that are accessible from CPython which are likely less well known. I think that given the scope of the projects listed, it shouldn't preclude PyPy from being listed, really. After all, interoperability with CPython extensions is something of a focus area for PyPy: http://pypy.org/compat.html I don't have an agenda here - I don't use PyPy actively, my only involvement with Shedskin (which is referenced and which can produce CPython extension modules) is in packaging it for Debian, and although I do have a static analysis library I see no pressing need to promote it extensively - but I feel that when it comes to educational resources people should be a bit careful about drawing boundaries that exclude things that would benefit people substantially if they only knew about it. My reason for speaking up about this is that I've had to tell a room full of people who were told to use Cython, NumPy and even plain C to make their Python programs faster that PyPy existed. (Of course, one can justify ignoring the elephant in the room by claiming things like scientific users rely on native libraries or CPython extensions - since science is a very broad term, this obviously isn't universally true - but I think people should be entitled to make their own minds up, and I was not completely certain that everyone involved in the case in question was oblivious to PyPy's existence or status.) But that is just where we started from. The website is intended to be a community website constructed from a github repository. So, we welcome pull requests from anyone who would like to see the website updated to reflect their related project.Jon Riehl (Mython, PyFront, ROFL, and many other interesting projects) and Stephen Diehl (Blaze) and I will be moderating the pull requests to begin with. But, we welcome others with similar interests to participate in that effort of moderation. The github repository is here: https://github.com/pydata/compilers-webpage This is intended to be a community website for information spreading, and so we welcome any and all contributions. There is also the python-static-type-checking Google Group: https://groups.google.com/forum/?fromgroups#!forum/python-static-type-checking If no-one beats me to it, I may post details of the site to that group because it may well be of interest to the members. Thanks once again for bringing such information together in one place! Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new webpage promoting Compiler technology for CPython
Paul Boddie, 15.02.2013 22:44: Travis Oliphant wrote: This page is specifically for Compiler projects that either integrate with or work directly with the CPython run-time which is why PyPy is not presently listed. The PyPy project is a great project but we just felt that we wanted to explicitly create a collection of links to compilation projects that are accessible from CPython which are likely less well known. I think that given the scope of the projects listed, it shouldn't preclude PyPy from being listed, really. After all, interoperability with CPython extensions is something of a focus area for PyPy: http://pypy.org/compat.html I don't have an agenda here - I don't use PyPy actively, my only involvement with Shedskin (which is referenced and which can produce CPython extension modules) is in packaging it for Debian, and although I do have a static analysis library I see no pressing need to promote it extensively - but I feel that when it comes to educational resources people should be a bit careful about drawing boundaries that exclude things that would benefit people substantially if they only knew about it. My reason for speaking up about this is that I've had to tell a room full of people who were told to use Cython, NumPy and even plain C to make their Python programs faster that PyPy existed. (Of course, one can justify ignoring the elephant in the room by claiming things like scientific users rely on native libraries or CPython extensions - since science is a very broad term, this obviously isn't universally true - but I think people should be entitled to make their own minds up, and I was not completely certain that everyone involved in the case in question was oblivious to PyPy's existence or status.) This is off-topic for this list, but the main problem with PyPy is that you'll quickly hit a lot of walls when you try to use it for anything serious in the area. It's true that there is a certain level of interoperability with CPython extensions, but calling it a focus area makes it sound bigger than it actually is in my ears. Even trying to get bugs fixed to at least make things work at all often means running against walls on their side. I can tell, trying to port Cython mostly consisted of bugging PyPy developers to fix stuff, which took anything from days to still-not-done, each time. And, by design, PyPy makes it very hard and time consuming to debug it and to try to fix bugs in their code base. So, while I agree that PyPy is worth a try in certain application areas, and can be helpful for some special needs, also in the field of scientific computing, it's lightyears away from a production-ready state in that area. It just doesn't integrate with the huge bulk of software that people use in their daily work. And once you rely on that software, which is hand tuned, well integrated and real-world proven in so many ways, over the time span of way more than a decade, the most visible advantage of PyPy to make Python code run faster becomes almost pointless. In that light, telling people to try PyPy and to drop (most of) their current ecosystem for it doesn't really sound helpful and clearly appears outside of the focus of the web site in question. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new webpage promoting Compiler technology for CPython
On Fri, Feb 15, 2013 at 2:36 PM, Stefan Behnel stefan...@behnel.de wrote: This is off-topic for this list, but the main problem with PyPy is that you'll quickly hit a lot of walls when you try to use it for anything serious in the area. It's true that there is a certain level of interoperability with CPython extensions, but calling it a focus area makes it sound bigger than it actually is in my ears. Even trying to get bugs fixed to at least make things work at all often means running against walls on their side. I can tell, trying to port Cython mostly consisted of bugging PyPy developers to fix stuff, which took anything from days to still-not-done, each time. And, by design, PyPy makes it very hard and time consuming to debug it and to try to fix bugs in their code base. I take issue with how you've described this, Stefan: I recall many on pypy-dev working with you quite a bit on the Cython port. There are some difficult problems involved and the port is not a main focus of the core PyPy team -- there's only so many free cycles. You should ping us (IRC is great) about any outstanding issues. So, while I agree that PyPy is worth a try in certain application areas, and can be helpful for some special needs, also in the field of scientific computing, it's lightyears away from a production-ready state in that area. It just doesn't integrate with the huge bulk of software that people use in their daily work. And once you rely on that software, which is hand tuned, well integrated and real-world proven in so many ways, over the time span of way more than a decade, the most visible advantage of PyPy to make Python code run faster becomes almost pointless. In that light, telling people to try PyPy and to drop (most of) their current ecosystem for it doesn't really sound helpful and clearly appears outside of the focus of the web site in question. I disagree that it's pointless. Numba disagrees too: it also attempts to make Python code faster. PyPy is indeed a work in progress in this area, but that doesn't necessarily preclude it from being included. -- Philip Jenvey ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new webpage promoting Compiler technology for CPython
Stefan Behnel wrote: This is off-topic for this list, but the main problem with PyPy is that you'll quickly hit a lot of walls when you try to use it for anything serious in the area. It's true that there is a certain level of interoperability with CPython extensions, but calling it a focus area makes it sound bigger than it actually is in my ears. It is a focus area. They even have a Web page for it, which I mentioned. Even trying to get bugs fixed to at least make things work at all often means running against walls on their side. I can tell, trying to port Cython mostly consisted of bugging PyPy developers to fix stuff, which took anything from days to still-not-done, each time. And, by design, PyPy makes it very hard and time consuming to debug it and to try to fix bugs in their code base. I'm sure it is tricky to debug PyPy. However, complete compatibility with CPython for Python programs is a goal of the project, and I have no reason to doubt that the project is committed to supporting broader compatibility with CPython. So, while I agree that PyPy is worth a try in certain application areas, and can be helpful for some special needs, also in the field of scientific computing, it's lightyears away from a production-ready state in that area. You are generalising too broadly, which is precisely what I mentioned in my last message. There are also plenty of people doing science who aren't using numeric libraries or relying on native code libraries. What I most took exception to was either the lack of awareness of PyPy amongst people giving advice on how to speed up Python programs - not specifically numeric programs - to an audience of people who happened to be scientists, or the pretense that the first port of call was to break out Cython or NumPy when the easiest thing for them to do was to try their code on PyPy, provided they could get a package for it. One of my colleagues thought that you could always rewrite your code in C, which is what he took away from such recommendations, was hilarious advice for speeding up Python programs. You write your Python code in another language! Why not just use C in the first place? Not such a stupid question, really. It's a question that has been hanging around for far too long without a really good answer. It just doesn't integrate with the huge bulk of software that people use in their daily work. And once you rely on that software, which is hand tuned, well integrated and real-world proven in so many ways, over the time span of way more than a decade, the most visible advantage of PyPy to make Python code run faster becomes almost pointless. In that light, telling people to try PyPy and to drop (most of) their current ecosystem for it doesn't really sound helpful and clearly appears outside of the focus of the web site in question. For a very long time, and even now to some extent, you could say the same thing about Python 3. Personally, I suspect that some people have such a problem with PyPy that they would rather not mention it or see it mentioned. That's obviously a shame because not only does PyPy offer people an alternative, but it also encourages the development of software in Python, some of which appears on the resource being discussed, that would otherwise be written in C because that's what we would usually write this kind of software in. And although I don't actively use PyPy, mostly because of what the default Python implementation is on the platforms I use, I would like to see more actual Python code written. But I'm certainly not going to dwell on this matter any more than I've already done. I'm sure people will get something from the referenced resource regardless of whether any particular project is mentioned by it or not. Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Submitting PEP 425 (compatibility tags)
This is the improved compatibility tags PEP 425, specifying how part of the
Wheel PEP 427 filenames work. Last time we discussed whether replacing .
with _ was ugly but I concluded it was harmless.
Submitted for your consideration,
PEP: 425
Title: Compatibility Tags for Built Distributions
Version: $Revision$
Last-Modified: 07-Aug-2012
Author: Daniel Holth dho...@fastmail.fm
BDFL-Delegate: Nick Coghlan ncogh...@gmail.com
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 27-Jul-2012
Python-Version: 3.4
Post-History: 8-Aug-2012, 18-Oct-2012, 15-Feb-2013
Abstract
This PEP specifies a tagging system to indicate with which versions of
Python a built or binary distribution is compatible. A set of three
tags indicate which Python implementation and language version, ABI,
and platform a built distribution requires. The tags are terse because
they will be included in filenames.
PEP Editor's Note
=
While the naming scheme described in this PEP will not be supported directly
in the standard library until Python 3.4 at the earliest, draft
implementations may be made available in third party projects.
Rationale
=
Today python setup.py bdist generates the same filename on PyPy
and CPython, but an incompatible archive, making it inconvenient to
share built distributions in the same folder or index. Instead, built
distributions should have a file naming convention that includes enough
information to decide whether or not a particular archive is compatible
with a particular implementation.
Previous efforts come from a time where CPython was the only important
implementation and the ABI was the same as the Python language release.
This specification improves upon the older schemes by including the Python
implementation, language version, ABI, and platform as a set of tags.
By comparing the tags it supports with the tags listed by the
distribution, an installer can make an educated decision about whether
to download a particular built distribution without having to read its
full metadata.
Overview
The tag format is {python tag}-{abi tag}-{platform tag}
python tag
‘py27’, ‘cp33’
abi tag
‘cp32dmu’, ‘none’
platform tag
‘linux_x86_64’, ‘any’
For example, the tag py27-none-any indicates compatible with Python 2.7
(any Python 2.7 implementation) with no abi requirement, on any platform.
Use
===
The `wheel` built package format includes these tags in its filenames,
of the form ``{distribution}-{version}(-{build tag})?-{python tag}-{abi
tag}-{platform tag}.whl``. Other package formats may have their own
conventions.
Details
===
Python Tag
--
The Python tag indicates the implementation and version required by
a distribution. Major implementations have abbreviated codes, initially:
* py: Generic Python (does not require implementation-specific features)
* cp: CPython
* ip: IronPython
* pp: PyPy
* jy: Jython
Other Python implementations should use `sys.implementation.name`.
The version is `py_version_nodot`. CPython gets away with no dot,
but if one is needed the underscore `_` is used instead. PyPy should
probably use its own versions here `pp18`, `pp19`.
The version can be just the major version `2` or `3` `py2`, `py3` for
many pure-Python distributions.
Importantly, major-version-only tags like `py2` and `py3` are not
shorthand for `py20` and `py30`. Instead, these tags mean the packager
intentionally released a cross-version-compatible distribution.
A single-source Python 2/3 compatible distribution can use the compound
tag `py2.py3`. See `Compressed Tag Sets`, below.
ABI Tag
---
The ABI tag indicates which Python ABI is required by any included
extension modules. For implementation-specific ABIs, the implementation
is abbreviated in the same way as the Python Tag, e.g. `cp33d` would be
the CPython 3.3 ABI with debugging.
The CPython stable ABI is `abi3` as in the shared library suffix.
Implementations with a very unstable ABI may use the first 6 bytes (as
8 base64-encoded characters) of the SHA-256 hash of ther source code
revision and compiler flags, etc, but will probably not have a great need
to distribute binary distributions. Each implementation's community may
decide how to best use the ABI tag.
Platform Tag
The platform tag is simply `distutils.util.get_platform()` with all
hyphens `-` and periods `.` replaced with underscore `_`.
* win32
* linux_i386
* linux_x86_64
Use
===
The tags are used by installers to decide which built distribution
(if any) to download from a list of potential built distributions.
The installer maintains a list of (pyver, abi, arch) tuples that it
will support. If the built distribution's tag is `in` the list, then
it can be installed.
For example, an installer running under CPython 3.3 on a linux_x86_64
system might support::
1. cp33-cp33m-linux_x86_64
2. cp33-abi3-linux_x86_64
3. cp33-none-linux_x86_64
4. cp33-none-any
5. cp3-none-any
6.
Re: [Python-Dev] A new webpage promoting Compiler technology for CPython
Philip Jenvey, 16.02.2013 01:01: On Fri, Feb 15, 2013 at 2:36 PM, Stefan Behnel wrote: So, while I agree that PyPy is worth a try in certain application areas, and can be helpful for some special needs, also in the field of scientific computing, it's lightyears away from a production-ready state in that area. It just doesn't integrate with the huge bulk of software that people use in their daily work. And once you rely on that software, which is hand tuned, well integrated and real-world proven in so many ways, over the time span of way more than a decade, the most visible advantage of PyPy to make Python code run faster becomes almost pointless. In that light, telling people to try PyPy and to drop (most of) their current ecosystem for it doesn't really sound helpful and clearly appears outside of the focus of the web site in question. I disagree that it's pointless. Numba disagrees too: it also attempts to make Python code faster. That's not even the main goal AFAIK, but in any case, it does it from the very inside of the existing ecosystem, like all of the compilers (and related software) that are listed on the website. That's the whole point. PyPy is indeed a work in progress in this area, but that doesn't necessarily preclude it from being included. That may be a matter of POV, but as long as PyPy fails to integrate (and you just called that not a main focus), I find it hard to defend its relevance. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new webpage promoting Compiler technology for CPython
On 16/02/13 16:41, Stefan Behnel wrote: PyPy is indeed a work in progress in this area, but that doesn't necessarily preclude it from being included. That may be a matter of POV, but as long as PyPy fails to integrate (and you just called that not a main focus), I find it hard to defend its relevance. Stefan, you're talking about a website which lists projects such as a Forth- like language in Python, a bytecode transformer, a project Peregine-Falcon which appears to be a one-man experimental implementation of Python in C++, ByteRun, a pure-Python implementation of a Python bytecode execution virtual machine, and SPARK, which has been stuck in version 0.7 pre-alpha for years. I am astonished that you think PyPy is too immature or niche for this list. http://compilers.pydata.org/ -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new webpage promoting Compiler technology for CPython
Steven D'Aprano, 16.02.2013 07:13: On 16/02/13 16:41, Stefan Behnel wrote: PyPy is indeed a work in progress in this area, but that doesn't necessarily preclude it from being included. That may be a matter of POV, but as long as PyPy fails to integrate (and you just called that not a main focus), I find it hard to defend its relevance. Stefan, you're talking about a website which lists projects such as a Forth- like language in Python, a bytecode transformer, a project Peregine-Falcon which appears to be a one-man experimental implementation of Python in C++, ByteRun, a pure-Python implementation of a Python bytecode execution virtual machine, and SPARK, which has been stuck in version 0.7 pre-alpha for years. I am astonished that you think PyPy is too immature or niche for this list. http://compilers.pydata.org/ Hmm, I don't have the feeling that this discussion is leading anywhere (especially not on this list). After all, it's quite possible to fire up a PyPy runtime from a CPython runtime and have them talk to each other, letting each one do what it's good at. That doesn't make PyPy a compiler for CPython, but at least it means that it doesn't fail completely to integrate with the rest of the world. There are arguments for both sides, which means in dubio pro reo, I guess. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sat, Feb 16, 2013 at 3:27 AM, Erik Bray erik.m.b...@gmail.com wrote: TL;DR, strong -1 on the stdlib getting out of the build business. Also as I think Nick already mentioned one of the wins of Setup-Requires-Dist is to have a standard way to bring in extra build requirements (such as bento) so if we have better support for a feature like that it's not necessary to bless any preferred tool. I've described below where I personally hope we can get to by the time of Python 3.4. Please, if anyone has any comments on the below, send them to me via private email. I am only publishing this half-baked version to allay any concerns people may have that distutils itself might be going away in the foreseeable future (such concerns are perfectly understandable, given the many harsh things that have been said about distutils and the use of setup.py to drive the build process). (I plan to flesh this out further before the packaging distribution mini-summit at PyCon US, but it already reflects the general scheme I had in the back of my mind when I decided to step up as BDFL-delegate for Daniel's three PEPs related to the wheel format. There are obviously lots of details to be worked out on distutils-sig and catalog-sig, but the big advantage it has over the approach tried with distutils2 is that individual projects shouldn't have to change much of anything - this scheme is designed to work so long as I can convince at least the setuptools, distribute, distutils2, pip, bento and zc.buildout developers to support it. End users would just need to update to recent versions of their preferred tools or, in the case of current users of plain distutils, upgrade to setuptools/distribute or use the pip wheel subcommand to get wheel support in older versions of Python) Components: Archiver: creates sdist source archives for distribution Builder: creates wheel binary archives for installation or distribution Uploader: tool for publishing to PyPI and private index servers Installer: retrieves archives (and their dependencies) and installs them on a target system Proposed flow for source distribution: Development System: - Source checkout - Installer - Setup-Requires-Dist dependencies - Archiver - sdist - Uploader - PyPI (or private index server) Target System: - Installer - sdist + Setup-Requires-Dist dependencies - Builder - wheel - Installer - installed software + Requires-Dist dependencies Proposed flow for binary distribution: Development System: - Source checkout - Installer - Setup-Requires-Dist dependencies - Archiver - sdist - Builder - wheel - Uploader - PyPI (or private index server) Target System: - Installer - installed software + Requires-Dist dependencies Standard library (3.4): distlib: tools to create Archivers, Uploaders, Builders and Installers pydist: Uploader/Installer CLI distutils: Archiver/Builder CLI (via setup.py) (setup.py will also continue to function as a limited Uploader/Installer CLI) Alternate Archiver/Builder tools: setuptools, distribute, distutils2, bento (and various custom distutils derivatives) Alternate Installer tools: pip, easy_install, zc.buildout The pydist CLI would likely be deliberately limited to installation from wheel binary archives. The officially recommended approach to supporting installation from sdist on systems which do not provide pip preinstalled would then be pydist install pip. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new webpage promoting Compiler technology for CPython
On Sat, Feb 16, 2013 at 5:14 PM, Stefan Behnel stefan...@behnel.de wrote: Hmm, I don't have the feeling that this discussion is leading anywhere (especially not on this list). After all, it's quite possible to fire up a PyPy runtime from a CPython runtime and have them talk to each other, letting each one do what it's good at. That doesn't make PyPy a compiler for CPython, but at least it means that it doesn't fail completely to integrate with the rest of the world. There are arguments for both sides, which means in dubio pro reo, I guess. If anyone is interested in fast Python code that integrates cleanly with external C libraries, then the combination of PyPy and cffi (http://cffi.readthedocs.org/en/latest/) should definitely be on their list of candidates to consider. Now, it may be excluded quickly because there's a CPython extension involved in the project that isn't a trivial wrapper around an existing non-Python library (and thus can't be easily replaced with cffi), but that's no excuse for not at least considering the combination in the cases where it makes sense. Yes, the PyPy team and scientific users of Python have a long history of talking past each other (and abusing each other for the mutual lack of understanding). However, that's no excuse for deliberately ignoring the advantages JIT compilation can bring, when cffi has been created specifically to give PyPy a typesafe (and JIT-transparent) way to interface with any library that provides C bindings. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
