We don't put stubs of PEPs into the repository, especially when they have
not been vetted on python-ideas or some other public mailing list that is
appropriate for the subject.
You also mis-capitalized PyPy in this commit.
On Thu, Sep 20, 2012 at 6:44 PM, daniel.holth <python-checkins(a)python.org>wrote:
> changeset: 4514:4ac055623f2a
> user: Daniel Holth <dholth(a)fastmail.fm>
> date: Thu Sep 20 18:43:53 2012 -0400
> add stub for wheel spec
> pep-0425.txt | 7 +++----
> pep-0427.txt | 30 ++++++++++++++++++++++++++++++
> 2 files changed, 33 insertions(+), 4 deletions(-)
> diff --git a/pep-0425.txt b/pep-0425.txt
> --- a/pep-0425.txt
> +++ b/pep-0425.txt
> @@ -81,10 +81,9 @@
> 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 uses versions
> -do not track the Python language version and should probably use its own
> -versions here `pp18`, `pp19`.
> +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.
> diff --git a/pep-0427.txt b/pep-0427.txt
> new file mode 100644
> --- /dev/null
> +++ b/pep-0427.txt
> @@ -0,0 +1,30 @@
> +PEP: 426
> +Title: The Wheel Binary Package Format 1.0
> +Version: $Revision$
> +Last-Modified: $Date$
> +Author: Daniel Holth <dholth(a)fastmail.fm>
> +Discussions-To: Distutils SIG
> +Status: Draft
> +Type: Standards Track
> +Content-Type: text/x-rst
> +Created: 20 Sep 2012
> +This PEP describes a binary format for Python called wheel.
> +This document has been placed in the public domain.
> + Local Variables:
> + mode: indented-text
> + indent-tabs-mode: nil
> + sentence-end-double-space: t
> + fill-column: 70
> + End:
> Repository URL: http://hg.python.org/peps
> Python-checkins mailing list
I have recently been experimenting with the memoryview() built-in and have come to believe that it really needs to expose the 'buf' attribute of the underlying Py_buffer structure as an integer (see PEP 3118). Let me explain.
The whole point of PEP 3118 (as I understand it) is to provide a means for exchanging or sharing array data across different libraries such as numpy, PIL, ctypes, Cython, etc. If you're working with Py_buffer objects at the C level, this works fine. However, if you're working purely in Python, you're only able to get partial information about memory views such as the shape and size. You can't get the actual pointer to the underlying memory (unless I've missed something obvious).
This is unfortunate because it means that you can't write Python code to link memoryviews to other kinds of compiled code that might want to operate on array-oriented data. For example, you can't pass the raw pointer into a function that you've exposed via ctypes. Similarly, you can't pass the pointer into functions you've dynamically compiled using libraries such as LLVM-py. There might be other kinds of applications, but just having that one bit of extra information available would be useful for various advanced programming techniques involving extensions and memory buffers.
I suspect I've missed the boat on this one (certainly for 3.3.0), but
here goes. The new TypeError reporting for bad function calls is a
huge improvement (thanks Benjamin!), but I have one small nitpick:
what *is* a positional argument? For example:
>>> def f(x): pass
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: f() missing 1 required positional argument: 'x'
I think it's confusing to describe 'x' as a positional argument. It's
a required formal parameter, certainly. But a caller of 'f' could
pass 'x' either by position or by 'keyword'.
When running training (generally Python 2.6 or 2.7 based), I
frequently have to devote some time to unravelling student confusion
between 'arguments passed by keyword' on one hand and 'optional formal
parameters' on the other. The outline of the explanation goes
(0) Preamble: be careful to separate out details of function calling
from those of function definition; distinguish formal parameters from
(1) On the function *definition* side, formal parameters may be either
*required* or *optional*.
(2) On the function *calling* side, actual arguments may be passed
either positionally or by keyword.
(3) The notions in (1) and (2) are entirely orthogonal!
(3a) (Although in practice, callers tend to use pass-by-keyword for
optional formal parameters.)
That's all for Python 2; Python 3, of course, requires a bit more
explanation related to the keyword-only arguments.
There already seems to be a fair amount of confusion in the Python
world about point (3); I've seen professional Python training slides
that show how to define optional formal parameters under the heading
I submit that the word 'positional' in the TypeError message
exacerbates this confusion, and that little would be lost by simply
dropping it from the exception message.
I am working with PYTHON 1.5 and want to control versions of every pyo
Is there any way I can assign a file version to every pyo file without
writing a variable inside every py file that holds it?
Thanks a lot,
I was wondering if anyone knows if the removed Lib/packaging directory
landed in some other places after it was removed.
We have http://hg.python.org/distutils2 be the 'packaging' version is a
full py3-renamed version we need to keep mirrored
On 09/16/2012 06:04 AM, solipsis(a)pitrou.net wrote:
> results for 1704deb7e6d7 on branch "default"
> test_dbm leaked [0, 2, 0] references, sum=2
I've noticed that test_dbm fairly often leaks here although I've never
reproduced it. Does anyone know with which dbm lib this is (gdbm, ndbm,
I've drafted some edits to Metadata 1.2 with valuable feedback from
distutils-sig (special thanks to Erik Bray), which seems to have no
more comments on the issue after about 6 weeks. Let me know if you
have an opinion, or if you will have one during some bounded time in
Metadata 1.2 (PEP 345), a non-final PEP that has been adopted by
approximately 10 of the latest sdists from pypy, cannot represent the
setuptools "extras" (optional dependencies) feature. This is a problem
because about 1600+ or 10% of the packages hosted on pypy define
"extras" as measured in May of this year.
The edit implements the extras feature by adding a new condition
"extra == 'name'" to the Metadata 1.2 environment markers.
Requirements with this marker are only installed when the named
optional feature is requested. Valid extras for a package must be
declared with Provides-Extra: name.
It also adds Setup-Requires-Dist as a way to specify requirements
needed during an install as opposed to during runtime.
Setup-Requires-Dist (multiple use)
Like Requires-Dist, but names dependencies needed while the
distributions's distutils / packaging `setup.py` / `setup.cfg` is run.
Provides-Extra (multiple use)
A string containing the name of an optional feature.
Requires-Dist: reportlab; extra == 'pdf'
Requires-Dist: nose; extra == 'test'
Requires-Dist: sphinx; extra == 'doc'
(full changeset on