[Python-Dev] x86 osx 5 buildbot slave
I have to shutdown the x86 osx 5 buildbot slave permanently, because the machine is getting a new role. Martin, please remove it from the configuration. -- Thanks, Thomas ___ 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] Providing support files to assist 3.x extension authors
On Sun, Dec 20, 2009 at 12:49 AM, "Martin v. Löwis" wrote: >> Several questions come to mind: >> >> 1) Is it reasonable to provide backward compatibility files (either as >> .h or .c) to provide support to new API calls to extension authors? > > I'm skeptical. In my experience, each extension has different needs, and > will also use different strategies to provide compatibility. So > publishing one way as the "official" approach might be difficult. In one > case, the proposed approach for compatibility actually led to incorrect > code (by ignoring exceptions when extracting a long), so we would need > to be fairly careful what compatibility layers we can bless as official. > >> 2) If yes, should they be included with the Python source or >> distributed as a separate entity? (2to3 and/or 3to2 projects, a Wiki >> page) > > In the way you propose it (i.e. as forward compatibility files) I fail > to see the point of including them with Python 2.7. Extension authors > likely want to support versions of Python before that, which now cannot > be changed. So those authors would still have to include the file > on their own. > > So a file distributed in Include of 2.7 actually hurts, as it would > conflict with the copy included in packages. > >> 3) If not, and extension authors can create their own compatibility >> files, are there any specific attribution or copyright messages that >> must be included? > > If you write a compatibility file from scratch, without copying existing > code, you don't need to worry at all. If you do copy parts of Python, > you must follow the license, in particular clause 2. > > Regards, > Martin > Thanks for comments. I will just maintain my own version. Case ___ 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] Disallow float arguments where an integer is expected in Python 2.7.
In Python 2.7, PyArg_ParseTuple and friends currently accept a float argument where an integer is expected, but produce a DeprecationWarning in this case. This can be seen in various places in Python proper: >>> itertools.combinations(range(5), 2.0) __main__:1: DeprecationWarning: integer argument expected, got float Are there any objections to turning this DeprecationWarning into a TypeError for Python 2.7? The behaviour has been deprecated since Python 2.3, it's gone in 3.x, and having it produce an error in 2.7 might slightly reduce the number of surprises involved in porting from 2.x to 3.x. There's a patch at http://bugs.python.org/issue5080 There's one fly in the ointment: the deprecation warning is produced for all integer codes except for one---the 'L' code. The patch adds a deprecation warning for this code. Mark ___ 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] Disallow float arguments where an integer is expected in Python 2.7.
On Mon, Dec 21, 2009 at 07:02, Mark Dickinson wrote: > In Python 2.7, PyArg_ParseTuple and friends currently accept a float > argument where an integer is expected, but produce a > DeprecationWarning in this case. This can be seen in various places > in Python proper: > > >>> itertools.combinations(range(5), 2.0) > __main__:1: DeprecationWarning: integer argument expected, got float > > > Are there any objections to turning this DeprecationWarning into a > TypeError for Python 2.7? The behaviour has been deprecated since > Python 2.3, it's gone in 3.x, and having it produce an error in 2.7 > might slightly reduce the number of surprises involved in porting from > 2.x to 3.x. There's a patch at http://bugs.python.org/issue5080 > > I'm +0 -Brett ___ 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] x86 osx 5 buildbot slave
Thomas Heller wrote: > I have to shutdown the x86 osx 5 buildbot slave permanently, because > the machine is getting a new role. Martin, please remove it from > the configuration. Thanks for the notice; I have now removed it from the list. Regards, Martin ___ 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] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Hi, On behalf of the Distutils-SIG, I would like to propose to addition of PEP 345 (once and *if* PEP 386 is accepted). It's the metadata v1.2: http://www.python.org/dev/peps/pep-0345/ PEP 345 was initiated a while ago by Richard Jones, and reworked since then together with PEP 386, at Pycon last year and in Distutils-SIG. The major enhancements are: - being able to express dependencies on other *distributions* names, rather than packages names or modules names. This enhancement comes from Setuptools and has been used successfully for years by the community. - being able to express some fields which values are specific to some platforms. For example, being able to define "pywin32" as a dependency *only* on win32. This enhancement will allow any tool to query PyPI and to get the metadata for a particular execution context, without having to download, build, or install the project itself. - being able to provide a list of browsable URLs for the project, like a bug tracker, a repository etc, in addition to the home url. This will allow UIs like PyPI to display a list of URLs for a project. A side-effect will be that a project maintainer will be able to drive its end users to the right places when they need to find detailed documentation or provide some feedback. This enhancement was driven by the discussions about the rating/comment system at PyPI on catalog-sig. We believe that having PEP 386 and PEP 345 accepted will be a major improvement for the Python packaging eco-system. The next PEP in the series we are working on is PEP 376. As a side note, I would really like to see them (hopefully) accepted before the first beta of Python 2.7 so we can add these features in 2.7/3.2 and start to work on third-party tools (Distribute, Pip, a standalone version of Distutils for 2.6/2.5, etc..) to get ready to support them by the time 2.7 final is out. Regards Tarek -- Tarek Ziadé | http://ziade.org ___ 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] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Tarek Ziadé wrote: > Hi, > > On behalf of the Distutils-SIG, I would like to propose to addition of > PEP 345 (once and *if* PEP 386 is accepted). +1 for integrating all the good work the catalog-sig folks have been doing. Some comments on PEP 345 specifically though: The deprecation of the existing Requires/Provides/Obsoletes fields should be more prominent - tucked away below the examples, I missed these notices on the first read through (I only noticed that they actually had been formally deprecated when I got to the summary of differences at the end). I suggest placing the deprecation notice immediately after the relevant field headers. There also needs to be an explanation in the PEP as to whether or not it is legal to use both Requires and Requires-Dist (etc) in the same PKG-INFO file. (i.e. what is the use case for allowing the old fields to be used in a metadata v1.2 PKG-INFO file? Should PEP 345 aware packaging tools just ignore the old fields, while v1.1 tools ignore the new ones? Or should new tools attempt to handle both?) The various lines about there being no standards or canonical definitions for particular fields also seem to run counter to the spirit of the detailed guidelines in the description of each field (which imply that some standards have already been adopted by convention). Perhaps these comments could be softened to say that although the metadata specification formally allows arbitrary strings in these fields, the descriptions are recommended guidelines for creating field entries that automated tools will handle correctly? Finally, as a general formatting request - some blank space between the end of the previous example and the header for the next field description would make the field descriptions much easier to read. 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
