Re: [Python-Dev] cpython (3.3): Make the various iterators' "setstate" sliently and consistently clip the
05.03.14 17:24, kristjan.jonsson написав(ла): http://hg.python.org/cpython/rev/3b2c28061184 changeset: 89477:3b2c28061184 branch: 3.3 parent: 89475:24d4e52f4f87 user:Kristján Valur Jónsson date:Wed Mar 05 13:47:57 2014 + summary: Make the various iterators' "setstate" sliently and consistently clip the index. This avoids the possibility of setting an iterator to an invalid state. Why indexes are silently clipped instead of raising an exception? files: Lib/test/test_range.py| 12 ++ Modules/arraymodule.c | 2 + Objects/bytearrayobject.c | 10 ++-- Objects/bytesobject.c | 10 ++-- Objects/listobject.c | 2 + Objects/rangeobject.c | 31 +++--- Objects/tupleobject.c | 4 +- Objects/unicodeobject.c | 10 ++-- 8 files changed, 66 insertions(+), 15 deletions(-) And it would be better first discuss and review such large changes on the bugtracker. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
Le 05/03/2014 23:53, Nick Coghlan a écrit : __traceback__ wouldn't change [...] Uh, really? If you want to suppress all reference cycles, you *have* to remove __traceback__. The problem is to make computation of the traceback summary lightweight enough that it doesn't degrade performance in the common case where you don't have to print the traceback later. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
On 2014-03-06, 8:42 AM, Antoine Pitrou wrote: Le 05/03/2014 23:53, Nick Coghlan a écrit : __traceback__ wouldn't change [...] Uh, really? If you want to suppress all reference cycles, you *have* to remove __traceback__. The problem is to make computation of the traceback summary lightweight enough that it doesn't degrade performance in the common case where you don't have to print the traceback later. So why can't we allow instantiation of types.TracebackType & types.FrameType? It should be about the same time to reconstruct traceback and its frames without locals, as to create named tuples. Yury ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
2014-03-06 14:42 GMT+01:00 Antoine Pitrou : > Le 05/03/2014 23:53, Nick Coghlan a écrit : >> >> >> __traceback__ wouldn't change [...] > > > Uh, really? If you want to suppress all reference cycles, you *have* to > remove __traceback__. > > The problem is to make computation of the traceback summary lightweight > enough that it doesn't degrade performance in the common case where you > don't have to print the traceback later. By the way, here is my test script to try to create a lightweight traceback object without references to locals: https://bitbucket.org/haypo/misc/src/tip/python/suppress_locals.py It works if there is no chained exception. The problem is to build something working with the traceback module. I should maybe write my own formatting function reusing some traceback functions. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
Le 06/03/2014 16:03, Yury Selivanov a écrit : On 2014-03-06, 8:42 AM, Antoine Pitrou wrote: Le 05/03/2014 23:53, Nick Coghlan a écrit : __traceback__ wouldn't change [...] Uh, really? If you want to suppress all reference cycles, you *have* to remove __traceback__. The problem is to make computation of the traceback summary lightweight enough that it doesn't degrade performance in the common case where you don't have to print the traceback later. So why can't we allow instantiation of types.TracebackType & types.FrameType? IMO it is absolutely out of question to allow creation of arbitrary frames from Python code, because the structure and initialization of frames embody too many low-level implementation details. We might allow the creation of traceback objects, but without any custom frame objects it is unclear how useful that would be. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
On 2014-03-06, at 16:52 , Antoine Pitrou wrote: > Le 06/03/2014 16:03, Yury Selivanov a écrit : >> >> On 2014-03-06, 8:42 AM, Antoine Pitrou wrote: >>> Le 05/03/2014 23:53, Nick Coghlan a écrit : __traceback__ wouldn't change [...] >>> >>> Uh, really? If you want to suppress all reference cycles, you *have* >>> to remove __traceback__. >>> >>> The problem is to make computation of the traceback summary >>> lightweight enough that it doesn't degrade performance in the common >>> case where you don't have to print the traceback later. >> >> So why can't we allow instantiation of types.TracebackType & >> types.FrameType? > > IMO it is absolutely out of question to allow creation of arbitrary frames > from Python code, because the structure and initialization of frames embody > too many low-level implementation details. > > We might allow the creation of traceback objects, but without any custom > frame objects it is unclear how useful that would be. Some bits of the standard library (and probably third-party libraries transitively relying on getinnerframes) really, really want traceback objects and can't be used with a stack or frames extracted via inspect.currentframe() or whatever. For instance cgitb.text calls inspect.getinnerframes which accesses param.tb_frame then calls getframeinfo(param). getframeinfo blows up if it does not get either an actual traceback object or an actual frame object. A frame object does not have a tb_frame attribute, and will thus fail in getinnerframes, a fake traceback object will fail in getframeinfo. Therefore it's not possible to call cgitb.text outside of an exception handling context (that is, not possible to use it as a traceback.print_stack providing extra information). If it were possible to create traceback objects, there would be no issue there at least. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
But inspect is in the stdlib. Surely changing inspect.py is less controversial than amending the semantics of frame objects. On Thu, Mar 6, 2014 at 10:10 AM, Xavier Morel wrote: > On 2014-03-06, at 16:52 , Antoine Pitrou wrote: > > Le 06/03/2014 16:03, Yury Selivanov a écrit : > >> > >> On 2014-03-06, 8:42 AM, Antoine Pitrou wrote: > >>> Le 05/03/2014 23:53, Nick Coghlan a écrit : > > __traceback__ wouldn't change [...] > >>> > >>> Uh, really? If you want to suppress all reference cycles, you *have* > >>> to remove __traceback__. > >>> > >>> The problem is to make computation of the traceback summary > >>> lightweight enough that it doesn't degrade performance in the common > >>> case where you don't have to print the traceback later. > >> > >> So why can't we allow instantiation of types.TracebackType & > >> types.FrameType? > > > > IMO it is absolutely out of question to allow creation of arbitrary > frames from Python code, because the structure and initialization of frames > embody too many low-level implementation details. > > > > We might allow the creation of traceback objects, but without any custom > frame objects it is unclear how useful that would be. > > Some bits of the standard library (and probably third-party libraries > transitively relying on getinnerframes) really, really want traceback > objects and can't be used with a stack or frames extracted via > inspect.currentframe() or whatever. For instance cgitb.text calls > inspect.getinnerframes which accesses param.tb_frame then calls > getframeinfo(param). getframeinfo blows up if it does not get either an > actual traceback object or an actual frame object. > > A frame object does not have a tb_frame attribute, and will thus fail > in getinnerframes, a fake traceback object will fail in getframeinfo. > > Therefore it's not possible to call cgitb.text outside of an exception > handling context (that is, not possible to use it as a > traceback.print_stack providing extra information). If it were possible > to create traceback objects, there would be no issue there at least. > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 03/04/2014 06:46 PM, Larry Hastings wrote: On 03/04/2014 03:59 PM, Barry Warsaw wrote: I too would like an rc3, especially to see if issue 19021 can be fixed, which I suspect will hit a lot of people. I talked to the other guys on the 3.4 team, and we're all willing to do an rc3 this weekend. I'll add that to PEP 429. In other news, I'm thrilled to confirm something Antoine mentioned a week or two ago: it is literally impossible for garden-variety core devs to push new branches back into trunk. I tried to, early this morning (PST), with someone logged in to hg.python.org ready to clean up in case it actually worked. But happily hg hooks on the server reject new branches every time. Since this banishes my chief objection to publishing the repo where I do my cherry picking, I'll be publishing that repo this week. I think I still have a rebase ahead of me, so I'm going wait until after the latest (and hopefully last!) round of cherry-picking. I'll post to python-dev once the tree is public. Thanks, Larry! I know I have no idea how much work it takes to be an RM, but I appreciate you taking the time, learning the ropes, and getting this done for the rest of us. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
But having exceptions without '__traceback__' affects not only the inspect module, but also lots of other code. It will make harder to write generic error reporting code, as you'd need to check for __traceback__ first, and then, if it's None, look for some other, asyncio specific attribute. I think that having tracebacks with fake frames is much more backwards compatible and consistent solution. I don't understand why we should break the established protocol here. [Or we can allow instantiation of immutable frame objects without __code__] Yury On 2014-03-06, 1:32 PM, Guido van Rossum wrote: But inspect is in the stdlib. Surely changing inspect.py is less controversial than amending the semantics of frame objects. On Thu, Mar 6, 2014 at 10:10 AM, Xavier Morel wrote: On 2014-03-06, at 16:52 , Antoine Pitrou wrote: Le 06/03/2014 16:03, Yury Selivanov a écrit : On 2014-03-06, 8:42 AM, Antoine Pitrou wrote: Le 05/03/2014 23:53, Nick Coghlan a écrit : __traceback__ wouldn't change [...] Uh, really? If you want to suppress all reference cycles, you *have* to remove __traceback__. The problem is to make computation of the traceback summary lightweight enough that it doesn't degrade performance in the common case where you don't have to print the traceback later. So why can't we allow instantiation of types.TracebackType & types.FrameType? IMO it is absolutely out of question to allow creation of arbitrary frames from Python code, because the structure and initialization of frames embody too many low-level implementation details. We might allow the creation of traceback objects, but without any custom frame objects it is unclear how useful that would be. Some bits of the standard library (and probably third-party libraries transitively relying on getinnerframes) really, really want traceback objects and can't be used with a stack or frames extracted via inspect.currentframe() or whatever. For instance cgitb.text calls inspect.getinnerframes which accesses param.tb_frame then calls getframeinfo(param). getframeinfo blows up if it does not get either an actual traceback object or an actual frame object. A frame object does not have a tb_frame attribute, and will thus fail in getinnerframes, a fake traceback object will fail in getframeinfo. Therefore it's not possible to call cgitb.text outside of an exception handling context (that is, not possible to use it as a traceback.print_stack providing extra information). If it were possible to create traceback objects, there would be no issue there at least. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Alternative forms [was: PEP 463: Exception-catching expressions]
The PEP currently says: > Alternative Proposals > = > Discussion on python-ideas brought up the following syntax suggestions:: >value = expr except default if Exception [as e] This one was rejected because of the out-of-order evaluation. Note, however, that the (farthest left) expr is always evaluated first; the only out-of-order evaluation is "default if Exception". "default if Exception" is precisely the same evaluation order (clause after the "if" skips ahead of the clause before the "if") as in the existing if-expression, and the existing if-filters in comprehensions. The same justifications for that order violation generally apply here too. You can argue that they weren't sufficient justification in the first place, but that is water under the bridge; *re*-using out-of-order-"if" shouldn't add any additional costs. [Err... unless people take the "if" too literally, and treat the Exception clause as a boolean value, instead of as an argument to the "except" keyword.] The advantages of this form get much stronger with [as e] or multiple different except clauses, but some of them do apply to even the simplest form. Notably, the "say it like you would in English" that convinced Perl still applies: "if" *without* a "then" is normally an extra condition added after the main point: Normally ham, but fish if it's a Friday. (Admittedly, the word "then" *can* be elided (and represented by a slight pause), and python programmers are already used to seeing it represented only by ":\n") I also give a fair amount of weight to the fact that this form starts to look awkward at pretty much the same time the logic gets too complicated for an expression -- that should discourage abuse. [The analogies to if-expressions and if-filters and to spoken English, along with discouragement for abuse, make this my preferred form.] ... >value = expr except (Exception [as e]: default) (and the similar but unmentioned) value = expr except (Exception [as e] -> default) The mapping analogy for ":" is good -- and is the reason to place parentheses there, as opposed to around the whole expression. Your preferred form -- without the internal parentheses -- looks very much like a suite-introduction, and not at all like the uses where an inline colon is acceptable. I do understand your concern that the parentheses make "except (...)" look too much like a function call -- but I'm not sure that is all bad, let alone as bad as looking like a suite introduction. Both ":" and "->" are defined for signatures; the signature meaning of ":" is tolerable, and the signature meaning of "->" is good. ... >value = expr except Exception [as e] continue with default This one works for me, but only because I read "continue with" as a compound keyword. I assume the parser would too. :D But I do recognize that it is a poor choice for those who see the space as a more solid barrier. ... >value = expr except(Exception) default # Catches only the named type(s) This looks too much like the pre-"as" way of capturing an exception. >value = default if expr raise Exception (Without new keyword "raises",) I would have to work really hard not to read that as: __temp = default if expr: raise Exception value = __temp >value = expr or else default if Exception To me, this just seems like a wordier and more awkward version of expr except (default if Exception [as e]) including the implicit parentheses around "default if Exception". >value = expr except Exception [as e] -> default Without parens to group Exception and default, this looks too much like an annotation describing what the expr should return. value = expr except Exception [as e] pass default I would assume that this skipped the statement, like an if-filter in a comprehension. > All forms involving the 'as' capturing clause have been deferred from > this proposal in the interests of simplicity, but are preserved in the > table above as an accurate record of suggestions. Nick is right that you should specify whether it is deferred or rejected, because the simplest implementation may lock you into too broad a scope if it is added later. > The four forms most supported by this proposal are, in order:: >value = (expr except Exception: default) >value = (expr except Exception -> default) ... If there are not parentheses after "except", it will be very tempting (and arguably correct) to (at least mentally) insert them around the first two clauses -- which are evaluated first. But that leaks into value = (expr except Exception): default which strongly resembles the suite-starter ":", but has very little in common with the mapping ":" or the signature ":". value = (expr except Exception) -> default which looks like an annotation, rather than a part of the value-determination. -jJ -- If there are still threading problems with my replies, please email
Re: [Python-Dev] Reference cycles in Exception.__traceback__
On 2014-03-06, at 19:32 , Guido van Rossum wrote: > But inspect is in the stdlib. Surely changing inspect.py is less > controversial than amending the semantics of frame objects. I've no idea, I'm just giving a case where I could have used the ability to create traceback objects even without the ability to create stack frames (changing the stdlib may also be an option, though I'd hope the explicit type checks were put in there for a reason) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
It's all very old C code that's deeply intertwined with interpreter internals. Who knows what kind of assumptions are made by some of the C code consuming frames and tracebacks... On Thu, Mar 6, 2014 at 12:38 PM, Xavier Morel wrote: > On 2014-03-06, at 19:32 , Guido van Rossum wrote: > > But inspect is in the stdlib. Surely changing inspect.py is less > controversial than amending the semantics of frame objects. > > I've no idea, I'm just giving a case where I could have used the ability > to create traceback objects even without the ability to create stack > frames (changing the stdlib may also be an option, though I'd hope the > explicit type checks were put in there for a reason) > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
Antoine Pitrou wrote: We might allow the creation of traceback objects, but without any custom frame objects it is unclear how useful that would be. When I was implementing Pyrex, I would have found it very useful to be able to create Traceback objects without Frames, but only if the Traceback were able to hold a line number. As it was, I had to create an entire fake Frame object filled with mostly dummy values, just to get line numbers printed in the traceback. -- Greg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative forms [was: PEP 463: Exception-catching expressions]
On Fri, Mar 7, 2014 at 7:29 AM, Jim J. Jewett wrote: > > The PEP currently says: > >> Alternative Proposals >> = > >> Discussion on python-ideas brought up the following syntax suggestions:: > >>value = expr except default if Exception [as e] > > This one was rejected because of the out-of-order evaluation. > > Note, however, that the (farthest left) expr is always evaluated first; > the only out-of-order evaluation is "default if Exception". > > "default if Exception" is precisely the same evaluation order > (clause after the "if" skips ahead of the clause before the "if") > as in the existing if-expression, and the existing if-filters in > comprehensions. Yes, but that's still out of order. > The same justifications for that order violation generally apply here too. > You can argue that they weren't sufficient justification in the first > place, but that is water under the bridge; *re*-using out-of-order-"if" > shouldn't add any additional costs. > > [Err... unless people take the "if" too literally, and treat the > Exception clause as a boolean value, instead of as an argument to the > "except" keyword.] The other thing to note is that it's somewhat ambiguous. Until you find that there isn't an else clause, it could be the equally valid "expr except (default if cond else other_default)", with the actual "if Exception" part still to come. (Style guides should, of course, decry this as unreadable, but both the machine parser and any humans reading the code have to assume style guides mightn't be followed.) > The advantages of this form get much stronger with [as e] or multiple > different except clauses, but some of them do apply to even the simplest > form. Multiple different except clauses would make for an even messier evaluation order: expr1 except expr3 if expr2 except expr5 if expr4 If you consider the exception type to be the condition, then this makes sense (that is, if you read it as "if isinstance(thrown_exception, Exception)"); but the most obvious reading of "if", both in its statement form and as part of "true if expr else false", is that it is followed by something that's evaluated as boolean; and all exception types and tuples will be true in that context. > Notably, the "say it like you would in English" that convinced > Perl still applies: "if" *without* a "then" is normally an extra condition > added after the main point: > > Normally ham, but fish if it's a Friday. That's not how Python words ternary if, though. "Ham, if it's not Friday; otherwise fish" is closer, or inverting that: "Fish on Fridays, but normally ham". English is pretty flexible with how you lay things out :) >>value = expr except (Exception [as e]: default) > > (and the similar but unmentioned) > > value = expr except (Exception [as e] -> default) The parenthesizing question and the choice of tokens are considered independent, so not all the cross-multiplications are listed. > The mapping analogy for ":" is good -- and is the reason to place > parentheses there, as opposed to around the whole expression. Your > preferred form -- without the internal parentheses -- looks very > much like a suite-introduction, and not at all like the uses > where an inline colon is acceptable. I have some notes on that down the bottom: http://www.python.org/dev/peps/pep-0463/#colons-always-introduce-suites >>value = expr except Exception [as e] continue with default > > This one works for me, but only because I read "continue with" as a > compound keyword. I assume the parser would too. :D But I do > recognize that it is a poor choice for those who see the space as a > more solid barrier. That depends on all parsers (computer and human) being okay with the two-keyword unit. Would have to poll human parsers to see how they feel about it. >>value = expr except(Exception) default # Catches only the named type(s) > > This looks too much like the pre-"as" way of capturing an exception. Not sure what the connection is, but I don't like the style anyway: putting an expression immediately after a close parenthesis seems odd (I can't think of anything else in Python that has that). >>value = default if expr raise Exception > > (Without new keyword "raises",) I would have to work really hard not to > read that as: > > __temp = default > if expr: > raise Exception > value = __temp Yeah; on the flip side, "raises" doesn't add a huge amount of clarity, and it's creating a new keyword that's not identical, but so all-but - oh Saphir, is it not quite too "all-but"? >>value = expr or else default if Exception > > To me, this just seems like a wordier and more awkward version of > > expr except (default if Exception [as e]) > > including the implicit parentheses around "default if Exception". And mainly, it abuses three keywords that can all already exist in an expression, and doesn't use either "try" or "except". Suppose you saw that, and wanted to kno
Re: [Python-Dev] Reference cycles in Exception.__traceback__
Hi, 2014-03-06 16:19 GMT+01:00 Victor Stinner : > By the way, here is my test script to try to create a lightweight > traceback object without references to locals: > https://bitbucket.org/haypo/misc/src/tip/python/suppress_locals.py > > It works if there is no chained exception. I updated my proof-of-concept to support Exception.__context__, Exception.__cause__ and Exception.__suppress_context__: https://bitbucket.org/haypo/misc/src/tip/python/suppress_locals.py It creates a lightweight "view" of an exception only keeping information needed to format a traceback. > The problem is to build something working with the traceback module. I > should maybe write my own formatting function reusing some traceback > functions. I reused as much code as possible of the traceback module. I only reimplemented _iter_chain() and _format_exception_iter(). View classes could be simplified, but it would need to modify more code in the traceback module. What do you think of my approach? Would it be something useful in other applications? If yes, I can maybe work on a a better implementation, and maybe on a PEP, to see how such thing could be integrated in Python stdlib. It can maybe directly be part of the traceback module. I don't know if storing an exception to maybe format it later as a traceback is a common use case. Usually, exceptions are immediatly formatted or dropped, no? Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
On 6 Mar 2014 23:44, "Antoine Pitrou" wrote: > > Le 05/03/2014 23:53, Nick Coghlan a écrit : >> >> >> __traceback__ wouldn't change [...] > > > Uh, really? If you want to suppress all reference cycles, you *have* to remove __traceback__. > > The problem is to make computation of the traceback summary lightweight enough that it doesn't degrade performance in the common case where you don't have to print the traceback later. The proposed summary extraction only keeps the exception type and its str output, not the exception itself (as you don't need that to create the formatted traceback). Cheers, Nick. > > Regards > > Antoine. > > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
