Mailman 3 October 2005 - Python-Dev

Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
by Guido van Rossum Oct. 24, 2005

Oct. 24, 2005

On 10/24/05, Bill Janssen <janssen(a)parc.com> wrote: > > > - yet others think: "I want all of Unicode, with proper, efficient > > > indexing, so I want four bytes per char". > > > > I doubt the last one though. Probably they really don't want efficient > > indexing, they want to perform higher-level operations that currently > > are only possible using efficient indexing or slicing. With the right > > API. perhaps they could work just as … [View More]

2 1

Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
by Phillip J. Eby Oct. 24, 2005

Oct. 24, 2005

At 06:06 PM 10/23/2005 -0700, Guido van Rossum wrote: >Folks, please focus on what Python 3000 should do. > >I'm thinking about making all character strings Unicode (possibly with >different internal representations a la NSString in Apple's Objective >C) and introduce a separate mutable bytes array data type. But I could >use some validation or feedback on this idea from actual >practitioners. +1. Chandler has been going through quite an upheaval to get its unicode … [View More]

3 2

Definining properties - a use case for class decorators?
by Nick Coghlan Oct. 24, 2005

Oct. 24, 2005

On and off, I've been looking for an elegant way to handle properties using decorators. It hasn't really worked, because decorators are inherently single function, and properties span multiple functions. However, it occurred to me that Python already contains a construct for grouping multiple related functions together: classes. And that thought led me to this decorator: def def_property(cls_func): cls = cls_func() try: fget = cls.get.im_func except … [View More]AttributeError: fget = None try: fset = cls.set.im_func except AttributeError: fset = None try: fdel = cls.delete.im_func except AttributeError: fdel = None return property(fget, fset, fdel, cls.__doc__) Obviously, this decorator can only be used by decorating a function that returns the class of interest: class Demo(object): @def_property def test(): class prop: """This is a test property""" def get(self): print "Getting attribute on instance" def set(self, value): print "Setting attribute on instance" def delete(self): print "Deleting attribute on instance" return prop Which gives the following behaviour: Py> Demo.test <property object at 0x00B9CC38> Py> Demo().test Getting attribute on instance Py> Demo().test = 1 Setting attribute on instance Py> del Demo().test Deleting attribute on instance Py> help(Demo.test) Help on property: This is a test property <get> = get(self) <set> = set(self, value) <delete> = delete(self) If we had class decorators, though, the decorator could be modified to skip the function invocation: def def_property(cls): try: fget = cls.get.im_func except AttributeError: fget = None try: fset = cls.set.im_func except AttributeError: fset = None try: fdel = cls.delete.im_func except AttributeError: fdel = None return property(fget, fset, fdel, cls.__doc__) And the usage would be much more direct: class Demo(object): @def_property class test: """This is a test property""" def get(self): print "Getting attribute on instance" def set(self, value): print "Setting attribute on instance" def delete(self): print "Deleting attribute on instance" Comments? Screams of horror? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com [View Less]

22 57

cross compiling python for embedded systems
by giovanniangeli＠iquattrocastelli.it Oct. 23, 2005

Oct. 23, 2005

is this the right place to ask: How could I build the python interpreter for an embedded linux target system (arm9 based), cross-compiling on a linux PC host? thanks, Giovanni Angeli.

3 2

Proposed resolutions for open PEP 343 issues
by Nick Coghlan Oct. 23, 2005

Oct. 23, 2005

I'm still looking for more feedback on the issues raised in the last update of PEP 343. There hasn't been much direct feedback so far, but I've rephrased and suggested resolutions for the outstanding issues based on what feedback I have received, and my own thoughts over the last week of so. For those simply skimming, my proposed issue resolutions are: 1. Use the slot name "__context__" instead of "__with__" 2. Reserve the builtin name "context" for future use as described below … [View More]3a. Give generator-iterators a native context that invokes self.close() 3b. Use "contextmanager" as a builtin decorator to get generator-contexts 4. Special case the __context__ slot to avoid the need to decorate it For those that disagree with the proposed resolutions above, or simply would like more details, here's the reasoning: 1. Should the slot be named "__with__" or "__context__"? Guido raised this as a side comment during the discussion of PJE's task variables pre-PEP, and it's a fair question. The closest analogous slot method ("__iter__") is named after the protocol it relates to, rather than the associated statement/expression keyword (that is, the method isn't called "__for__"). The next closest analogous slot is one that doesn't actually exist yet - the proposed "boolean" protocol. This again uses the name of a protocol rather than the associated keyword (that is, the name "__bool__" was suggested rather than "__if__"). At the moment, PEP 343 makes the opposite choice - it uses the keyword, rather than the protocol name (that is, it uses "__with__" instead of using "__context__"). That inconsistency would be a bad thing, in my opinion, and I propose that the slot should instead be named "__context__". 2. If the slot is called "__context__" what should a "context" builtin do? Again, considering existing slot names, a slot with a given name is generally invoked by the builtin type or function with the same name. This is true of the builtin types, and also true of iter, cmp and pow. getattr, setattr and delattr get in on the act as well. So, to be consistent, one would expect a "context" builtin to be able to be used such that "context(x)" invoked "x.__context__()". Such a method might special-case certain types, or have a two-argument form that accepted an "enter" function and an "exit" function, but using it to mark a generator that is to be used as a context manager (as currently suggested in PEP 343) would not be appropriate. I don't mind either way whether or not a "context" builtin is actually included for Python 2.5. However, even if it isn't included, the name should be reserved for that purpose (that is, we shouldn't be using it to name a generator decorator or a module). 3. How should generators behave when used as contexts? With PEP 342 accepted, generators pose a problem, because they have two possible uses as contexts. The first is for a generator that is intended to be used as an actual iterator. This case is a case of resource management - ensuring the close method is invoked on the generator-iterator when done with it (i.e., similar to the proposed native context for files). PEP 343 proposes a second use case for generators - to write custom context managers. In this case, the __enter__ method steps the generator once, and the __exit__ method finishes the job. I propose that we give generator-iterator objects resource management behaviour by default (i.e., __context__ and __enter__ methods that just "return self", and an __exit__ method that invokes "self.close()"). The "contextmanager" builtin decorator from previous drafts of the PEP (called simply "context" in the current draft) can then be used to get the custom context manager behaviour. I previously thought giving generators a native context caused problems with getting silent failures when the "contextmanager" decorator was inadvertently omitted. This is still technically true - the "with" statement itself won't raise a TypeError because the generator is a legal context. However, with this bug, the context manager won't be getting entered *at all* (it gets closed without its next() method ever being called). Even the most cursory testing of the generator-context function should be able to tell whether the generator-context is being entered or not. The main alternative (having yet-another-decorator to give generators "auto-close" functionality) would be possible, but the additional builtin clutter would be getting to the point where it started to concern me. And given that "yield" inside "try/finally" is now always legal, I consider it reasonable that using a generator in a "with" statement would also always be legal. Further, if type_new special cases __context__ as suggested below, then the context behaviour of generators used to define "__iter__" and "__context__" slots will always be appropriate. 4. Should the __context__ slot be special-cased in type_new? Currently, type_new special cases the "__new__" slot and automatically applies the staticmethod decorator when it finds a function occupying that slot in the class attribute dictionary. I propose that type_new also special case the situation where the "__context__" slot is occupied by a generator function, and automatically apply the "contextmanager" decorator. This looks much nicer when using a generator to write a __context__ function, and also avoids the situation where the decorator is omitted, and the object becomes legal to use directly in with statements but doesn't actually do the right thing. Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com [View Less]

3 4

AST reverts PEP 342 implementation and IDLE starts working again
by Raymond Hettinger Oct. 23, 2005

Oct. 23, 2005

FWIW, a few months ago, I reported that File New or File Open in IDLE would crash Python as a result of the check-in implementing PEP 342. Now, with AST checked-in, IDLE has started working again. Given the reconfirmation, I recommend that the 342 patch be regarded as suspect and not be restored until the fault is found and repaired. Raymond

2 2

Comparing date+time w/ just time
by skip＠pobox.com Oct. 22, 2005

Oct. 22, 2005

With significant input from Fred I made some changes to xmlrpclib a couple months ago to better integrate datetime objects into xmlrpclib. That raised some problems because I neglected to add support for comparing datetime objects with xmlrpclib.DateTime objects. (The problem showed up in MoinMoin.) I've been working on that recently (adding rich comparison methods to DateTime while retaining __cmp__ for backward compatibility), and have second thoughts about one of the original changes. I … [View More]

4 4

DRAFT: python-dev Summary for 2005-09-01 through 2005-09-16
by Tony Meyer Oct. 22, 2005

Oct. 22, 2005

This is over a month late, sorry, but here it is (Steve did his threads ages ago; I've fallen really behind). Summaries for the second half of September and the first half of October will soon follow. As always, if anyone is able to give this a quick look that would be great. Feedback to me or Steve (steven.bethard(a)gmail.com). Thanks! ============= Announcements ============= ----------------------------- QOTF: Quotes of the Fortnight ----------------------------- In the … [View More]

3 2

LXR site for Python CVS
by Hye-Shik Chang Oct. 22, 2005

Oct. 22, 2005

Hi, I just set up a LXR instance for Python CVS for my personal use: http://pxr.openlook.org/pxr/ If you find it useful, feel free to use the site. :) The source files will be updated twice a day. Hye-Shik

1 0

PEP 267 -- is the semantics change OK?
by Jim Jewett Oct. 21, 2005

Oct. 21, 2005

(In http://mail.python.org/pipermail/python-dev/2005-October/057501.html) Neil Schemenauer suggested PEP 267 as an example of something that might be easier with the AST compiler. As written, PEP 267 does propose a slight semantics change -- but it might be an improvement, if it is acceptable. Today, after from othermod import val1 import othermod val2 = othermod.val2 othermod.val3 # Just making sure it was referenced early othermod.val1 = "new1" othermod.val2 = "… [View More]

2 1