Re: [Python-Dev] Py_buffer.obj documentation
Alexander Belopolsky wrote: > /* info->obj is either NULL or a borrowed reference. This > reference should not be decremented in PyBuffer_Release(). */ The semantics of PyMemoryView_FromBuffer() are problematic. This function is the odd one in memoryobject.c since it's the only function that breaks the link in consumer -> exporter chains. This has several consequences: 1) One can't rely on the fact that 'info' has PyBUF_FULL information. This is a major inconvenience and the reason for *a lot* of code in memoryobject.c that reconstructs PyBUF_FULL information. 2) One has to make a decision whether PyMemoryView_FromBuffer() steals the reference to view.obj or treats it as a borrowed reference. My view on this is that it's safer to treat it as a borrowed reference. Additionally, I can't see a scenario where PyMemoryView_FromBuffer(info) could be used for creating a non-temporary memoryview with automatic decref of info.obj: If 'info' is allocated on the stack, then the memoryview shouldn't be returned from a function. If 'info' is allocated on the heap, then who frees 'info' when the memoryview is deallocated? Permanent memoryviews can now be safely created with PyMemoryView_FromMemory(). PyMemoryView_FromBuffer() isn't really that useful any more. It's hard to document all this in a few lines. Perhaps you can open an issue for this? Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problem with _PyTrash_destroy_chain ?
Hi,
I am currently hitting http://bugs.python.org/issue13992.
I have a scenario that reproduces the bug after 1 to 2 hours (intensive
sqlalchemy and threading). I get the same stack trace as described in the
bug.
After spending quite a bit of time trying to understand what could go wrong
in the C extensions I use, and not finding anything interesting, I decided
to try to find the problem with gdb. The stacktrace I have seems to mean
that we are trying to double free something in the frame_dealloc method.
See
(gdb) bt
#0 0x0046479f in _Py_ForgetReference (op=0x4dc7bc0) at
Objects/object.c:
#1 0x00464810 in _Py_Dealloc (op=0x4dc7bc0) at
Objects/object.c:2242
#2 0x00559a68 in frame_dealloc (f=0x4997ab0) at
Objects/frameobject.c:458
#3 0x0046481d in _Py_Dealloc (op=0x4997ab0) at
Objects/object.c:2243
and info in the bug report. Since the frame dealloc method is bracketed
with Py_TRASHCAN_SAFE_{BEGIN|END} macros, and they deal with memory
management, I had a closer look at those.
I compiled cpython without this trashcan management (replaced the macros by
two noops) and reran my scenario and it seems it is not segfaulting anymore.
I then had a closer look at the PyTrash_destroy_chain method (in object.c).
Here is what I think it does :
for each PyObject in the _PyTrash_delete_later linked list do :
set delete_nesting to 1 (it was 0 when the method was called) so that we
don't call destroy_chain again.
call deallocator for the object
set delete_nesting back to 1.
The thing is that this deallocator (from what I understood) is also
bracketed with Py_TRASHCAN macros. It could potentially cause a long
deallocation chain, that will be added to the _PyTrash_delete_later linked
list (if it's bigger than the PyTrash_UNWIND_LEVEL). If that happens, it
seems that the _PyTrash_delete_later list is going to contain twice the
same object, which could in turn cause the double free ?
Note that I am really not sure about this. What I am now almost sure about
is that my segfault goes away if I bypass the trashcan mechanism.
I am currently trying to set the unwind level to something like 5 and get a
quicker way to reproduce the bug, but I didn't manage to yet. I am
definitely available for help if needed.
Thanks,
Manu
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with _PyTrash_destroy_chain ?
Hello, On Thu, 30 Aug 2012 14:39:41 +0200 Manu wrote: > Hi, > > I am currently hitting http://bugs.python.org/issue13992. > > I have a scenario that reproduces the bug after 1 to 2 hours (intensive > sqlalchemy and threading). I get the same stack trace as described in the > bug. > [...] > > The thing is that this deallocator (from what I understood) is also > bracketed with Py_TRASHCAN macros. It could potentially cause a long > deallocation chain, that will be added to the _PyTrash_delete_later linked > list (if it's bigger than the PyTrash_UNWIND_LEVEL). If that happens, it > seems that the _PyTrash_delete_later list is going to contain twice the > same object, which could in turn cause the double free ? I don't see how that can happen. The following piece of logic in _PyTrash_destroy_chain(): PyObject *op = _PyTrash_delete_later; destructor dealloc = Py_TYPE(op)->tp_dealloc; _PyTrash_delete_later = (PyObject*) _Py_AS_GC(op)->gc.gc_prev; ensures that the object is moved out of the list before it is potentially re-added to it. However, there's a potential pitfall producing double dealloc's described in subtype_dealloc() in typeobject.c, under the following comment: Q. Why the bizarre (net-zero) manipulation of _PyTrash_delete_nesting around the trashcan macros? (I'm not copying the answer since it's quite long-winded, you can find it here: http://hg.python.org/cpython/file/2dde5a7439fd/Objects/typeobject.c#l1066 ) The bottom line is that subtype_dealloc() mutates _PyTrash_delete_nesting to avoid being called a second time, but it seems to miss the fact that another thread can run in-between and also mutate _PyTrash_delete_nesting in the other direction. The GIL protects us as long as it is not released, but it can be released inside the functions called by a non-trivial deallocator such as subtype_dealloc(). This is only a hypothesis, but we see that this traceback involves subtype_dealloc() and deallocators running from multiple threads: http://bugs.python.org/file26717/thread_all_apply_bt.txt Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with _PyTrash_destroy_chain ?
Am 30.08.12 14:39, schrieb Manu:
After spending quite a bit of time trying to understand what could go
wrong in the C extensions I use, and not finding anything interesting, I
decided to try to find the problem with gdb. The stacktrace I have seems
to mean that we are trying to double free something in the frame_dealloc
method. See
(gdb) bt
#0 0x0046479f in _Py_ForgetReference (op=0x4dc7bc0) at
Objects/object.c:
#1 0x00464810 in _Py_Dealloc (op=0x4dc7bc0) at
Objects/object.c:2242
#2 0x00559a68 in frame_dealloc (f=0x4997ab0) at
Objects/frameobject.c:458
#3 0x0046481d in _Py_Dealloc (op=0x4997ab0) at
Objects/object.c:2243
Why do you think that this stacktrace "seems to mean that we are trying
to double free something"? I can't infer that from the stacktrace.
You seem to suggest that the crash happens on object.c:. If so,
it's indeed likely a double-free; my suspicion is that the object memory
shows the regular "deallocated block" memory pattern (display *op at
the point of crash).
It would then be interesting to find out what object used to be there.
Unfortunately, there is no easy way to find out (unless the crash
always involves 0x4dc7bc0). So I suggest the following tracing:
- in _Py_NewReference, printf("allocate %p\n", op);
- in _Py_ForgetReference,
printf("free %p %s\n", op, op->ob_type->tp_name);
fflush(stdout);
This may get large, so you may open a file (e.g. in /tmp/fixedname)
to collect the trace. When it crashes, find the last prior free
of the address - there shouldn't be any subsequent alloc.
If the type doesn't give a clue, but it's always the same type,
you can restrict tracing to that type, and then print values
of the object for further diagnosis.
Other useful debug information would be to find out what specific
frame object is being deallocated - this can still be diagnosed
at the point of crash (try _PyObject_Dump(f->f_code)), and then
which specific variable (not sure what exact Python version you
are using - it seems it's in localsplus, so it likely is a local
variable of that frame).
HTH,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] hg.python.org should default to defaut, not 2.7
If one goes to http://hg.python.org/cpython/ and clicks 'browse', it defaults to 2.7, not to default (now 3.3). Moreover, there is no indication that it is defaulting to an old branch rather than current default, as one might reasonably expect. I found this very confusing when I was trying to get a link for a python-list post and the code did not look right. When one clicks 'branches', default is listed under 2.7, instead of on top, where it should be. I hope someone can fix both these issues. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg.python.org should default to defaut, not 2.7
In article , Terry Reedy wrote: > If one goes to http://hg.python.org/cpython/ and clicks 'browse', it > defaults to 2.7, not to default (now 3.3). Moreover, there is no > indication that it is defaulting to an old branch rather than current > default, as one might reasonably expect. I found this very confusing > when I was trying to get a link for a python-list post and the code did > not look right. It defaults to "tip" which is the most recently pushed change set. At the moment, it just so happens that tip is a 2.7 change set. Usually a change set for "default" will be the most recent but not always. You just need to check the branch list. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with _PyTrash_destroy_chain ?
On Thu, Aug 30, 2012 at 8:49 PM, "Martin v. Löwis" wrote:
> Am 30.08.12 14:39, schrieb Manu:
>
> After spending quite a bit of time trying to understand what could go
>> wrong in the C extensions I use, and not finding anything interesting, I
>> decided to try to find the problem with gdb. The stacktrace I have seems
>> to mean that we are trying to double free something in the frame_dealloc
>> method. See
>>
>> (gdb) bt
>> #0 0x0046479f in _Py_ForgetReference (op=0x4dc7bc0) at
>> Objects/object.c:
>> #1 0x00464810 in _Py_Dealloc (op=0x4dc7bc0) at
>> Objects/object.c:2242
>> #2 0x00559a68 in frame_dealloc (f=0x4997ab0) at
>> Objects/frameobject.c:458
>> #3 0x0046481d in _Py_Dealloc (op=0x4997ab0) at
>> Objects/object.c:2243
>>
>
> Why do you think that this stacktrace "seems to mean that we are trying
> to double free something"? I can't infer that from the stacktrace.
>
That's right, sorry. The reason why I think this is a double free is that
the op seems to point to an object that has been deallocated by python.
(gdb) select-frame 0
(gdb) print *op
$6 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x2364020}
>
> You seem to suggest that the crash happens on object.c:. If so,
> it's indeed likely a double-free; my suspicion is that the object memory
> shows the regular "deallocated block" memory pattern (display *op at
> the point of crash).
>
> It would then be interesting to find out what object used to be there.
> Unfortunately, there is no easy way to find out (unless the crash
> always involves 0x4dc7bc0).
Not sure why you know this address by heart ;) but the op pointer points
exactly there in the stacktrace I posted in the bug report. I'd bet it's
like this every time. What does it mean ?
(gdb) p op
$12 = (PyObject *) 0x4dc7bc0
I'll reproduce tomorrow and tell you if I get this again.
> So I suggest the following tracing:
>
> - in _Py_NewReference, printf("allocate %p\n", op);
> - in _Py_ForgetReference,
> printf("free %p %s\n", op, op->ob_type->tp_name);
> fflush(stdout);
>
> This may get large, so you may open a file (e.g. in /tmp/fixedname)
> to collect the trace. When it crashes, find the last prior free
> of the address - there shouldn't be any subsequent alloc.
>
> If the type doesn't give a clue, but it's always the same type,
> you can restrict tracing to that type, and then print values
> of the object for further diagnosis.
>
OK I'll do that.
It's always the same type. It's one of our mapped SqlAlchemy types. The
code I am using uses sqlalchemy heavily in a multithreaded environment, and
is using mostly instances of exactly this mapped type.
>
> Other useful debug information would be to find out what specific
> frame object is being deallocated - this can still be diagnosed
> at the point of crash (try _PyObject_Dump(f->f_code)), and then
> which specific variable (not sure what exact Python version you
> are using - it seems it's in localsplus, so it likely is a local
> variable of that frame).
>
I used the macro to get the python stacktrace. It always crashes on the
same line, in a sqlalchemy file. It looked innocuous to me, but I can post
it tomorrow when I get back to work.
>
> HTH,
> Martin
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg.python.org should default to defaut, not 2.7
Ned Deily wrote: In article , Terry Reedy wrote: If one goes to http://hg.python.org/cpython/ and clicks 'browse', it defaults to 2.7, not to default (now 3.3). Moreover, there is no indication that it is defaulting to an old branch rather than current default, as one might reasonably expect. I found this very confusing when I was trying to get a link for a python-list post and the code did not look right. It defaults to "tip" which is the most recently pushed change set. At the moment, it just so happens that tip is a 2.7 change set. Usually a change set for "default" will be the most recent but not always. You just need to check the branch list. So is it not possible to have the default stay at "default" instead of at "tip"? ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg.python.org should default to defaut, not 2.7
On Thu, 30 Aug 2012 13:34:56 -0700 Ethan Furman wrote: > Ned Deily wrote: > > In article , Terry Reedy > > wrote: > > > >> If one goes to http://hg.python.org/cpython/ and clicks 'browse', it > >> defaults to 2.7, not to default (now 3.3). Moreover, there is no > >> indication that it is defaulting to an old branch rather than current > >> default, as one might reasonably expect. I found this very confusing > >> when I was trying to get a link for a python-list post and the code did > >> not look right. > > > > It defaults to "tip" which is the most recently pushed change set. At > > the moment, it just so happens that tip is a 2.7 change set. Usually a > > change set for "default" will be the most recent but not always. You > > just need to check the branch list. > > So is it not possible to have the default stay at "default" instead of > at "tip"? http://bz.selenic.com/show_bug.cgi?id=2815 Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg.python.org should default to defaut, not 2.7
On Thu, Aug 30, 2012 at 12:57 PM, Terry Reedy wrote: > If one goes to http://hg.python.org/cpython/ and clicks 'browse', it > defaults to 2.7, not to default (now 3.3). Moreover, there is no indication > that it is defaulting to an old branch rather than current default, as one > might reasonably expect. I found this very confusing when I was trying to > get a link for a python-list post and the code did not look right. I reported both of these issues previously here: http://bugs.python.org/issue15491 For the second issue, I wound up filing this issue (noted in a comment on the above issue): http://bz.selenic.com/show_bug.cgi?id=3559 --Chris > When one clicks 'branches', default is listed under 2.7, instead of on top, > where it should be. > > I hope someone can fix both these issues. > > -- > Terry Jan Reedy > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/chris.jerdonek%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg.python.org should default to defaut, not 2.7
In article <[email protected]>, Antoine Pitrou wrote: > On Thu, 30 Aug 2012 13:34:56 -0700 > Ethan Furman wrote: > > Ned Deily wrote: > > > In article , Terry Reedy > > > > > > wrote: > > > > > >> If one goes to http://hg.python.org/cpython/ and clicks 'browse', it > > >> defaults to 2.7, not to default (now 3.3). Moreover, there is no > > >> indication that it is defaulting to an old branch rather than current > > >> default, as one might reasonably expect. I found this very confusing > > >> when I was trying to get a link for a python-list post and the code did > > >> not look right. > > > > > > It defaults to "tip" which is the most recently pushed change set. At > > > the moment, it just so happens that tip is a 2.7 change set. Usually a > > > change set for "default" will be the most recent but not always. You > > > just need to check the branch list. > > > > So is it not possible to have the default stay at "default" instead of > > at "tip"? > > http://bz.selenic.com/show_bug.cgi?id=2815 Yes, as Matt hints at, what most people really want is a filter for a particular branch. As it stands, you can always find the (default) head of a branch: http://hg.python.org/cpython/shortlog/default http://hg.python.org/cpython/shortlog/3.2 http://hg.python.org/cpython/shortlog/2.7 etc but note that as you follow the graph for a branch, merge change sets can take you into other branches depending on which parent you choose, and the change log shows all earlier change sets regardless of branch. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg.python.org should default to defaut, not 2.7
Antoine Pitrou wrote: On Thu, 30 Aug 2012 13:34:56 -0700 Ethan Furman wrote: Ned Deily wrote: Terry Reedy wrote: If one goes to http://hg.python.org/cpython/ and clicks 'browse', it defaults to 2.7, not to default (now 3.3). Moreover, there is no indication that it is defaulting to an old branch rather than current default, as one might reasonably expect. I found this very confusing when I was trying to get a link for a python-list post and the code did not look right. >>> It defaults to "tip" which is the most recently pushed change set. At the moment, it just so happens that tip is a 2.7 change set. Usually a change set for "default" will be the most recent but not always. You just need to check the branch list. >> So is it not possible to have the default stay at "default" instead of at "tip"? http://bz.selenic.com/show_bug.cgi?id=2815 Thanks, Antoine. For those with click-a-phobia (Steven? ;) the short answer is "No". Branches it is, then. ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg.python.org should default to defaut, not 2.7
Am 30.08.12 22:34, schrieb Ethan Furman: If one goes to http://hg.python.org/cpython/ and clicks 'browse', it defaults to 2.7, not to default (now 3.3). Moreover, there is no indication that it is defaulting to an old branch rather than current default, as one might reasonably expect. I found this very confusing when I was trying to get a link for a python-list post and the code did not look right. It defaults to "tip" which is the most recently pushed change set. At the moment, it just so happens that tip is a 2.7 change set. Usually a change set for "default" will be the most recent but not always. You just need to check the branch list. So is it not possible to have the default stay at "default" instead of at "tip"? It becomes challenging when you look at the other links: The bz2/zip/gz links: should they archive default or tip? [I guess you want them to archive default as well] The log link (which is actually the default page): should it log all changes including tip, or start at the head of default? [Do you really want it to suppress changes that are older than default's head?] The graph link: starting from default head, or tip? [same issue as log] The changeset link: tip or default? [I cannot guess what you would prefer. I personally think all changesets should be hyperlinked in the shortlog, and the shortlog shouldn't include a changeset navlink. This is probably intended, except that it breaks for changesets with tracker issue numbers in their description.] tags and branches are special cases - they always consider all of them (where "all tags" is "all .hgtags entries from all active (?) branches' heads"); help is also special. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with _PyTrash_destroy_chain ?
Am 30.08.12 22:22, schrieb Manu:
That's right, sorry. The reason why I think this is a double free is
that the op seems to point to an object that has been deallocated by python.
(gdb) select-frame 0
(gdb) print *op
$6 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x2364020}
Doesn't look like that to me. If it was deallocated, the debug malloc
would fill it with DEADBYTE (0xDB). So the memory has *not* been
deallocated (yet?). The object was just unlinked from the all-objects
list (or the pointers were overwritten with NULL by some buggy code
of yours).
If the object had properly been unlinked before, its refcount would have
been set to 0. In turn, the DECREF call that caused the second
deallocation would have complained "UNREF negative refcnt" just above
the line where it crashed.
So it's rather unlikely that an earlier ForgetReference had happened,
unless someone has INCREFed the object again in-between. This is
actually plausible: the trashcan defers deallocation, allowing for
a double drop-refcount-to-zero operation. Without the trashcan, the
object gets deallocated, the refcount overwritten with DEADBYTE, the
bogus INCREF and the second DECREF happen, the refcount isn't 0 then,
so there is no second deallocation.
Since there apparently is still a reference from a frame, the first
forgetreference was actually bogus; the object shouldn't have been
released yet. So you are missing an INCREF somewhere.
It would then be interesting to find out what object used to be there.
Unfortunately, there is no easy way to find out (unless the crash
always involves 0x4dc7bc0).
Not sure why you know this address by heart ;) but the op pointer points
exactly there in the stacktrace I posted in the bug report. I'd bet it's
like this every time. What does it mean ?
It means that it's a deterministic failure, which is a good thing from
a debugging point of view. You can set a watchpoint on the refcount,
and watch it go 0, then 1, then 0 again. If you are unfamiliar with
watchpoints, here is the rough guide:
1. Find the address of ob_refcnt, i.e. &op->ob_refcnt. I *think*
it should be (int*)0x4dc7bc8, but please double-check.
2. watch *(int*)0x4dc7bc8
3. run, continue, continue, ...
In this form, this typically doesn't work, since the address has
typically no memory associated initially. So you need to set
a break point on a function that is called closely before the
object gets allocated, and set the watchpoint only then.
Good luck,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] why is _PyBytes_Join not public but PyUnicode_Join is?
We have use for _PyBytes_Join in an extension module but technically it isn't a public Python C API... anyone know why? PyUnicode_Join is. Looking up the bytes 'join' method and using the C API to call that method object with proper parameters seems like overkill in the case where we're not dealing with user supplied byte strings at all. -gps ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why is _PyBytes_Join not public but PyUnicode_Join is?
On 31/08/2012 02:43, Gregory P. Smith wrote: We have use for _PyBytes_Join in an extension module but technically it isn't a public Python C API... anyone know why? PyUnicode_Join is. Looking up the bytes 'join' method and using the C API to call that method object with proper parameters seems like overkill in the case where we're not dealing with user supplied byte strings at all. For what it's worth, I could also make use of it in the regex module. I use PyUnicode_Join when working with Unicode strings, but I could also use PyBytes_Join if it were available instead of having to look it up. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
After this discussion it seemed wiser to submit my proposed 1.2 edits as Metadata 1.3, adding Provides-Extra, Setup-Requires-Dist, and Extension (with no defined registration procedure). This version is sure to be exciting as it also specifies that the values are UTF-8 with tolerant decoding and re-defines environment markers in terms of the ast module (is there a better way to specify a subset of Python?). The proposed Metadata 1.3 is at https://bitbucket.org/dholth/python-peps/changeset/8fa1de7478e95b5ef3a18c3272f740d8f3e2fb80 Thanks, Daniel Holth ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
