Mailman 3 February 2006 - Python-Dev

PEP for Better Control of Nested Lexical Scopes
by Almann T. Goo 03 Mar '06

03 Mar '06

I am considering developing a PEP for enabling a mechanism to assign to free variables in a closure (nested function). My rationale is that with the advent of PEP 227 <http://www.python.org/peps/pep-0227.html>, Python has proper nested lexical scopes, but can have undesirable behavior (especially with new developers) when a user makes wants to make an assignment to a free variable within a nested function. Furthermore, after seeing numerous kludges to "solve" the problem with a mutable object, like a list, as the free variable do not seem "Pythonic." I have also seen mention that the use of classes can mitigate this, but that seems, IMHO, heavy handed in cases when an elegant solution using a closure would suffice and be more appropriate--especially when Python already has nested lexical scopes. I propose two possible approaches to solve this issue: 1. Adding a keyword such as "use" that would follow similar semantics as " global" does today. A nested scope could declare names with this keyword to enable assignment to such names to change the closest parent's binding. The semantic would be to keep the behavior we experience today but tell the compiler/interpreter that a name declared with the "use" keyword would explicitly use an enclosing scope. I personally like this approach the most since it would seem to be in keeping with the current way the language works and would probably be the most backwards compatible. The semantics for how this interacts with the global scope would also need to be defined (should " use" be equivalent to a global when no name exists all parent scopes, etc.) def incgen( inc = 1 ) : a = 6 def incrementer() : use a #use a, inc <-- list of names okay too a += inc return a return incrementer Of course, this approach suffers from a downside that every nested scope that wanted to assign to a parent scope's name would need to have the "use" keyword for those names--but one could argue that this is in keeping with one of Python's philosophies that "Explicit is better than implicit" (PEP 20<http://www.python.org/peps/pep-0020.html>). This approach also has to deal with a user declaring a name with "use" that is a named parameter--this would be a semantic error that could be handled like "global" does today with a SyntaxError. 2. Adding a keyword such as "scope" that would behave similarly to JavaScript's "var" keyword. A name could be declared with such a keyword optionally and all nested scopes would use the declaring scope's binding when accessing or assigning to a particular name. This approach has similar benefits to my first approach, but is clearly more top-down than the first approach. Subsequent "scope" declarations would create a new binding at the declaring scope for the declaring and child scopes to use. This could potentially be a gotcha for users expecting the binding semantics in place today. Also the scope keyword would have to be allowed to be used on parameters to allow such parameter names to be used in a similar fashion in a child scope. def incgen( inc = 1 ) : #scope inc <-- allow scope declaration for bound parameters (not a big fan of this) scope a = 6 def incrementer() : a += inc return a return incrementer This approach would be similar to languages like JavaScript that allow for explicit scope binding with the use of "var" or more static languages that allow re-declaring names at lower scopes. I am less in favor of this, because I don't think it feels very "Pythonic". As a point of reference, some languages such as Ruby will only bind a new name to a scope on assignment when an enclosing scope does not have the name bound. I do believe the Python name binding semantics have issues (for which the "global" keyword was born), but I feel that the "fixing" the Python semantic to a more "Ruby-like" one adds as many problems as it solves since the "Ruby-like" one is just as implicit in nature. Not to mention the backwards compatibility impact is probably much larger. I would like the community's opinion if there is enough out there that think this would be a worthwile endevour--or if there is already an initiative that I missed. Please let me know your questions, comments. Best Regards, Almann -- Almann T. Goo almann.goo(a)gmail.com

21 78

Re: [Python-Dev] str object going in Py3K
by Guido van Rossum 01 Mar '06

01 Mar '06

On 2/14/06, Just van Rossum <just(a)letterror.com> wrote: > Guido van Rossum wrote: > > [...] surely text files are more commonly used, and surely the > > most common operation should have the shorter name -- call it the > > Huffman Principle. > > +1 for two functions. > > My choice would be open() for binary and opentext() for text. I don't > find that backwards at all: the text function is going to be more > different from the current open() function then the binary function > would be since in many ways the str type is closer to bytes than to > unicode. It's still backwards because the current open function defaults to text on Windows (the only platform where it matters any more). > Maybe it's even better to use opentext() AND openbinary(), and deprecate > plain open(). We could even introduce them at the same time as bytes() > (and leave the open() deprecation for 3.0). And then, on 2/14/06, Alex Martelli <aleaxit(a)gmail.com> wrote: > What about shorter names, such as 'text' instead of 'opentext' and > 'data' instead of 'openbinary'? By eschewing the 'open' prefix we > might make it easy to eventually migrate off it. Maybe text and data > could be two subclasses of file, with file remaining initially as it > is (and perhaps becoming an abstract-only baseclass at the time 'open' > is deprecated). Plain 'text' and 'data' don't convey the fact that we're talking about opening I/O objects here. If you want, we could say textfile() and datafile(). (I'm fine with data instead of binary.) But somehow I still like the 'open' verb. It has a long and rich tradition. And it also nicely conveys that it is a factory function which may return objects of different types (though similar in API) based upon either additional arguments (e.g. buffering) or the environment (e.g. encodings) or even inspection of the file being opened. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

14 46

Proposal: defaultdict
by Guido van Rossum 01 Mar '06

01 Mar '06

A bunch of Googlers were discussing the best way of doing the following (a common idiom when maintaining a dict of lists of values relating to a key, sometimes called a multimap): if key not in d: d[key] = [] d[key].append(value) An alternative way to spell this uses setdefault(), but it's not very readable: d.setdefault(key, []).append(value) and it also suffers from creating an unnecessary list instance. (Timings were inconclusive; the approaches are within 5-10% of each other in speed.) My conclusion is that setdefault() is a failure -- it was a well-intentioned construct, but doesn't actually create more readable code. Google has an internal data type called a DefaultDict which gets passed a default value upon construction. Its __getitem__ method, instead of raising KeyError, inserts a shallow copy (!) of the given default value into the dict when the value is not found. So the above code, after d = DefaultDict([]) can be written as simply d[key].append(value) Note that of all the possible semantics for __getitem__ that could have produced similar results (e.g. not inserting the default in the underlying dict, or not copying the default value), the chosen semantics are the only ones that makes this example work. Over lunch with Alex Martelli, he proposed that a subclass of dict with this behavior (but implemented in C) would be a good addition to the language. It looks like it wouldn't be hard to implement. It could be a builtin named defaultdict. The first, required, argument to the constructor should be the default value. Remaining arguments (even keyword args) are passed unchanged to the dict constructor. Some more design subtleties: - "key in d" still returns False if the key isn't there - "d.get(key)" still returns None if the key isn't there - "d.default" should be a read-only attribute giving the default value Feedback? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

33 103

with-statement heads-up
by Guido van Rossum 28 Feb '06

28 Feb '06

I just realized that there's a bug in the with-statement as currently checked in. __exit__ is supposed to re-raise the exception if there was one; if it returns normally, the finally clause is NOT to re-raise it. The fix is relatively simple (I believe) but requires updating lots of unit tests. It'll be a while. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

4 9

2.4.3 for end of March?
by Anthony Baxter 28 Feb '06

28 Feb '06

So I'm planning a 2.4.3c1 around the 22nd-23rd of March, with a 2.4.3 final a week later. This will be the first release since the svn cutover, which should make things exciting. This is to get things cleared out before we start the cycle of pain - ahem - the 2.5 release cycle. A 2.4.4 would then follow when 2.5 final is done, hopefully October or so... Anyone have any screaming issues with this? Martin's ok to do the Windows release, and the doc build should be fine, too. Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Making ascii the default encoding
by Neal Norwitz 28 Feb '06

28 Feb '06

PEP 263 states that in Phase 2 the default encoding will be set to ASCII. Although the PEP is marked final, this isn't actually implemented. The warning about using non-ASCII characters started in 2.3. Does anyone think we shouldn't enforce the default being ASCII? This means if an # -*- coding: ... -*- is not set and non-ASCII characters are used, an error will be generated. n

2 1

Pre-PEP: The "bytes" object
by Neil Schemenauer 28 Feb '06

28 Feb '06

This could be a replacement for PEP 332. At least I hope it can serve to summarize the previous discussion and help focus on the currently undecided issues. I'm too tired to dig up the rules for assigning it a PEP number. Also, there are probably silly typos, etc. Sorry. Neil

8 12

Re: [Python-Dev] bytes.from_hex()
by Greg Ewing 28 Feb '06

28 Feb '06

Bill Janssen wrote: > I use it quite a bit for image processing (converting to and from the > "data:" URL form), and various checksum applications (converting SHA > into a string). Aha! We have a customer! For those cases, would you find it more convenient for the result to be text or bytes in Py3k? Greg

1 0

quick status report
by Jeremy Hylton 28 Feb '06

28 Feb '06

I made a few more minor revisions to the AST on the plane this afternoon. I'll check them in tomorrow when I get a chance to do a full test run. * Remove asdl_seq_APPEND. All uses replaced with set * Fix set_context() comments and check return value every where. * Reimplement real arena for pyarena.c Jeremy

1 0

Translating docs
by Facundo Batista 27 Feb '06

27 Feb '06

After a small talk with Raymond, yesterday in the breakfast, I proposed in PyAr the idea of start to translate the Library Reference. You'll agree with me that this is a BIG effort. But not only big, it's dynamic! So, we decided that we need a system that provide us the management of the translations. And it'd be a good idea the system to be available for translations in other languages. One of the guys proposed to use Launchpad (https://launchpad.net/). The question is, it's ok to use a third party system for this initiative? Or you (we) prefer to host it in-house? Someone alredy thought of this? Thank you! . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

4 4