[Python-Dev] First attempt at Python 3.4.0rc3 is up
It's published here: http://hg.python.org/releasing/3.4/ There's also a tarball at the old web site: http://midwinter.com/~larry/3.4.status/ However, the "merge.status.html" page is broken. I'm not going to bother to fix it, instead please just look at the hg repo above. I think part of the problem is that some revisions I had to manually patch in (instead of grafting) wound up with my name instead of the original core dev's name, so the translation between the 3.4 and default branches got broken. Anyway, it locally builds and runs tests without errors. //arry/ ___ 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] First attempt at Python 3.4.0rc3 is up
On 7 March 2014 21:00, Larry Hastings wrote: > > > It's published here: > > http://hg.python.org/releasing/3.4/ Thanks for that Larry - commits and NEWS for the pip bundling, pkgutil and inspect changes all look good to me :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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-07 6:25 GMT+01:00 Nick Coghlan : >> 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). My patch keeps the exception object, but it breaks links to the other exceptions (__cause__ and __context__) and to the traceback (__traceback__): https://bitbucket.org/haypo/misc/src/tip/python/suppress_locals.py Then I saw that http://bugs.python.org/issue17911 already has a patch for the traceback module, nice! And it's very close to what I wrote: http://bugs.python.org/review/17911/#ps8639 This patch stores the exception as string (traceback._format_value(exc)). I prefer to avoid any useless formatting, since the formatted exception is only needed in rare cases. Just drop the "exception summary/view" is the most common case. If you want to full original exception object, don't use the summary/view but handle the exception in the except block. I realized that "memory leaks" (reference cycles) is a common issue with traceback objects (in Python 2) and exception objects (in Python 3): Extracting tracebacks does too much work [open] http://bugs.python.org/issue17911 Local variables not freed when Exception raises in function called from cycle [wont fix] http://bugs.python.org/issue5641 asyncio.Future.set_exception() creates a reference cycle [invalid] http://bugs.python.org/issue20032 Do we need to call gc.collect() occasionally through the event loop? http://code.google.com/p/tulip/issues/detail?id=42 Traceback objects not properly garbage-collected [invalid] http://bugs.python.org/issue226254 Reference cycle in _TracebackLogger and bug in _TracebackLogger.__del__() http://code.google.com/p/tulip/issues/detail?id=155 Twisted fake Traceback object: http://twistedmatrix.com/trac/browser/trunk/twisted/python/failure.py#L89 frame.f_locals keeps references to things for too long [open since 2009], request from Twisted http://bugs.python.org/issue6116 http://twistedmatrix.com/trac/ticket/3853 assertRaises as a context manager keeps tracebacks and frames alive [open] http://bugs.python.org/issue9815 Expose called function on frame object http://bugs.python.org/issue12857 tracebacks eat up memory by holding references to locals and globals when they are not wanted [fixed by traceback.clear_frames()] http://bugs.python.org/issue1565525 Add a frame method to clear expensive details [fixed by frame.clear()] http://bugs.python.org/issue17934 Generator cleanup without tp_del [rejected] http://bugs.python.org/issue17807 Generator memory leak [duplicate] http://bugs.python.org/issue17468 asyncio: remove _TracebackLogger [fixed] http://bugs.python.org/issue19967 sys.exc_info() should not be stored on a local variable [fixed] https://code.djangoproject.com/ticket/10758 Capturing the Currently Raised Exception http://docs.python.org/3/howto/pyporting.html#capturing-the-currently-raised-exception In Python 3, the traceback is attached to the exception instance through the __traceback__ attribute. If the instance is saved in a local variable that persists outside of the except block, the traceback will create a reference cycle with the current frame and its dictionary of local variables. This will delay reclaiming dead resources until the next cyclic garbage collection pass. In Python 2, this problem only occurs if you save the traceback itself (e.g. the third element of the tuple returned by sys.exc_info()) in a variable. => http://hewgill.com/journal/entries/541-python-2-to-3-upgrade-and-exception-handling [Python-Dev] new unbounded memory leak in exception handling? https://mail.python.org/pipermail/python-dev/2009-November/094304.html PEP 3134: Exception Chaining and Embedded Tracebacks [final] http://legacy.python.org/dev/peps/pep-3134/ PEP 344: Exception Chaining and Embedded Tracebacks [superseded] http://legacy.python.org/dev/peps/pep-0344/ 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] First attempt at Python 3.4.0rc3 is up
On 03/07/2014 03:14 AM, Nick Coghlan wrote: On 7 March 2014 21:00, Larry Hastings wrote: It's published here: http://hg.python.org/releasing/3.4/ Thanks for that Larry - commits and NEWS for the pip bundling, pkgutil and inspect changes all look good to me :) It's been an anxious process. I have some ideas for 3.5 that I think will be popular and make the process easier. But that's a discussion for another time, //arry/ ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2014-02-28 - 2014-03-07) 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: open4593 (+11) closed 28044 (+45) total 32637 (+56) Open issues with patches: 2084 Issues opened (33) == #13936: RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True http://bugs.python.org/issue13936 reopened by ncoghlan #19494: urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthH http://bugs.python.org/issue19494 reopened by r.david.murray #20014: Makes array.array constructor accepts ascii-unicode typecode http://bugs.python.org/issue20014 reopened by serhiy.storchaka #20015: Allow 1-character ASCII unicode where 1-character str is requi http://bugs.python.org/issue20015 reopened by serhiy.storchaka #20811: str.format for fixed width float can return a string longer th http://bugs.python.org/issue20811 opened by aubmoon #20812: Explicitly cover application migration in the 2->3 guide http://bugs.python.org/issue20812 opened by ncoghlan #20813: Backport revised 2to3 guide to older branches http://bugs.python.org/issue20813 opened by ncoghlan #20815: ipaddress unit tests PEP8 http://bugs.python.org/issue20815 opened by exhuma #20816: inspect.getcallargs() attempts to iterate over None http://bugs.python.org/issue20816 opened by jlowin #20817: inspect.getcallargs() raises the wrong error if 3+ arguments a http://bugs.python.org/issue20817 opened by jlowin #20819: reinitialize_command doesn't clear install_lib on install and http://bugs.python.org/issue20819 opened by jason.coombs #20823: Clarify copyreg.pickle() documentation http://bugs.python.org/issue20823 opened by peter.otten #20825: containment test for "ip_network in ip_network" http://bugs.python.org/issue20825 opened by exhuma #20826: Faster implementation to collapse consecutive ip-networks http://bugs.python.org/issue20826 opened by exhuma #20827: IDLE : Display function argument list in ClassBrowser http://bugs.python.org/issue20827 opened by sahutd #20833: scripts\pydocgui.pyw out of date http://bugs.python.org/issue20833 opened by loewis #20836: Pickle Nonetype http://bugs.python.org/issue20836 opened by Hans.Polak #20837: Ambiguity words in base64 documentation http://bugs.python.org/issue20837 opened by naoki #20840: AttributeError: 'module' object has no attribute 'ArgumentPars http://bugs.python.org/issue20840 opened by bsduni #20842: pkgutil docs should reference glossary terms not PEP 302 http://bugs.python.org/issue20842 opened by ncoghlan #20844: coding bug remains in 3.3.5rc2 http://bugs.python.org/issue20844 opened by miwa #20847: asyncio docs should call out that network logging is a no-no http://bugs.python.org/issue20847 opened by gvanrossum #20849: add exist_ok to shutil.copytree http://bugs.python.org/issue20849 opened by thehesiod #20851: Update devguide to cover testing from a tarball http://bugs.python.org/issue20851 opened by brett.cannon #20853: pdb "args" crashes when an arg is not printable http://bugs.python.org/issue20853 opened by jneb #20854: multiprocessing.managers.Server: problem with returning proxy http://bugs.python.org/issue20854 opened by allista #20857: ipaddress "is_private" and "is_global" are insufficiently docu http://bugs.python.org/issue20857 opened by r.david.murray #20858: Enhancements/fixes to pure-python datetime module http://bugs.python.org/issue20858 opened by bdkearns #20859: Context of documentation for conditional expressions http://bugs.python.org/issue20859 opened by terry.reedy #20860: ipaddress network subnets() method should return object with _ http://bugs.python.org/issue20860 opened by Warren.Turkal #20861: datetime argument handling inconsistent; should accept logical http://bugs.python.org/issue20861 opened by josh.rosenberg #20863: IDLE not opening http://bugs.python.org/issue20863 opened by chester.burns #20864: getattr does not work well with descriptor http://bugs.python.org/issue20864 opened by Martin.Thurau Most recent 15 issues with no replies (15) == #20864: getattr does not work well with descriptor http://bugs.python.org/issue20864 #20859: Context of documentation for conditional expressions http://bugs.python.org/issue20859 #20854: multiprocessing.managers.Server: problem with returning proxy http://bugs.python.org/issue20854 #20851: Update devguide to cover testing from a tarball http://bugs.python.org/issue20851 #20842: pkgutil docs should reference glossary terms not PEP 302 http://bugs.python.org/issue20842 #20833: scripts\pydocgui.pyw out of date http://bugs.python.org/issue20833 #20827: IDLE : Display function argument list in ClassBrowser http://bugs.python.org/issue20827 #20826: Faster implementation to collapse consecutive ip-networks http://bugs.python.org/issue20826 #20823: Clari
Re: [Python-Dev] Alternative forms [was: PEP 463: Exception-catching expressions]
(Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded:
> On Fri, Mar 7, 2014 at 7:29 AM, Jim J. Jewett wrote:
>> [ note that "x if y" already occurs in multiple contexts, and
>> always evaluates y before x. ]
> Yes, but that's still out of order.
Yeah, but local consistency is more important than global guidelines. :D
>> ... *re*-using out-of-order-"if" shouldn't add any additional costs.
> 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.
True -- and I'm not a parser expert. But my belief is that the
current parser allows lookahead for exactly one token, and that
the "else" would fit within that limit.
> ... humans reading the code have to assume style guides mightn't
> be followed.
True ... but I hope any non-trivial use of this (including use
with a non-trivial ternary if) will look bad enough to serve as
its own warning.
>> 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 is boolean; as always True]
I phrased that badly. I agree that without parentheses for
good spacing, the above is at least ambiguous -- that is what
you get for stringing multiple clauses together without
internal grouping.
I do think parentheses help, (but are less important when there
is only a single "if") and I strongly prefer that they be internal
(which you fear looks too much like calling a function named except).
In that case, it is:
expr1 except (expr3 if expr2)
and the extension to multiple except clauses would be:
expr1 except (expr3 if expr2,
expr5 if expr4)
though as I discuss later, placing parentheses there also makes a
colon or arrow more tolerable. It does this because the nearby
parens make it look more like the existing (non-lambda) uses of
inline-colon to associate the two things on either side. (Without
nearby brackets, the scope of the colon or arrow is more easily
taken to be the whole line.)
expr1 except (expr2: expr3,
expr4: expr5)
expr1 except (expr2 -> expr3,
expr4 -> expr5)
>> 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.
Agreed ... the "say it like you would in English" applies only
to the "expr if expr" form (proposed here and) used by comprehensions:
[1/x for x in data
if x]
>>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
I know that they don't always introduce suites.
I can't speak to the lambda precedent, but I do know that I personally
often stumble when trying to parse it, so I don't consider it a good model.
The other three inline uses (dict display, slide notation, and
function parameter annotation) are effectively conjunction operators,
saying that expr1 and expr2 are bound more tightly than you would
assume if they were separated by commas. They only occur inside
a fairly close bracket (of some sort), and if the bracket isn't
*very* close, then there are usually multiple associates-colons
inside the same bracket.
data[3:5]
data[-1:-3:-1]
def myfunc(a:int=5,
b:str="Jim",
c:float=3.14)
{'b': 2, 'c': 3, 'a': 1}
With parentheses after the except, the except expression will match
this pattern too -- particularly if there are multiple types of
exception treated differently.
expr1 except (expr2: expr3)
Without (preferably internal) parentheses, it will instead look like
a long line with a colon near the end, and a short continuation suite
that got moved up a line because it was only one statement long.
def nullfunc(self, a
[Python-Dev] Relaxáló masszázs otthon.
Tudja meg,hogyan részesülhetnek az otthoni masszázsnak,20%-kal olcsóbb árban mint a masszázs szalonokban. -> Kattintson ide <-- ___ 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 Sat, Mar 8, 2014 at 5:58 AM, Jim J. Jewett wrote: > > (Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded: > >> On Fri, Mar 7, 2014 at 7:29 AM, Jim J. Jewett >> wrote: > >>> [ note that "x if y" already occurs in multiple contexts, and >>> always evaluates y before x. ] > >> Yes, but that's still out of order. > > Yeah, but local consistency is more important than global guidelines. :D I don't see except expressions as fundamentally more associated with if/else than with, say, an or chain, which works left to right. Aside from both being ternary operators, of course, which isn't really much of a justification. >> 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. > > True -- and I'm not a parser expert. But my belief is that the > current parser allows lookahead for exactly one token, and that > the "else" would fit within that limit. > >> ... humans reading the code have to assume style guides mightn't >> be followed. > > True ... but I hope any non-trivial use of this (including use > with a non-trivial ternary if) will look bad enough to serve as > its own warning. Not sure whether the parser would be able to handle it or not, but the human would have to if the machine can, and that's going to be a source of confusion. I'd rather avoid it if I can. Remember, everywhere else in Python, the word "if" is followed by something that's interpreted as a boolean. You wouldn't expect to see this somewhere: if None: do_stuff() do_stuff() if sys else do_other_stuff() So it'd cause a mental glitch to see some other constant and always-true expression there: ... if ZeroDivisionError ... You don't expect ZeroDivisionError ever to be false. Seeing it following an if would leave you wondering if maybe it is. IMO that syntax is abuse of the 'if' keyword, hammering it into a hole it's not designed to fit into. > I do think parentheses help, (but are less important when there > is only a single "if") Analysis of the Python standard library suggests that the single-if situation is *by far* the most common, to the extent that it'd hardly impact the stdlib at all to add multiple except clauses to the proposal. Do you have a strong use-case for the more full syntax? It tends to get long, which rather damages the readability. A number of people have said that if the except expression goes over a line break, it should probably be a statement instead. I'm not sure that extreme is fully justified, but it certainly does have merit. In a codebase of mine I wouldn't *forbid* breaking an except expression over multiple lines, but it'd certainly be a reason to consider whether it's really necessary or not. > and I strongly prefer that they [the parentheses] be internal > (which you fear looks too much like calling a function named except). > In that case, it is: > > expr1 except (expr3 if expr2) I'm still not really seeing how this is better. With the colon version, it looks very much like dict display, only with different brackets around it; in some fonts, that'll be very easily confused. With the if, it looks like an incomplete expression waiting for its else. And I'm still not enamored of constructing syntax that has the evaluation order (a) not simple left-to-right, like most expressions are, and (b) different from the except statement, which puts the exception_list ahead of the suite. > Agreed ... the "say it like you would in English" applies only > to the "expr if expr" form (proposed here and) used by comprehensions: > > [1/x for x in data > if x] Sure. That usage makes a _lot_ of sense, I really like list comprehensions. There's no room in them for an 'else' clause though, so it's very strictly one-way. Makes them a tricky comparison for this. > I can't speak to the lambda precedent, but I do know that I personally > often stumble when trying to parse it, so I don't consider it a good model. The only confusion I have with lambda is its precedence, which trips me up now and then: >>> def f(x): ... return lambda y: x,y ... >>> f(5) Traceback (most recent call last): File "", line 1, in File "", line 2, in f NameError: name 'y' is not defined That's not returning a function that returns a tuple. It's returning a tuple of a function and the global y, and the function will ignore its arg. > The other three inline uses (dict display, slide notation, and > function parameter annotation) are effectively conjunction operators, > saying that expr1 and expr2 are bound more tightly than you would > assume if they were separated by commas. They only occur inside > a fairly close bracket (of some sort), and if the bracket isn't > *very* close, then there are usually multiple associates-colons > inside the same bracket. Not sure that really helps. This isn't going to be as tight as a
[Python-Dev] undocumented help() function change in Python 3.4?
Hi. I just noticed that the way help() function displays a function signature changed between Python 3.3 & 3.4 but I can not find this documented anywhere. Here's a matching example in both Python 3.3 & Python 3.4 for comparison: Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:19:30) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. def f(a, b, c): ... print(a, b, c) ... def g(*args, **kwargs): ... f(*args, **kwargs) ... import inspect print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (*args, **kwargs) g.__wrapped__ = f print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (a, b, c) help(f) Help on function f in module __main__: f(a, b, c) help(g) Help on function g in module __main__: g(*args, **kwargs) Python 3.4.0b3 (v3.4.0b3:a97ce3ecc96a, Jan 26 2014, 17:50:55) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. def f(a, b, c): ... print(a, b, c) ... def g(*args, **kwargs): ... f(*args, **kwargs) ... import inspect print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (*args, **kwargs) g.__wrapped__ = f print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (a, b, c) help(f) Help on function f in module __main__: f(a, b, c) help(g) Help on function g in module __main__: g(a, b, c) As you can see by comparing those two outputs, setting the __wrapped__ attribute on a wrapper function affects the inspect.signature() results on that function. This behaviour is the same in both Python 3.3. & 3.4 and is (somewhat) described in the Python documentation. However, help() output is not affected by this in Python 3.3, but is affected in Python 3.4, and I can not find anything regarding this in the Python 3.4 docs. Can something related to this be added at least to the 'what's changed' docs, if not to the help() documentation as well? Best regards, Jurko Gospodentić ___ 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] First attempt at Python 3.4.0rc3 is up
In article <[email protected]>, Larry Hastings wrote: > It's published here: > > http://hg.python.org/releasing/3.4/ Note, to get the current state of what will be in "3.4.0.rc3", you need to use the "3.4" branch and not "default". hg pull http://hg.python.org/releasing/3.4/ hg update 3.4 -- Ned Deily, [email protected] ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On Wed Mar 5 17:37:12 CET 2014, Victor Stinner wrote: > Python 3 now stores the traceback object in Exception.__traceback__ > and exceptions can be chained through Exception.__context__. It's > convenient but it introduced tricky reference cycles if the exception > object is used out of the except block. > ... see Future.set_exception() of the ayncio module. > ... frame.clear() raises an RuntimeError if the frame is still > running. And it doesn't break all reference cycles. > An obvious workaround is to store the traceback as text, but this > operation is "expensive" especially if the traceback is only needed in > rare cases. > I tried to write "views" of the traceback (and frames), but > Exception.__traceback__ rejects types other than traceback and > traceback instances cannot be created. It's possible to store the > traceback somewhere else and set Exception.__traceback__ to None, but > there is still the problem with chained exceptions. > Any idea for a generic fix to such problem? Could you clarify what the problem actually is? I can imagine any of the following: (A) Exceptions take a lot of memory, because of all the related details. + But sometimes the details are needed, so there is no good solution. (B) Exceptions take a lot of memory, because of all the related details. There is a common use case that knows it will never need certain types of details, and releasing just those details would save a lot of memory. But frame.clear() picks the wrong details to release, at least for this case. + So write another function (or even a method) that does work, and have your framework call it. (Also see (F)) + Instead of saving the original exception, could you instead create and store a new (copied?) one, which obviously won't (yet) be referenced by the traceback you assign to it? (C) Exceptions take a lot of memory, because of all the related details. There is a common use case that knows it can make do with a summary of certain types of details, and releasing just those details would save a lot of memory. But generating the summary is expensive. + It would help to have the summarize method available. + It would help to have feedback from gc saying when there is enough memory pressure to make this call worthwhile. (D) Exceptions are not released until cyclic gc, and so they eat a lot of memory for a long time prior to that. + This may be like case B + Are there references that can be replaced by weak references? + Are there references that you can replace with weak references when your framework stores the exception? (Also see (F)) (E) Exceptions are not released even during cyclic gc, because of ambiguity over which __del__ to run first. + This may be like case B or case E + This may be a concrete use case for the __close__ protocol. __close__ is similar to __del__, except that it promises not to care about order of finalization, and it is run eagerly. As soon as an instance is known to be in a garbage cycle, __close__ should be run without worrying about whether other objects also have __close__ or __del__ methods. Hopefully, this will break the cycle, or at least reduce the number of objects with __del__ methods. (Whether to require that __close__ be idempotent, or to guarantee that it is run only once/instance -- that would be part of the bikeshedding.) (F) You know what to delete (or turn into weakrefs), but can't actually do it without changing a type. (F1) Why does Exception.__traceback__ reject other objects which are neither tracebacks nor None? + Can that restriction be relaxed? + Can you create a mixin subtype of Exception, which relaxes the constraint, and gets used by your framework? + Can the restriction on creating tracebacks be relaxed? + Can traceback's restriction on frames' types be relaxed? (F2) Do you need the original Exception? (see (B)) (F3) Do you care about frame.clear() raising a runtime exception? Could you suppress it (or, better, get clear() to raise something more specific, and suppress that)? It would still have released what memory it reasonably could. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On 03/07/2014 01:20 PM, Jim J. Jewett wrote: (E) Exceptions are not released even during cyclic gc, because of ambiguity over which __del__ to run first. + This may be like case B or case E Um, this is case E. ;) -- ~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
[Python-Dev] Why not make frames? [was: Reference cycles in Exception.__traceback__]
On Thu Mar 6 16:52:56 CET 2014, Antoine Pitrou wrote: > 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. So? Does any of that matter until the frame is used to actually evaluate something? So what is the harm in creating a (likely partially invalid) frame for inspection purposes? For that matter, what is the point in tracebacks requiring frames, as opposed to any object, with the caveat that not having the expected attributes may cause grief -- as happens with any duck typing? -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On 3/7/2014 1:25 PM, Ethan Furman wrote: On 03/07/2014 01:20 PM, Jim J. Jewett wrote: (E) Exceptions are not released even during cyclic gc, because of ambiguity over which __del__ to run first. + This may be like case B or case E Um, this is case E. ;) Yeah, quite a bit like case E :) ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
> Could you clarify what the problem actually is? Please see: http://bugs.python.org/file33238/never_deleted.py 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] undocumented help() function change in Python 3.4?
On 3/7/2014 3:10 PM, Jurko Gospodnetić wrote: Hi. I just noticed that the way help() function displays a function signature changed between Python 3.3 & 3.4 but I can not find this documented anywhere. Here's a matching example in both Python 3.3 & Python 3.4 for comparison: Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:19:30) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. def f(a, b, c): ... print(a, b, c) ... def g(*args, **kwargs): ... f(*args, **kwargs) ... import inspect print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (*args, **kwargs) g.__wrapped__ = f print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (a, b, c) help(f) Help on function f in module __main__: f(a, b, c) help(g) Help on function g in module __main__: g(*args, **kwargs) Python 3.4.0b3 (v3.4.0b3:a97ce3ecc96a, Jan 26 2014, 17:50:55) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. def f(a, b, c): ... print(a, b, c) ... def g(*args, **kwargs): ... f(*args, **kwargs) ... import inspect print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (*args, **kwargs) g.__wrapped__ = f print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (a, b, c) help(f) Help on function f in module __main__: f(a, b, c) help(g) Help on function g in module __main__: g(a, b, c) As you can see by comparing those two outputs, setting the __wrapped__ attribute on a wrapper function affects the inspect.signature() results on that function. This behaviour is the same in both Python 3.3. & 3.4 and is (somewhat) described in the Python documentation. I suspect that is it intentional that the output of help is not exactly defined, just as exception messages are not. We consider either fair game to be changed in new versions. However, help() output is not affected by this in Python 3.3, That was a bug. but is affected in Python 3.4, and I can not find anything regarding this in the Python 3.4 docs. Assuming that pydoc (and hence help()) have not (yet?) been switched to using .signature directly, I suspect this is a side-effect of http://bugs.python.org/issue17481 inspect.getfullargspec should use __signature__ Can something related to this be added at least to the 'what's changed' docs, if not to the help() documentation as well? Perhaps add something to Other Language Changes -- * Signatures reported by help() have been modified and improved by Argument Clinic and changes to the inspect module. -- Terry Jan Reedy ___ 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] undocumented help() function change in Python 3.4?
On 8 March 2014 11:29, Terry Reedy wrote: > Perhaps add something to > > Other Language Changes > -- > * Signatures reported by help() have been modified and improved by Argument > Clinic and changes to the inspect module. Yeah, the changes to help() are doubly indirect - help() uses pydoc which uses inspect, and inspect saw a lot of changes. I'll make a few updates to the What's New to help make the consequences of this clearer. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] cpython (3.3): Make the various iterators' "setstate" sliently and consistently clip the
Am 06.03.2014 09:02, schrieb Serhiy Storchaka: > 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. Agreed. Kristjan, could you please explain a bit more about this change and use the tracker in the future? Georg ___ 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
