Mailman 3 May 2005 - Python-Dev

python-dev Summary for 2005-04-16 through 2005-04-30 [draft]
by Tony Meyer May 5, 2005

May 5, 2005

Here's April Part Two. If anyone can take their eyes of the anonymous block threads for a moment and give this a once-over, that would be great! Please send any corrections or suggestions to Tim (tlesher at gmail.com), Steve (steven.bethard at gmail.com) and/or me, rather than cluttering the list. Ta! ====================== Summary Announcements ====================== --------------- Exploding heads --------------- After a gentle introduction for our first summary, python-dev really let loose last fortnight; not only with the massive PEP 340 discussion, but also more spin-offs than a `popular`_ `TV`_ `series`_, and a few stand-alone threads. Nearly a week into May, and the PEP 340 talk shows no sign of abating; this is unfortunate, since Steve's head may explode if he has to write anything more about anonymous blocks. Just as well there are three of us! .. _popular: http://imdb.com/title/tt0060028/ .. _TV: http://imdb.com/title/tt0098844/ .. _series: http://imdb.com/title/tt0247082/ [TAM] ------- PEP 340 ------- A request for anonymous blocks by Shannon -jj Behrens launched a massive discussion about a variety of related ideas. This discussion is split into different sections for the sake of readability, but as the sections are extracted from basically the same discussion, it may be easiest to read them in the following order: 1. `Localized Namespaces`_ 2. `The Control Flow Management Problem`_ 3. `Block Decorators`_ 4. `PEP 310 Updates Requested`_ 5. `Sharing Namespaces`_ 6. `PEP 340 Proposed`_ [SJB] ========= Summaries ========= -------------------- Localized Namespaces -------------------- Initially, the "anonymous blocks" discussion focused on introducing statement-local namespaces as a replacement for lambda expressions. This would have allowed localizing function definitions to a single namespace, e.g.:: foo = property(get_foo) where: def get_foo(self): ... where get_foo is only accessible within the ``foo = ...`` assignment statement. However, this proposal seemed mainly to be motivated by a desire to avoid "namespace pollution", an issue which Guido felt was not really that much of a problem. Contributing threads: - `anonymous blocks <http://mail.python.org/pipermail/python-dev/2005-April/052717.html>`__ [SJB] ----------------------------------- The Control Flow Management Problem ----------------------------------- Guido suggested that if new syntax were to be introduced for "anonymous blocks", it should address the more important problem of being able to extract common patterns of control flow. A very typical example of such a problem, and thus one of the recurring examples in the thread, is that of a typical acquire/release pattern, e.g.:: lock.acquire() try: CODE finally: lock.release() Guido was hoping that syntactic sugar and an appropriate definition of locking() could allow such code to be written as:: locking(lock): CODE where locking() would factor out the acquire(), try/finally and release(). For such code to work properly, ``CODE`` would have to execute in the enclosing namespace, so it could not easily be converted into a def-statement. Some of the suggested solutions to this problem: - `Block Decorators`_ - `PEP 310 Updates Requested`_ - `Sharing Namespaces`_ - `PEP 340 Proposed`_ Contributing threads: - `anonymous blocks <http://mail.python.org/pipermail/python-dev/2005-April/052717.html>`__ [SJB] ---------------- Block Decorators ---------------- One of the first solutions to `The Control Flow Management Problem`_ was "block decorators". Block decorators were functions that accepted a "block object" (also referred to in the thread as a "thunk"), defined a particular control flow, and inserted calls to the block object at the appropriate points in the control flow. Block objects would have been much like function objects, in that they encapsulated a sequence of statements, except that they would have had no local namespace; names would have been looked up in their enclosing function. Block decorators would have wrapped sequences of statements in much the same way as function decorators wrap functions today. "Block decorators" would have allowed locking() to be written as:: def locking(lock): def block_deco(block): lock.acquire() try: block() finally: lock.release() return block_deco and invoked as:: @locking(lock): CODE The implementation of block objects would have been somewhat complicated if a block object was a first class object and could be passed to other functions. This would have required all variables used in a block object to be "cells" (which provide slower access than normal name lookup). Additionally, first class block objects, as a type of callable, would have confused the meaning of the return statement - should the return exit the block or the enclosing function? Contributing threads: - `anonymous blocks <http://mail.python.org/pipermail/python-dev/2005-April/052717.html>`__ - `Anonymous blocks: Thunks or iterators? <http://mail.python.org/pipermail/python-dev/2005-April/053093.html>`__ [SJB] ------------------------- PEP 310 Updates Requested ------------------------- Another suggested solution to `The Control Flow Management Problem`_ was the resuscitation of `PEP 310`_, which described a protocol for invoking the __enter__() and __exit__() methods of an object at the beginning and ending of a set of statements. This PEP was originally intended mainly to address the acquisition/release problem, an example of which is discussed in `The Control Flow Management Problem`_ as the locking() problem. Unmodified, `PEP 310`_ could handle the locking() problem defining locking() as:: class locking(object): def __init__(self, lock): self.lock = lock def __enter__(self): self.lock.acquire() def __exit__(self): self.lock.release() and invoking it as:: with locking(lock): CODE In addition, an extended version of the `PEP 310`_ protocol which augmented the __enter__() and __exit__() methods with __except__() and __else__() methods provided a simple syntax for some of the transactional use cases as well. Contributing threads: - `PEP 310 and exceptions: <http://mail.python.org/pipermail/python-dev/2005-April/052857.html>`__ - `__except__ use cases: <http://mail.python.org/pipermail/python-dev/2005-April/052868.html>`__ - `Integrating PEP 310 with PEP 340 <http://mail.python.org/pipermail/python-dev/2005-April/053039.html>`__ .. _PEP 310: http://www.python.org/peps/pep-0310.html [SJB] ------------------ Sharing Namespaces ------------------ Jim Jewett suggested that `The Control Flow Management Problem`_ could be solved in many cases by allowing arbitrary blocks of code to share namespaces with other blocks of code. As injecting such arbitrary code into a template has been traditionally done in other languages with compile-time macros, this thread briefly discussed some of the reasons for not wanting compile-time macros in Python, most importantly, that Python's compiler is "too dumb" to do much at compile time. The discussion then moved to runtime "macros", which would essentially inject code into functions at runtime. The goal here was that the injected code could share a namespace with the function into which it was injected. Jim Jewett proposed a strawman implementation that would mark includable chunks of code with a "chunk" keyword, and require these chunks to be included using an "include" keyword. The major problems with this approach were that names could "magically" appear in a function after including a chunk, and that functions that used an include statement would have dramatically slower name lookup as Python's lookup optimizations rely on static analysis. Contributing threads: - `defmacro (was: Anonymous blocks): <http://mail.python.org/pipermail/python-dev/2005-April/052854.html>`__ - `anonymous blocks vs scope-collapse: <http://mail.python.org/pipermail/python-dev/2005-April/052973.html>`__ - `scope-collapse: <http://mail.python.org/pipermail/python-dev/2005-April/053006.html>`__ - `anonymous blocks as scope-collapse: detailed proposal <http://mail.python.org/pipermail/python-dev/2005-April/053104.html>`__ [SJB] ---------------- PEP 340 Proposed ---------------- In the end, Guido decided that what he really wanted as a solution to `The Control Flow Management Problem`_ was the simplicity of something like generators that would let him write locking() as something like:: def locking(lock): lock.acquire() try: yield finally: lock.release() and invoke it as something like:: block locking(lock): CODE where the yield statement indicates the return of control flow to ``CODE``. Unlike a generator in a normal for-loop, the generator in such a "block statement" would need to guarantee that the finally block was executed by the end of the block statement. For this reason, and the fact that many felt that overloading for-loops for such non-loops might be confusing, Guido suggested introducing "block statements" as a new separate type of statement. `PEP 340`_ explains the proposed implementation. Essentially, a block-statement takes a block-iterator object, and calls its __next__() method in a while loop until it is exhausted, in much the same way that a for-statement works now. However, for generators and well-behaved block-iterators, the block-statement guarantees that the block-iterator is exhausted, by calling the block-iterator's __exit__() method. Block-iterator objects can also have values passed into them using a new extended continue statement. Several people were especially excited about this prospect as it seemed very useful for a variety of event-driven programming techniques. A few issues still remained unresolved at the time this summary was written: Should the block-iterator protocol be distinct from the current iterator protocol? Phillip J. Eby campaigned for this, suggesting that by treating them as two separate protocols, block-iterators could be prevented from accidentally being used in for-loops where their cleanup code would be silently omitted. Having two separate protocols would also allow objects to implement both protocols if appropriate, e.g. perhaps sometimes file objects should close themselves, and sometimes they shouldn't. Guido seemed inclined to instead merge the two protocols, allowing block-iterators to be used in both for-statements and block-statements, saying that the benefits of having two very similar but distinct protocols were too small. What syntax should block-statements use? This one was still undecided, with dozens of different keywords having been proposed. Syntaxes that did not seem to have any major detractors at the time this summary was written: * ``EXPR as NAME: BLOCK`` * ``@EXPR as NAME: BLOCK`` * ``in EXPR as NAME: BLOCK`` * ``block EXPR as NAME: BLOCK`` * ``finalize EXPR as NAME: BLOCK`` Contributing threads: - `anonymous blocks <http://mail.python.org/pipermail/python-dev/2005-April/052717.html>`__ - `next(arg) <http://mail.python.org/pipermail/python-dev/2005-April/053156.html>`__ - `PEP 340 - possible new name for block-statement <http://mail.python.org/pipermail/python-dev/2005-April/053109.html>`__ - `PEP 340: syntax suggestion - try opening(filename) as f: <http://mail.python.org/pipermail/python-dev/2005-April/053163.html>`__ - `Keyword for block statements <http://mail.python.org/pipermail/python-dev/2005-April/053184.html>`__ - `About block statement name alternative <http://mail.python.org/pipermail/python-dev/2005-April/053139.html>`__ - `Integrating PEP 310 with PEP 340 <http://mail.python.org/pipermail/python-dev/2005-April/053039.html>`__ .. _PEP 340: http://www.python.org/peps/pep-0340.html [SJB] ------------------ A switch statement ------------------ The switch statement (a la `PEP 275`_) came up again this month, as a spin-off (wasn't everything?) of the `PEP 340`_ discussion. The main benefit of such a switch statement is avoiding Python function calls, which are very slow compared to branching to inlined Python code. In addition, repetition (the name of the object being compared, and the comparison operator) is avoided. Although Brian Beck contributed a `switch cookbook recipe`_, the discussion didn't progress far enough to make any changes or additions to `PEP 275`_. Contributing threads: - `switch statement <http://mail.python.org/pipermail/python-dev/2005-April/052778.html>`__ .. _PEP 275: http://www.python.org/peps/pep-0275.html .. _switch cookbook recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/410692 [TAM] ---------------- Pattern Matching ---------------- Discussion about a dictionary-lookup switch statement branched out to more general discussion about pattern matching statements, like Ocaml's "match", and Haskell's case statement. There was reasonable interest in pattern matching, but since types are typically a key feature of pattern matching, and many of the elegant uses of pattern matching use recursion to traverse data structures, both of which hinder coming up with a viable Python implementation (at least while CPython lacks tail-recursion elimination). The exception to this is matching strings, where regular expressions provide a method of pattern specification, and multi-way branches based on string content is common. As such, it seems unlikely that any proposals for new pattern matching language features will be made at this time. Contributing threads: - `switch statement <http://mail.python.org/pipermail/python-dev/2005-April/052778.html>`__ [TAM] ----------------------------------------- Read-only property access inconsistencies ----------------------------------------- Barry Warsaw noticed that the exception thrown for read-only properties of C extension types is a TypeError, while for read-only properties of Python (new-style) classes is an AttributeError, and `wrote a patch`_ to clean up the inconsistency. Guido pronounced that this was an acceptable fix for 2.5, and so the change was checked in. Along the way, he wondered whether in the long-term, AttributeError should perhaps inherit from TypeError. Contributing threads: - `Inconsistent exception for read-only properties? <http://mail.python.org/pipermail/python-dev/2005-April/052681.html>`__ .. _wrote a patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1184449&group_id=54 70&atid=105470 [TAM] -------------------- site.py enhancements -------------------- Bob Ippolito asked for review of a `patch to site.py`_ to solve three deficiencies for Python 2.5: - It is no longer true that all site dirs must exist on the file system - The directories added to sys.path by .pth files are not scanned for further .pth files - .pth files cannot use os.path.expanduser() Greg Ewing suggested additionally scanning the directory containing the main .py file for .pth files to make it easier to have collections of Python programs sharing a common set of modules. Possibly swamped by the `PEP 340`_ threads, further discussion trailed off, so it's likely that Bob's patch will be applied, but without Greg's proposal. Contributing threads: - `site enhancements (request for review) <http://mail.python.org/pipermail/python-dev/2005-April/052885.html>`__ .. _patch to site.py: http://python.org/sf/1174614 [TAM] ------------------------------------- Passing extra arguments when building ------------------------------------- Martin v. Löwis helped Brett C out with adding some code to facilitate a Py_COMPILER_DEBUG build for use on the AST branch. Specifically, an EXTRA_CFLAGS environment variable was added to the build process, to enable passing additional arguments to the compiler, that aren't modified by configure, and that change binary compatibility. Contributing threads: - `Proper place to put extra args for building <http://mail.python.org/pipermail/python-dev/2005-April/052746.html>`__ [TAM] --------------------------- zipfile module improvements --------------------------- Bob Ippolito pointed out that the "2GB bug" that was `supposed to be fixed`_ was not, and opened a `new bug and patch`_ that should fix the issue correctly, as well as a bug that sets the ZipInfo record's platform to Windows, regardless of the actual platform. He suggested that someone should consider rewriting the zipfile module to include a repair feature, and be up-to-date with `the latest specifications`_, and include support for Apple's zip format extensions. Charles Hartman added deleting a file from a zipfile to this list. Bob suggested that one of the most useful additions to the zipfile module would be a stream interface for reading and writing (a `patch to read large items`_ along these lines already exists). Guido liked this idea and suggested that Bob rework the zipfile module, if possible, for Python 2.5. Contributing threads: - `zipfile still has 2GB boundary bug <http://mail.python.org/pipermail/python-dev/2005-April/052887.html>`__ .. _supposed to be fixed: http://python.org/sf/679953 .. _new bug and patch: http://python.org/sf/1189216 .. _the latest specifications: http://www.pkware.com/company/standards/appnote/ .. _patch to read large items: http://python.org/sf/1121142 [TAM] ------------------------------------- super_getattro() and attribute lookup ------------------------------------- Phil Thompson asked a number of questions about super_getattro(), and attribute lookup. Michael Hudson answered these, and pointed out that there has been `some talk`_ of having a tp_lookup slot in typeobjects. However, he noted that he has many other pots on the boil at the moment, so is unlikely to work on it soon. Contributing threads: - `super_getattro() Behaviour <http://mail.python.org/pipermail/python-dev/2005-April/052655.html>`__ .. _some talk: http://mail.python.org/pipermail/python-dev/2005-March/052150.html [TAM] -------------------------------- Which objects are memory cached? -------------------------------- Facundo Batista asked about memory caching of objects (for performance reasons), to aid in explaining how to think using name/object and not variable/value. In practice, ints between -5 and 100 are cached, 1-character strings are often cached, and string literals that resemble Python identifiers are often interned. It was noted that the reference manual specifies that immutables *may* be cached, but that CPython specifics, such as which objects are, are omitted so that people will not think of them as fixed; Terry Reedy reiterated his suggestion that implementation details such as this are documented separately, elsewhere. Guido and Greg Ewing pointed out that when explaining it is important for the explainees to understand that mutable objects are never in danger of being shared. Contributing threads: - `Caching objects in memory <http://mail.python.org/pipermail/python-dev/2005-April/052844.html>`__ [TAM] ------------------------------ Unregistering atexit functions ------------------------------ Nick Jacobson noted that while you can mark functions to be called with at exit with the 'register' method, there's no 'unregister' method to remove them from the stack of functions to be called. Many suggestions were made about how this could already be done, however, including using try/finally, writing the cleanup routines in such a way that they could detect reentry, passing a class to register(), and managing a list of functions oneself. General pearls of wisdom outlined included: - if one devotes time to "making a case", then one should also devote equal effort to researching the hazards and API issues. - "Potentially useful" is usually trumped by "potentially harmful". - if the API is awkward or error-prone, that is a bad sign. Contributing threads: - `atexit missing an unregister method <http://mail.python.org/pipermail/python-dev/2005-April/052983.html>`__ [TAM] ----------------------- Pickling buffer objects ----------------------- Travis Oliphant proposed a patch to the pickle module to allow pickling of the buffer object. His use case was avoiding copying array data into a string before writing to a file in Numeric, while still having Numeric arrays interact seamlessly with other pickleable types. The proposal was to unpickle the object as a string (since a `bytes object`_ does not exist) rather than to mutable-byte buffer objects, to maintain backwards compatibility. Other than a couple of questions, no objections were raised, so a patch is likely to appear. Contributing threads: - `Pickling buffer objects. <http://mail.python.org/pipermail/python-dev/2005-April/052707.html>`__ .. _bytes object: http://python.org/peps/pep-0296.html [TAM] =============== Skipped Threads =============== - `Another Anonymous Block Proposal <http://mail.python.org/pipermail/python-dev/2005-April/053031.html>`__ - `PEP 340: What is "ret" in block statement semantics? <http://mail.python.org/pipermail/python-dev/2005-April/053140.html>`__ - `anonymous blocks (off topic: match) <http://mail.python.org/pipermail/python-dev/2005-April/052759.html>`__ - `Reference counting when entering and exiting scopes <http://mail.python.org/pipermail/python-dev/2005-April/052779.html>`__ - `How do you get yesterday from a time object <http://mail.python.org/pipermail/python-dev/2005-April/052712.html>`__ - `shadow password module (spwd) is never built due to error in setup.py <http://mail.python.org/pipermail/python-dev/2005-April/052679.html>`__ - `Problem with embedded python <http://mail.python.org/pipermail/python-dev/2005-April/052995.html>`__ - `python.org crashing Mozilla? <http://mail.python.org/pipermail/python-dev/2005-April/052992.html>`__ - `noob question regarding the interpreter <http://mail.python.org/pipermail/python-dev/2005-April/053103.html>`__ - `Newish test failures <http://mail.python.org/pipermail/python-dev/2005-April/052771.html>`__ - `Error checking in init<module> functions <http://mail.python.org/pipermail/python-dev/2005-April/052847.html>`__ - `a few SF bugs which can (probably) be closed <http://mail.python.org/pipermail/python-dev/2005-April/052864.html>`__ - `Check out a new way to read threaded conversations. <http://mail.python.org/pipermail/python-dev/2005-April/052674.html>`__ - `Python 2.1 in HP-UX <http://mail.python.org/pipermail/python-dev/2005-April/052710.html>`__ - `Python tests fails on HP-UX 11.11 and core dumps <http://mail.python.org/pipermail/python-dev/2005-April/052652.html>`__ - `IPV6 with Python- 4.2.1 on HPUX <http://mail.python.org/pipermail/python-dev/2005-April/052656.html>`__ - `Fwd: CFP: DLS05: ACM Dynamic Languages Symposium <http://mail.python.org/pipermail/python-dev/2005-April/052699.html>`__ - `PyCon 2005 keynote on-line <http://mail.python.org/pipermail/python-dev/2005-April/052684.html>`__ - `PyCallable_Check redeclaration <http://mail.python.org/pipermail/python-dev/2005-April/052677.html>`__ - `os.urandom uses closed FD (sf 1177468) <http://mail.python.org/pipermail/python-dev/2005-April/052716.html>`__ - `Removing --with-wctype-functions support <http://mail.python.org/pipermail/python-dev/2005-April/052968.html>`__

1 0

Re: [Python-Dev] PEP 340: Breaking out.
by Delaney, Timothy C (Timothy) May 5, 2005

May 5, 2005

Aahz wrote: > My standard workaround is using exceptions, but I'm not sure how that > interacts with a block: > > try: > for name in filenames: > with opened(name) as f: > if f.read(2) == 0xFEB0: > raise Found > except Found: > pass For any sane block iterator, it will work as expected. However, an evil block iterator could suppress the `Found` exception. A sane block iterator should re-raise the original exception. Tim Delaney

2 1

Need to hook Py_FatalError
by m.u.k May 4, 2005

May 4, 2005

Greetings, Currently Py_FatalError only dumps the error to stderr and calls abort(). When doing quirky things with the interpreter, it's so annoying that process just terminates. Are there any reason why we still dont have a simple callback to hook Py_FatalError. PS. If the answer is "because no one needs/implemented...", I can volunteer. Best regards.

7 19

Py_UNICODE madness
by Nicholas Bastin May 4, 2005

May 4, 2005

The documentation for Py_UNICODE states the following: "This type represents a 16-bit unsigned storage type which is used by Python internally as basis for holding Unicode ordinals. On platforms where wchar_t is available and also has 16-bits, Py_UNICODE is a typedef alias for wchar_t to enhance native platform compatibility. On all other platforms, Py_UNICODE is a typedef alias for unsigned short." However, we have found this not to be true on at least certain RedHat versions (maybe all, but I'm not willing to say that at this point). pyconfig.h on these systems reports that PY_UNICODE_TYPE is wchar_t, and PY_UNICODE_SIZE is 4. Needless to say, this isn't consistent with the docs. It also creates quite a few problems when attempting to interface Python with other libraries which produce unicode data. Is this a bug, or is this behaviour intended? It turns out that at some point in the past, this created problems for tkinter as well, so someone just changed the internal unicode representation in tkinter to be 4 bytes as well, rather than tracking down the real source of the problem. Is PY_UNICODE_TYPE always going to be guaranteed to be 16 bits, or is it dependent on your platform? (in which case we can give up now on Python unicode compatibility with any other libraries). At the very least, if we can't guarantee the internal representation, then the PyUnicode_FromUnicode API needs to go away, and be replaced with something capable of transcoding various unicode inputs into the internal python representation. -- Nick

4 8

Re: [Python-Dev] PEP 340: Breaking out.
by Shane Hathaway May 4, 2005

May 4, 2005

Ka-Ping Yee wrote: > On Wed, 4 May 2005, Shane Hathaway wrote: >> >> for name in filenames: >> opening(name) as f: >> if f.read(2) == 0xFEB0: >> break for > > > This is very elegant. Thanks. > It works beautifully with "break", though at > first that natural analogs "continue for", "continue while" appear to > conflict with Guido's proposed extension to "continue". > > But if we choose the keyword "with" to introduce an anonymous block, > it comes out rather nicely: > > continue with 2 > > That's easier to read than "continue 2", in my opinion. (If it's not > too cute for you.) Or perhaps: continue yield 2 This would create some symmetry, since generators will retrieve the value passed by a continue statement using a yield expression. Shane

1 0

"begin" as keyword for pep 340
by Adam Souzis May 4, 2005

May 4, 2005

I'm a bit surpised that no one has yet [1] suggested "begin" as a keyword instead "block" as it seems to express the intent of blocks and is concise and readable. For example, here are the examples in PEP 340 rewritten using "begin": begin locking(): ... begin opening(path) as f: #how about: begin using_file(path) as f: ... begin transaction(db): ... begin auto_retry(3): ... begin redirecting_stdout: .... Probably the biggest problem with "begin" is that it is relatively common as an identify. For example, Greping through Python's Lib directory, begin is used as a method name twice (in httplib and idlelib.pyshell) and as a local twice (in mhlib and pyassemb). However, i can't think of many instances where there would be ambiguity in usage -- could 'begin' be a pseudo-identifier like "as" for some transitional time? -- adam [1] (Or maybe GMail's search has failed me ;)

3 2

my first post: asking about a "decorator" module
by Michele Simionato May 4, 2005

May 4, 2005

My first post to python-dev, but I guess my name is not completely unknown in this list ;) Actually, I have been wondering about subscribing to python-dev for at least a couple of years, but never did it, because of the limited amount of time I have to follow all the interesting mailing lists in the world. However, in the last few months I have been involved with teaching Python and I have decided to follow more closely the development to keep myself updated on what is going on. Plus, I have some ideas I would like to share with people in this list. One of them concerns decorators. Are there plans to improve decorators support in future Python versions? By "improving decorator support" I mean for instance a module in the standard library providing some commonly used decorators such as ``memoize``, or utilities to create and compose decorators, and things like that. I have been doing some work on decorators lately and I would be willing to help is there is a general interest about a "decorator" module. Actually, I have already a good candidate function for that module, and plenty of recipes. I submitted an early version of the idea some time ago on c.l.py http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/60f2… but I could as well flesh it out and deliver a module people can play with and see if they like it. This is especially interesting in this moment, since decorators may address many of the use cases of PEP 340 (not all of them). I need to write down some documentation, but it could be done by tomorrow. What do people think? Michele Simionato

2 1

Python Language track at Europython, still possibilities to submit talks
by Samuele Pedroni May 4, 2005

May 4, 2005

I'm the track chair of the Python Language track at Europython (27-29 June, Göteborg, Sweden) . The general deadlline for talk submission has been extended until the 7th of May. There are still open slots for the language track. So if someone with (core) language interests is or may be interested in partecipating, there's still the possibility to submit talks about idioms, patterns, recent new additions to language (for example new 2.4 features), or other language related topics. http://www.europython.org/sections/tracks_and_talks/propose_a_talk/#language http://www.europython.org/sections/tracks_and_talks/propose_a_talk/ http://www.europython.org Regards, Samuele Pedroni, Python Language Track chair.

1 0

Re: [Python-Dev] PEP 340 -- concept clarification
by Delaney, Timothy C (Timothy) May 4, 2005

May 4, 2005

Guido van Rossum wrote: > I'd like the block statement to be defined exclusively in terms of > __exit__() though. This does actually suggest something to me (note - just a thought - no real idea if it's got any merit). Are there any use cases proposed for the block-statement (excluding the for-loop) that do *not* involve resource cleanup (i.e. need an __exit__)? This could be the distinguishing feature between for-loops and block-statements: 1. If an iterator declares __exit__, it cannot be used in a for-loop. For-loops do not guarantee resource cleanup. 2. If an iterator does not declare __exit__, it cannot be used in a block-statement. Block-statements guarantee resource cleanup. This gives separation of API (and thus purpose) whilst maintaining the simplicity of the concept. Unfortunately, generators then become a pain :( We would need additional syntax to declare that a generator was a block generator. OTOH, this may not be such a problem. Any generator that contains a finally: around a yield automatically gets an __exit__, and any that doesn't, doesn't. Although that feels *way* too magical to me (esp. in light of my example below, which *doesn't* use finally). I'd prefer a separate keyword for block generators. In that case, having finally: around a yield would be a syntax error in a "normal" generator. :: resource locking(lock): lock.acquire() try: yield finally: lock.release() block locking(myLock): # Code here executes with myLock held. The lock is # guaranteed to be released when the block is left (even # if via return or by an uncaught exception). To use a (modified) example from another email:: class TestCase: resource assertRaises (self, excClass): try: yield except excClass: return else: if hasattr(excClass, '__name__'): excName = excClass.__name__ else: excName = str(excClass) raise self.failureException, "%s is not raised" % excName block self.assertRaises(TypeError): raise TypeError Note that this *does* require cleanup, but without using a finally: clause - the except: and else: are the cleanup code. Tim Delaney

2 1

Re: [Python-Dev] PEP 340 -- loose ends
by Nick Coghlan May 4, 2005

May 4, 2005

Paul Svensson wrote: > On Tue, 3 May 2005, Nick Coghlan wrote: > >> I'd also suggest that the blocktemplate decorator accept any iterator, >> not just >> generators. > > > So you want decorators on classes now ? A decorator is just a function - it doesn't *need* to be used with decorator syntax. I just think the following code should work for any iterator: block blocktemplate(itr): # Do stuff Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net

9 32