Re: [Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Nick Coghlan wrote: > "Loop on this iterator and finalise when done" would be written: > >for item in itr: >process(item) >finally: >pass This is approaching things from the wrong end. The user of an iterator shouldn't need to know or care whether it requires finalization -- it should Just Work, whatever context it is used in. Greg ___ 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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Greg Ewing wrote: > Ron Adam wrote: > >>There seems to be some confusion as to weather or >>not 'for's will do finalizing. So I was trying to stress I think >>regular 'for' loops should not finalize. They should probably give an >>error if an object with an try-finally in them or an __exit__ method. > > > But if the for-loop can tell whether the iterator > needs finalizing or not, why not have it finalize > the ones that need it and not finalize the ones > that don't? That would be backwards compatible, > since old for-loops working on old iterators would > work as before. When I first started redrafting the PEP, I had essentially this idea in there - look for an __exit__() method, if it's there use the new 'finalising' semantics, if it isn't, use the old semantics. This bloats the generated byte code horribly, though - it is necessary to produce two complete copies of the for loop code, since we don't know at compile time which version (finalising or non-finalising) will be needed. It also takes away from the programmer the ability to choose to do partial iteration on generators that require finalisation. And it does so in a non-obvious way: "it works with this iterator, why doesn't it work with that one?" Accordingly, I switched to a version which puts control pack in the hands of the programmer. If you know the iterator doesn't need finalising, or if eventual finalisation on garbage collection is sufficient, then you can omit the finally clause, and get the optimised form of the for loop. Alternatively, if you want prompt finalisation (e.g. with an iterator like all_lines() from the PEP redraft), then you can include the finally clause and get the behaviour you want. Failure to finalise promptly on iterators that need it is still a bug - but then, so is failing to close a file handle or database connection. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.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
[Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Nick Coghlan wrote: > Josiah Carlson wrote: >> This has the benefit that an arbitrary block of code can be named, >> and a named TerminateBlock used to exit it. >> ... I suspect any such implementation is going to need to use >> exceptions for the guts of the flow control, even if that use isn't >> visible to the programmer. > Not necessarily. If I were implementing such a thing; any time > arbitrary break/continues (to a loop that isn't the deepest) were used > in nested loops, I would increment a counter any time a loop was entered, > and decrement the counter any time a loop was exited. ... When named blocks are used in Lisp, they often cross function boundaries. Given that, the number of intervening loops could change depending on external variables. Since you would have to pop frames anyhow, Exceptions are the right way to do it. If you limited the named-block gotos to within a single function/method, then the loop counter would work (and you could limit obfuscation). Unfortunately, you would lose most of the power of named blocks, while still paying the full ugliness price. You would also encourage people to inline things that ought to be separate functions. In case it isn't clear, I think named loops would be a mistake. I wanted them when I first started, but ... at the moment, I can't think of any usage that wasn't an ugly speed hack, which is at least more explicit with the "raise Found" idiom. -jJ ___ 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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Nick Coghlan wrote: > "Loop on this iterator and finalise when done" would be written: >for item in itr: >process(item) >finally: >pass Greg Ewing wrote: > This is approaching things from the wrong end. The user of > an iterator shouldn't need to know or care whether it > requires finalization -- it should Just Work, whatever > context it is used in. If you're saying "lists don't need it, but openfiles do", then I agree; it shouldn't matter what type of iterator you have. If you're talking specific object instances, then the user is the only one (outside of the Garbage Collection system) who has a chance of knowing whether the rest of the iterator will be needed later. When iterating over lines in a file, and breaking out at a sentinel, the compiler can't know whether you're done, or just leaving the "real" lines to another piece of code. Of course, that still raises the "Why are we encouraging bugs?" issue. If there are no remaining references, then garbage collection is the answer, and maybe we just need to make it more aggressive. If there are remaining references, then maybe the user is wrong about being done. -jJ ___ 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] New Py_UNICODE doc
Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >>Unicode has many code points that are meant only for composition >>and don't have any standalone meaning, e.g. a combining acute >>accent (U+0301), yet they are perfectly valid code points - >>regardless of UCS-2 or UCS-4. It is easily possible to break >>such a combining sequence using slicing, so the most >>often presented argument for using UCS-4 instead of UCS-2 >>(+ surrogates) is rather weak if seen by daylight. > > > I disagree. It is not just about slicing, it is also about > searching for a character (either through the "in" operator, > or through regular expressions). If you define an SRE character > class, such a character class cannot hold a non-BMP character > in UTF-16 mode, but it can in UCS-4 mode. Consequently, > implementing XML's lexical classes (such as Name, NCName, etc.) > is much easier in UCS-4 than it is in UCS-2. In this case, > combining characters do not matter much, because the XML > spec is defined in terms of Unicode coded characters, causing > combining characters to appear as separate entities for lexical > purposes (unlike half surrogates). Searching for a character is possible in UCS2 as well - even for surrogates with "in" now supporting multiple code point searches: >>> len(u'\U0001') 2 >>> u'\U0001' in u'\U00010001\U00010002\U0001 and some extra stuff' True >>> u'\U0001' in u'\U00010001\U00010002\U00010003 and some extra stuff' False On sre character classes: I don't think that these provide a good approach to XML lexical classes - custom functions or methods or maybe even a codec mapping the characters to their XML lexical class are much more efficient in practice. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 09 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] The decorator module
At 01:08 AM 5/9/2005 -0400, Michele Simionato wrote: >On 5/6/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > In this case, the informally-discussed proposal is to add a mutable > > __signature__ to functions, and have it be used by inspect.getargspec(), so > > that decorators can copy __signature__ from the decoratee to the decorated > > function. > >Is there in the plans any facility to copy functions? Currently I am doing > >def copyfunc(func): > "Creates an independent copy of a function." > c = func.func_code > nc = new.code(c.co_argcount, c.co_nlocals, c.co_stacksize, c.co_flags, > c.co_code, c.co_consts, c.co_names, c.co_varnames, > c.co_filename, c.co_name, c.co_firstlineno, > c.co_lnotab, c.co_freevars, c.co_cellvars) > return new.function(nc, func.func_globals, func.func_name, > func.func_defaults, func.func_closure) > >and I *hate* it! You don't need to copy the code object; functions can share the same code object just fine, and in fact for closures they do all the time. ___ 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] Python's Unicode width default (New Py_UNICODE doc)
[Python used to always default to UCS2-Unicode builds; this was changed to default to whatever a possibly installed TCL system is using - hiding the choice from the user and in effect removing the notion of having a Python Unicode default configuration] Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >>I believe that it would be more appropriate to adjust the _tkinter >>module to adapt to the TCL Unicode size rather than >>forcing the complete Python system to adapt to TCL - I don't >>really see the point in an optional extension module >>defining the default for the interpreter core. > > > _tkinter currently supports, for a UCS-2 Tcl, both UCS-2 and UCS-4 > Python. For an UCS-4 Tcl, it requires Python also to be UCS-4. > Contributions to support the missing case are welcome. I'm no expert for _tkinter and don't use it, so I'm the wrong one to ask :-) However, making Python's own default depend on some 3rd party software on the machines is bad design. >>At the very least, this should be a user controlled option. > > > It is: by passing --enable-unicode=ucs2, you can force Python > to use UCS-2 even if Tcl is UCS-4, with the result that > _tkinter cannot be built anymore (and compilation fails > with an #error). I think we should remove the defaulting to whatever TCL uses and instead warn the user about a possible problem in case TCL is found and uses a Unicode width which is incompatible with Python's choice. The user can then decide whether she finds _tkinter important enough to turn away from the standard Python default Unicode width or not (with all the consequences that go with it, e.g. memory bloat, problems installing binaries precompiled for standard Python builds, etc.). This should definitely *not* be done automatically. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 09 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Josiah Carlson wrote: > Ron Adam <[EMAIL PROTECTED]> wrote: > >> There's also the possibility to use conditional looping based on the value returned from the generator. >> >> do VAR from EXPR if VAR==CONST: >>BLOCK >> >> This is a bit verbose, but it reads well. :-) > > > > Reading well or not, this is not really an option for the same reasons > why... > > for VAR in EXPR1 if EXPR2: > or > for VAR in EXPR1 while EXPR2: > > are not options. Keep it simple. > Yes, so just "do [VAR from] EXPR1:" >>3. Do-loops: An generator based loop with finalization: This could be both single and multiple pass. The difference is determined by weather or not the generator used loops the yield statement or not. > > > Offering only generator-based finalization loops is, as I understand it, > not an option. It could also include class's with __exit__ methods which are really just more complex generators when used this way. But isn't this what PEP340 *already* proposes? Or am I missing a subtle distinction here. -Ron ___ 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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Greg Ewing wrote: > Ron Adam wrote: >> There seems to be some confusion as to weather or >> not 'for's will do finalizing. So I was trying to stress I think >> regular 'for' loops should not finalize. They should probably give an >> error if an object with an try-finally in them or an __exit__ method. > > But if the for-loop can tell whether the iterator > needs finalizing or not, why not have it finalize > the ones that need it and not finalize the ones > that don't? That would be backwards compatible, > since old for-loops working on old iterators would > work as before. That's why I suggested to have the behaviour depend on what is passed in as EXPR. for VAR in EXPR: BLOCK could be translated to: __cleanup = False __itr = EXPR if not isinstance(__itr,iterator): __itr = iter(__itr) __cleanup = True while True: try: VAR = __itr.next() except StopIteration: break BLOCK if __cleanup: __itr.__exit__() Which would require isinstance(__itr,iterator) or equivalent to act as a robust test on iterators. I'll leave 'for' with an 'else' clause as an exercise to the reader. --eric ___ 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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Greg Ewing wrote: > Ron Adam wrote: > >>There seems to be some confusion as to weather or >>not 'for's will do finalizing. So I was trying to stress I think >>regular 'for' loops should not finalize. They should probably give an >>error if an object with an try-finally in them or an __exit__ method. > > > But if the for-loop can tell whether the iterator > needs finalizing or not, why not have it finalize > the ones that need it and not finalize the ones > that don't? That would be backwards compatible, > since old for-loops working on old iterators would > work as before. > > Greg Ok, so if they check for it, they might as well handle it. Or maybe they shouldn't even check for performance reasons? Then no error, and it's up to the programmer to decide which looping construct to use. _Ron ___ 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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Josiah Carlson wrote: > I wasn't expressing my opinion, I was attempting to express as to where > the discussion went and concluded. I honestly can't remember having an > opinion on the subject, but I seem to have convinced Nick earlier that > they shouldn't loop, and he (re-)convinced me that indeed, they > shouldn't loop. So you can be re-re-convinced if more use cases are found? ;-) >>It needs some polish I think. ;-) > > > Goodness, the horror! When implementation details start bleeding their > way into actual language constructs (using a continue/break stack in > order to control the flow of nested loops), that's a good clue that an > idea has gone a bit too far. > > I would honestly prefer gotos, and I would prefer having no change to > existing syntax to gaining gotos. Well I happen to like stacks for somethings. They can be very useful and efficient. But I agree that they have been horrible abused in all sorts of ways. But that doesn't make them bad. In this case I think they work well, but the implementation ccould be improved. I see a correlation between breaks, continues, and exceptions. So it makes since to me that they could use similar mechanisms to catch and reraise them as needed. But this seems awkward and it's even *uglier*! try: # some code in a loop. except BreakException, Breakme: pass then later raise Breakme# breaks a loop now instead of then. But these examples sort of point out an underlying concept in these discussions. That it is useful to be able to postpone or delay code to be executed at a later time. Thus the idioms, before-after, enter-exit, and init-finalize. And here again, with try-finally, and breaks/continues. _Ron > It's kind of funny. Every month I spend in python-dev, I feel less > inclined to want to change the Python language (except for the relative > import I need to finish implementing). Not because it is a pain in the > tookus (though it is), but because many times it is my immediate sense > of aesthetics that causes me to desire change, and my future of code > maintenance makes me think forward to understanding Python 2.3 in the > context of Python 2.9 . Changing it just for the sake of newness or "it's cool" or whatever isn't good of course. But extending a language vs changing the way it works, is worth while as long as it's done in a careful and consistent manner. That's sort of why I'm against changing 'for', and for adding the new loop/block. I see it as a loop with a higher level of abstraction. A new tool to be used in new ways, but I want to keep my old dependable tools too. _Ron The simplest computer language in the world is called MAIN, has only one function called main(), which evaluates any arbitrary set of arguments you give it. Programming is now an obsolete profession! However we are now in desperate need of experts who can understand exceedingly long arbitrary sets of arguments and what they will do when they are evaluated by MAIN's main() function. ;-) ___ 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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Jim Jewett <[EMAIL PROTECTED]> wrote: > > Nick Coghlan wrote: > > Josiah Carlson wrote: > > >> This has the benefit that an arbitrary block of code can be named, > >> and a named TerminateBlock used to exit it. > > >> ... I suspect any such implementation is going to need to use > >> exceptions for the guts of the flow control, even if that use isn't > >> visible to the programmer. > > > Not necessarily. If I were implementing such a thing; any time > > arbitrary break/continues (to a loop that isn't the deepest) were used > > in nested loops, I would increment a counter any time a loop was entered, > > and decrement the counter any time a loop was exited. ... > > When named blocks are used in Lisp, they often cross function > boundaries. Given that, the number of intervening loops could > change depending on external variables. Since you would have > to pop frames anyhow, Exceptions are the right way to do it. I wasn't talking about cross-function blocks/named blocks. I was strictly talking about nested loops as they currently exist in Python. > If you limited the named-block gotos to within a single function/method, > then the loop counter would work (and you could limit obfuscation). > Unfortunately, you would lose most of the power of named blocks, > while still paying the full ugliness price. That's fine, I don't want named loops or blocks anyhow. I was merely offering an implementation that did not require exceptions, and was necessarily fast (proving both that it could be fast and not require exceptions). > You would also encourage > people to inline things that ought to be separate functions. I wouldn't go that far. If one were to introduce such functionality, it would be to ease control flow within nested for/while/blocks. Whether or not that lead to people inlining code, who are we to say? It would, however, complicate the 'inline function' decorator that I seem to have lost my link to. > In case it isn't clear, I think named loops would be a mistake. I > wanted them when I first started, but ... at the moment, I can't > think of any usage that wasn't an ugly speed hack, which is at > least more explicit with the "raise Found" idiom. Don't get me wrong, I think they would be a mistake as well, but they would solve the 'does a break statement in a block break its enclosing loop' question, as well as general nested loop flow control issues. Now that we both agree that they shouldn't be done, maybe one of us should write a PEP for Guido to rule on so that we never have to hear about loop naming (heh). - Josiah ___ 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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Ron Adam <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > > Ron Adam <[EMAIL PROTECTED]> wrote: > > > >> There's also the possibility to use conditional looping based on the > value returned from the generator. > >> > >> do VAR from EXPR if VAR==CONST: > >>BLOCK > >> > >> This is a bit verbose, but it reads well. :-) > > > > > > > > Reading well or not, this is not really an option for the same reasons > > why... > > > > for VAR in EXPR1 if EXPR2: > > or > > for VAR in EXPR1 while EXPR2: > > > > are not options. Keep it simple. > > > > Yes, so just "do [VAR from] EXPR1:" Regardless of the 'finalization' syntax, I'm talking about the fact that including extra 'if EXPR' or 'while EXPR' is not going to be an option. > >>3. Do-loops: An generator based loop with finalization: This > could be both single and multiple pass. The difference is determined by > weather or not the generator used loops the yield statement or not. > > > > > > Offering only generator-based finalization loops is, as I understand it, > > not an option. > > It could also include classes with __exit__ methods which are really > just more complex generators when used this way. > > But isn't this what PEP340 *already* proposes? Or am I missing a subtle > distinction here. It is, in fact, what PEP 340 already proposes. Let us take a step back for a moment and realize that this entire discussion is going around in circles. >From what I understand, we all agree: 1. There should be some mechanism X which signals that an indented suite is a 'block statement'. Such blocks are described and finalized as per PEP 340 (or whatever derivative gets accepted). 2. Standard for/while loops should not be finalized in a timely fashion, because testing for the proper methods would necessarily slow down large amounts of current Python, so should be left to the garbage collector. 3. A note as to the additional overhead of finalized blocks should be mentioned in the source code of the finalization implementation, and a note on their performace characteristics may or may not need to be listed in the language reference. What there is still discussion over: 4. What the syntax should be. 5. Whether or not it loops. 6. Method names. I find the answers to 4,5,6 to be a matter of opinion, and like many, I have my own. However, I do not feel strongly enough about 4,5,6 to argue about my opinion (I've been attempting to re-state where the conversation went for the last 2 weeks, as I have managed to read each and every email about the subject at hand *ick*). - Josiah ___ 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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Josiah Carlson wrote: >> Ron Adam <[EMAIL PROTECTED]> wrote: >>Yes, so just "do [VAR from] EXPR1:" > > Regardless of the 'finalization' syntax, I'm talking about the fact that > including extra 'if EXPR' or 'while EXPR' is not going to be an option. Yes, I meant for the syntax to be the shorter form, not for the programmer to just leave off the end. >>But isn't this what PEP340 *already* proposes? Or am I missing a subtle >>distinction here. > > It is, in fact, what PEP 340 already proposes. Let us take a step back > for a moment and realize that this entire discussion is going around in > circles. I think so too. > From what I understand, we all agree: > 1. There should be some mechanism X which signals that an indented suite > is a 'block statement'. Such blocks are described and finalized as per > PEP 340 (or whatever derivative gets accepted). +1 > 2. Standard for/while loops should not be finalized in a timely fashion, > because testing for the proper methods would necessarily slow down large > amounts of current Python, so should be left to the garbage collector. +1 Also add to this, it is not always desirable to finalize an object after use in a for loop. > 3. A note as to the additional overhead of finalized blocks should be > mentioned in the source code of the finalization implementation, and a > note on their performace characteristics may or may not need to be > listed in the language reference. +1 > What there is still discussion over: > 4. What the syntax should be. > 5. Whether or not it loops. > 6. Method names. > > I find the answers to 4,5,6 to be a matter of opinion, and like many, I > have my own. However, I do not feel strongly enough about 4,5,6 to > argue about my opinion (I've been attempting to re-state where the > conversation went for the last 2 weeks, as I have managed to read each > and every email about the subject at hand *ick*). > > - Josiah I think you clarified this well. Item 4: A list of possible syntax's with a vote at some point should do. Item 5: (A.) More use case's for looping blocks need to be found. I think there may be some or many that are not obvious at the moment. (B.) It may not cost much in performance to include the looping behavior. Maybe this should be put off till there is a working version of each, then comparisons of performance can be made in different situations? _Ron ___ 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] New Py_UNICODE doc
M.-A. Lemburg wrote: > On sre character classes: I don't think that these provide > a good approach to XML lexical classes - custom functions > or methods or maybe even a codec mapping the characters > to their XML lexical class are much more efficient in > practice. That isn't my experience: functions that scan XML strings are much slower than regular expressions. I can't imagine how a custom codec could work, so I cannot comment on that. 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] Python's Unicode width default (New Py_UNICODE doc)
M.-A. Lemburg wrote: > I think we should remove the defaulting to whatever > TCL uses and instead warn the user about a possible > problem in case TCL is found and uses a Unicode > width which is incompatible with Python's choice. -1. 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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Raymond Hettinger wrote: > [Nick Coghlan] > >>The number of good use cases for a looping block statement currently >>stands at >>exactly 1 (auto_retry). Every other use case suggested (locking, > > opening, > >>suppressing, etc) involves factoring out try statement boiler plate > > that > >>is far >>easier to comprehend with a single pass user defined statement. > > > I would like to offer up one additional use case, eliminating redundant > code in a do-while construct: > > > def do_while(cond_func): > yield > while cond_func(): > yield > > block do_while(lambda: a>b): > Nice example, but it doesn't need to intercept exceptions the way auto_retry does. Accordingly, a 'for' loop which makes [VAR in] optional would do the job just fine: for do_while(lambda: a>b): Even today, the following works: def do_while(cond_func): yield None while cond_func(): yield None for _ in do_while(lambda: a>b): Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Ron Adam <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > > I wasn't expressing my opinion, I was attempting to express as to where > > the discussion went and concluded. I honestly can't remember having an > > opinion on the subject, but I seem to have convinced Nick earlier that > > they shouldn't loop, and he (re-)convinced me that indeed, they > > shouldn't loop. > > So you can be re-re-convinced if more use cases are found? ;-) Historically, my opinion has meant close to 0 in regards to language features, so even if I were to change my mind again, I doubt it would have any effect on the outcome of this feature. > >>It needs some polish I think. ;-) > > > > > > Goodness, the horror! When implementation details start bleeding their > > way into actual language constructs (using a continue/break stack in > > order to control the flow of nested loops), that's a good clue that an > > idea has gone a bit too far. > > > > I would honestly prefer gotos, and I would prefer having no change to > > existing syntax to gaining gotos. > > Well I happen to like stacks for somethings. They can be very useful and > efficient. But I agree that they have been horrible abused in all sorts > of ways. But that doesn't make them bad. In this case I think they > work well, but the implementation ccould be improved. You missed my point. As an implementation detail, stacks are fine. As discussion about how one uses it, discussion of stacks is wholly out of the question. Think of it in terms of function calls. Do we talk about 'call stacks' when we make function calls? Of course not, and call stacks are a major part about how Python is implemented. This tells us that we certainly shouldn't talk about 'loop stacks' when we are talking about nested loops. > But this seems awkward and it's even *uglier*! > > try: > # some code in a loop. > except BreakException, Breakme: > pass > > then later > > raise Breakme# breaks a loop now instead of then. That's why we don't see many (if any) uses right now, even if it does solve the nested loop control flow 'problem'. > But these examples sort of point out an underlying concept in these > discussions. That it is useful to be able to postpone or delay code to > be executed at a later time. Thus the idioms, before-after, enter-exit, > and init-finalize. And here again, with try-finally, and breaks/continues. Apple, Apple, Apple, Apple, hotdog. One of those don't quite fit, and that's break/continue. Break/continue statements are about control flow, and while the other mechanisms can be used for control flow, that is not their primary purpose. The first three are about resource acquisition/release and try/finally is about making sure that a block of code is executed "no matter what" (the first three using try/finally as a mechanism to guarantee resource release, if acquisition has taken place). Let us look at the flow of the conversation... "There should be a resource acquisition/release statement with a code suite attached." ... lead to ... "The behavior of a break within such a code suite is ambiguous." ... lead to ... "Flow within nested loops themselves can be tricky and/or ambiguous." It's not that there is an underlying concept, it's just that the third bit of the conversation hadn't been brought up, but 'solving' that bit would unambiguate the previous 'break within code block' ambiguity. It's a sledge hammer solution to a jewel hammer problem. > > It's kind of funny. Every month I spend in python-dev, I feel less > > inclined to want to change the Python language (except for the relative > > import I need to finish implementing). Not because it is a pain in the > > tookus (though it is), but because many times it is my immediate sense > > of aesthetics that causes me to desire change, and my future of code > > maintenance makes me think forward to understanding Python 2.3 in the > > context of Python 2.9 . > > Changing it just for the sake of newness or "it's cool" or whatever > isn't good of course. In general, I was thinking "that would make my life as a programmer working with Python easier", but within a few days I realize that Python's power is in its simplicity. With every new language ability/feature, learning and using the language (necessarily) becomes more difficult. > But extending a language vs changing the way it > works, is worth while as long as it's done in a careful and consistent > manner. That's sort of why I'm against changing 'for', and for adding > the new loop/block. I see it as a loop with a higher level of > abstraction. A new tool to be used in new ways, but I want to keep my > old dependable tools too. I'm not sure that the discussion has been leading toward a change that is 'careful and consistent', but more of people offering their pet desired syntaxes (I've been having dejavu to the decorator discussion of last spring/summer). Of course the only
Re: [Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Ron Adam wrote: > That's sort of why I'm against changing 'for', and for adding > the new loop/block. I see it as a loop with a higher level of > abstraction. A new tool to be used in new ways, but I want to keep my > old dependable tools too. But if there's too much overlap in functionality between the old and the new tool, you're in danger of losing TOOWTDI. Random thought for the day: Programming tools are different from physical tools. I own quite a few different screwdrivers, several of which would be more or less equally good for any particular screw, and this isn't a problem. But I don't have a big crowd of people looking over my shoulder while I work, all trying to figure out why I chose one particular screwdriver over another, and decide which would be the best screwdriver to use on their screws. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Josiah Carlson wrote: > 2. Standard for/while loops should not be finalized in a timely fashion, > because testing for the proper methods would necessarily slow down large > amounts of current Python, so should be left to the garbage collector. I'm not convinced about that. If implemented properly, it could be as simple as testing whether a slot of a type object is populated during processing of the bytecode which causes exit from the loop. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Nick Coghlan wrote: > This bloats the generated byte code horribly, though - it is necessary to > produce two complete copies of the for loop code, since we don't know at > compile > time which version (finalising or non-finalising) will be needed. Unless I'm seriously mistaken, all the Python-equivalent loop code that's been presented is only for expositional purposes -- in real life, the logic would be embedded in the ceval code that implements the for-loop control bytecodes, so there would be little or no difference in the bytecode from what is generated today. > It also takes away from the programmer the ability to choose to do partial > iteration on generators that require finalisation. > > Accordingly, I switched to a version which puts control pack in the hands of > the > programmer. I still think it puts far too much burden on the user, though. The vast majority of the time, for-loops are intended to consume their iterators, and the user may not even know what flavour of iterator is being used, much less want to have to think about it. This means that nearly *every* for-loop would need to have a finally tacked on the end of it as a matter of course. It would be better to do it the other way around, and have a different form of looping statement for when you *don't* want finalization. The programmer knows he's doing a partial iteration when he writes the code, and is therefore in a position to choose the right statement. For backwards compatibility, the existing for-loop would work for partial iteration of old iterators, but this usage would be deprecated. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Jim Jewett wrote: > In case it isn't clear, I think named loops would be a mistake. I > wanted them when I first started, but ... at the moment, I can't > think of any usage that wasn't an ugly speed hack, which is at > least more explicit with the "raise Found" idiom. I'm inclined to agree. Anything more elaborate than breaking from a single place in the immediately enclosing loop tends to be getting into the realm of spaghetti, in my experience. Giving people named loops would be tantamount almost to giving them a goto. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Jim Jewett wrote: > If you're talking specific object instances, then the user is the > only one (outside of the Garbage Collection system) who has a > chance of knowing whether the rest of the iterator will be needed > later. Indeed. He *does* know whether he will want the iterator again later. He *doesn't* know whether it will require finalization when he is eventually done with it, and failing to do so if needed will cause obscure bugs. Also, not needing it again is the overwhelmingly commoner use case. My conclusion is that finalization should be the default, with a way of explicitly overriding it when necessary. > If there are no remaining references, then garbage collection is the > answer, and maybe we just need to make it more aggressive. If > there are remaining references, then maybe the user is wrong about > being done. Or maybe he's not wrong, and due to the way things are coded, the reference happens to hang around a little longer than strictly needed. If garbage collection were sufficient, we'd be relying on it to close our files in the first place, and this whole thread would never have gotten started. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [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
[Python-Dev] Merging PEP 310 and PEP 340-redux?
Apologies if this has been discovered and rejected already; I've had to skip most of the discussions but this though won't leave my head... So PEP 310 proposes this: with VAR = EXPR: BLOCK translated to VAR = EXPR\ if hasattr(VAR, "__enter__"): VAR.__enter__() try: BLOCK finally: VAR.__exit__() This equates VAR with the value of EXPR. It has a problem: what if inside BLOCK an assignment to VAR is made -- does this affect the finally clause or not? I think that the finally clause should use an internal variable that isn't affected by assignments to VAR. But what if we changed the translation slightly so that VAR gets assigned to value of the __enter__() call: abc = EXPR VAR = abc.__enter__() # I don't see why it should be optional try: BLOCK finally: abc.__exit__() Now it would make more sense to change the syntax to with EXPR as VAR: BLOCK and we have Phillip Eby's proposal. The advantage of this is that you can write a relatively straightforward decorator, call it @with_template, that endows a generator with the __enter__ and __exit__ methods, so you can write all the examples (except auto_retry(), which was there mostly to make a point) from PEP 340 like this: @with_template def opening(filename, mode="r"): f = open(filename, mode) yield f f.close() and so on. (Note the absence of a try/finally block in the generator -- the try/finally is guaranteed by the with-statement but not by the generator framework.) I used to dislike this, but the opposition and the proliferation of alternative proposals have made me realize that I'd rather have this (plus "continue EXPR" which will be moved to a separate PEP once I have some extra time) than most of the other proposals. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
[Jim Jewett] > > In case it isn't clear, I think named loops would be a mistake. I > > wanted them when I first started, but ... at the moment, I can't > > think of any usage that wasn't an ugly speed hack, which is at > > least more explicit with the "raise Found" idiom. [Greg Ewing] > I'm inclined to agree. Anything more elaborate than > breaking from a single place in the immediately > enclosing loop tends to be getting into the realm > of spaghetti, in my experience. Giving people named > loops would be tantamount almost to giving them > a goto. Yes please. Stop all discussion of breaking out of multiple loops. It ain't gonna happen before my retirement. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
