Mailman 3 August 2008 - Python-Dev

Hanging out on freenode IRC #python-dev
by Barry Warsaw Aug. 19, 2008

Aug. 19, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I will be hanging out as much as possible over the next two days on the #python-dev channel on freenode IRC. If you have any last minute decisions you need, that will be the most immediate way to get in touch with me. Modulo work commitments, I'm generally available from about 7am to about 7pm US Eastern (UTC -0400) time. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKrEGHEjvBPtnXfVAQKCZAP+JyldH4bq1MO/0s5cJYDIM1hKNuXTm488 Ys/scWaPb7zBGi5/+Wdbwmle82EAsl3SDH6yDzjzhvgHOkOdsvaCP2bbVaXzDQ2r gOWs9jNBug/1HuGlaD3UPLehZ0I8Hy192XZz0o9z6jXmh7+ffbbDdyUW8x3D4IKX +pu/DsL8EkY= =+MNA -----END PGP SIGNATURE-----

1 0

parse_qs and parse_qsl functions
by Facundo Batista Aug. 19, 2008

Aug. 19, 2008

Hi! The issue 600362 has two patches (one for 2.6 and the other for 3.0) that are ready to commit (with a small change in the docs). This patches relocates the parse_qs and parse_qsl functions into the urlparse module (urllib.parse in 3k), bringing them from the cgi one. For backward compatibility, those functions are also accessible from the cgi module, but in the documentation says that the function was moved, and you should use it from the urlparse one. So, we don't have *any* change in the behaviour towards the final user. Two questions: - It's ok to do this now or we should wait for 3.1/2.7? - Should we add a deprecation warning in the cgi module for this functions? I propose to commit this now, but leave a deprecation warning for the next release. Thanks!! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

3 2

issue 3582
by Kristján Valur Jónsson Aug. 18, 2008

Aug. 18, 2008

Hello there. Yesterday I posted a feature request, http://bugs.python.org/issue3582, along with a patch. It provides platform specifict TLS functions on windows. Implementing it I came across the strange semantics of PyThread_set_key_value(). If a value has been set previously, it will ignore the set. This is most unusual, and I had to make two TLS calls in the NT version to emulate this behaviour. This behaviour is mentioned in pystate.c: The only situation where you can legitimately have more than one thread state for an OS level thread is when there are multiple interpreters, when: a) You shouldn't really be using the PyGILState_ APIs anyway, and: b) The slightly odd way PyThread_set_key_value works (see comments by its implementation) means that the first thread state created for that given OS level thread will "win", which seems reasonable behaviour. */ Now, this seems to be the only place where this is required, but I fail to see how even in this scenario it makes sense. As a) code says, you shouldn't be using the GIL api anyway, and it will undoubtebly create problems elsewhere if sticking the thread state into TLS fails silently. Changing this odd behaviour of PyThread_set_key_value () is trivial and would make it easier to use native TLS functions on other platforms. Any thoughts? K

2 1

optimization required: .format() is much slower than %
by Christian Heimes Aug. 18, 2008

Aug. 18, 2008

Dear fellow Python developers! Ten minutes ago I raised a concern about speed differences between the old style % formatting and the new .format() code. Some quick benchmarking from Benjamin and me showed, that it's even worse than I expected. $ ./python -m timeit "'%s'.format('nothing')" 100000 loops, best of 3: 2.63 usec per loop $ ./python -m timeit "'%s' % 'nothing'" 10000000 loops, best of 3: 0.188 usec per loop $ ./python -m timeit "'some text with {0}'.format('nothing')" 100000 loops, best of 3: 4.34 usec per loop $ ./python -m timeit "'some text with %s' % 'nothing'" 100000 loops, best of 3: 2.04 usec per loop $ ./python -m timeit "'some text with {0} {1}'.format('nothing', 'more')" 100000 loops, best of 3: 6.77 usec per loop $ ./python -m timeit "'some text with %s %s' % ('nothing', 'more')" 100000 loops, best of 3: 2.22 usec per loop As you can clearly see the new .format() code is *much* slower than the old style % code. I recommend we spend some time on optimizing common code paths of the new .format() code. As first step I propose the move the __format__ method to a new type slot. __format__() is called for every object. My gut feeling says that a slot method is going to speed up the most common usage "{0}".format(some_string). Christian

10 19

Re: [Python-Dev] turtle.Screen- how to implement best a Singleton
by Gregor Lingl Aug. 18, 2008

Aug. 18, 2008

Thanks for the feedback, Gregor Vern Ceder schrieb: > Gregor, > > I don't feel authoritative on the correctness/appropriateness of the > implementation, but I do agree completely that behavior b, or what you > have in the 3.0 version, is vastly preferable. > > Cheers, > Vern > > Gregor Lingl wrote: >> Hi, >> >> this posting - concerning the new turtle module - goes to the >> Python-Dev and Python-3000 lists and to a couple of 'power users' of >> turtle graphics, hoping to recieve feedback from the developer's >> point of view as well as from the user's point of view. >> >> Currently the implementations of the turtle.Screen class for Python >> 2.6 and Python 3.0 differ by a 'tiny' detail with an important >> difference in behaviour. So clearly this has to be resolved before >> the final release.(The origin of this difference is, that when I >> ported turtle.py to Python 3.0 I discovered (and 'fixed') what I now >> consider to be a bug in the 2.6 version.) I'd like to ask you kindly >> for your advice to achieve an optimal solution. >> >> The posting consists of three parts: >> 1. Exposition of design goals >> 2. Problem with the implementation 3. How to solve it? >> >> Preliminary remark: I've had some discussions on this topic before >> but I still do not see a clear solution. Moreover I'm well aware of >> the fact that using the Singleton pattern is controversial. So ... >> >> 1. Exposition of design goals >> ... why use the Singleton design pattern? The turtle module contains >> a TurtleScreen class, which implements methods to control the drawing >> area the turtle is (turtles are) drawing on. It's constructor needs a >> Tkinter Canvas as argument. In order to avoid the need for users to >> tinker around with Tkinter stuff there is the Screen(TurtleScreen) >> class, designed to be used by beginners(students, kids,...), >> particularly in interactive sessions. >> >> A (THE (!)) Screen object is essentially a window containing a >> scrolled canvas, the TurtleScreen. So it's a ressource which should >> exist only once. It can be constructed in several ways: >> - implicitely by calling an arbitrary function derived from a >> Turtle-method, such as forward(100) or by constructing a Turtle such >> as bob = Turtle() >> - implicitely by calling an arbitrary function derived from a Screen >> method, such as bgcolor("red") >> - explicitely by calling it's constructor such as s = Screen() >> Anyway this construction should only happen if a Screen object >> doesn't exist yet. >> Now for the pending question: What should happen, when s = Screen() >> is called explicitely and there exists already 'the' Screen object. >> (i) Clearly s should get a reference to the existing Screen object, >> but ... >> (ii) (a)... should s be reinitialized (this is the case now in Python >> 2.6), or >> (b)... should s be left untouched (this is the case now in Python >> 3.0) >> >> I, for my part, prefer the latter solution (b). Example: a student, >> having (interactively) produced some design using some turtle t = >> Turtle() decides spontaneously to change backgroundcolor. s = >> Screen(); s.bgcolor("pink") should do this for her - instead of >> deleting her design and moreover her turtle. To reinitialize the >> screen she still can use s.clear(). >> >> Of course, there are workarounds to achieve the same effect also with >> solution (a), for instance by assigning s = Screen() *before* drawing >> anything or by assigning s = t.getscreen(). But imho (which derives >> itself from my experience as a teacher) solution (b) supports better >> the oop-view as well as experimenting spontaneously in interactive >> sessions. >> >> 2. Problem with the implementation >> The task is to derive a Singleton class from a Nonsingleton class >> (Screen from TurtleScreen). The current implementations of the Screen >> 'Singleton' both use the Borg idiom. Just for *explaining* the >> difference between the two versions of class Screen here concisely, >> I'll use a 'standard' Singleton pattern (roughly equivalent to the >> Borg idiom): >> >> class Spam(object): >> def __init__(self, s): >> self.s = s >> >> class SingleSpam(Spam): >> _inst = None >> def __new__(cls, *args, **kwargs): if cls != >> type(cls._inst): >> cls._inst = Spam.__new__(cls, *args, **kwargs) >> return cls._inst >> def __init__(self, s): >> if vars(self): return ###### should this be here??? >> Spam.__init__(self, s) >> >> Shortly, this means that SingleSpam.__init__() acts like an empty >> method whenever a (the!) SingleSpam object already exists. 3.0 >> version of Screen acts like this. By contrast 2.6 version of Screen >> acts as if the butlast line were not there and thus reinitializes the >> Screen object. >> >> 3. How to solve it? >> >> Main question: which *behaviour* of the Screen class should be >> preferred. If 3.0, is it feasible and correct not to call the >> constructor of the parent class if the object already exists? >> >> Additional question: Do you consider the Borg idiom a good solution >> for this task or should the standard singleton pattern as shown above >> be preferred. Or would you suggest a solution/an approach different >> from both? >> >> Thanks for your patience, and - in advance - for your assistance >> >> Regard, >> Gregor >> >> >> >> >

1 0

turtle.Screen- how to implement best a Singleton
by Gregor Lingl Aug. 18, 2008

Aug. 18, 2008

Hi, this posting - concerning the new turtle module - goes to the Python-Dev and Python-3000 lists and to a couple of 'power users' of turtle graphics, hoping to recieve feedback from the developer's point of view as well as from the user's point of view. Currently the implementations of the turtle.Screen class for Python 2.6 and Python 3.0 differ by a 'tiny' detail with an important difference in behaviour. So clearly this has to be resolved before the final release.(The origin of this difference is, that when I ported turtle.py to Python 3.0 I discovered (and 'fixed') what I now consider to be a bug in the 2.6 version.) I'd like to ask you kindly for your advice to achieve an optimal solution. The posting consists of three parts: 1. Exposition of design goals 2. Problem with the implementation 3. How to solve it? Preliminary remark: I've had some discussions on this topic before but I still do not see a clear solution. Moreover I'm well aware of the fact that using the Singleton pattern is controversial. So ... 1. Exposition of design goals ... why use the Singleton design pattern? The turtle module contains a TurtleScreen class, which implements methods to control the drawing area the turtle is (turtles are) drawing on. It's constructor needs a Tkinter Canvas as argument. In order to avoid the need for users to tinker around with Tkinter stuff there is the Screen(TurtleScreen) class, designed to be used by beginners(students, kids,...), particularly in interactive sessions. A (THE (!)) Screen object is essentially a window containing a scrolled canvas, the TurtleScreen. So it's a ressource which should exist only once. It can be constructed in several ways: - implicitely by calling an arbitrary function derived from a Turtle-method, such as forward(100) or by constructing a Turtle such as bob = Turtle() - implicitely by calling an arbitrary function derived from a Screen method, such as bgcolor("red") - explicitely by calling it's constructor such as s = Screen() Anyway this construction should only happen if a Screen object doesn't exist yet. Now for the pending question: What should happen, when s = Screen() is called explicitely and there exists already 'the' Screen object. (i) Clearly s should get a reference to the existing Screen object, but ... (ii) (a)... should s be reinitialized (this is the case now in Python 2.6), or (b)... should s be left untouched (this is the case now in Python 3.0) I, for my part, prefer the latter solution (b). Example: a student, having (interactively) produced some design using some turtle t = Turtle() decides spontaneously to change backgroundcolor. s = Screen(); s.bgcolor("pink") should do this for her - instead of deleting her design and moreover her turtle. To reinitialize the screen she still can use s.clear(). Of course, there are workarounds to achieve the same effect also with solution (a), for instance by assigning s = Screen() *before* drawing anything or by assigning s = t.getscreen(). But imho (which derives itself from my experience as a teacher) solution (b) supports better the oop-view as well as experimenting spontaneously in interactive sessions. 2. Problem with the implementation The task is to derive a Singleton class from a Nonsingleton class (Screen from TurtleScreen). The current implementations of the Screen 'Singleton' both use the Borg idiom. Just for *explaining* the difference between the two versions of class Screen here concisely, I'll use a 'standard' Singleton pattern (roughly equivalent to the Borg idiom): class Spam(object): def __init__(self, s): self.s = s class SingleSpam(Spam): _inst = None def __new__(cls, *args, **kwargs): if cls != type(cls._inst): cls._inst = Spam.__new__(cls, *args, **kwargs) return cls._inst def __init__(self, s): if vars(self): return ###### should this be here??? Spam.__init__(self, s) Shortly, this means that SingleSpam.__init__() acts like an empty method whenever a (the!) SingleSpam object already exists. 3.0 version of Screen acts like this. By contrast 2.6 version of Screen acts as if the butlast line were not there and thus reinitializes the Screen object. 3. How to solve it? Main question: which *behaviour* of the Screen class should be preferred. If 3.0, is it feasible and correct not to call the constructor of the parent class if the object already exists? Additional question: Do you consider the Borg idiom a good solution for this task or should the standard singleton pattern as shown above be preferred. Or would you suggest a solution/an approach different from both? Thanks for your patience, and - in advance - for your assistance Regard, Gregor

1 0

Think a dead import finding script would be handy?
by Brett Cannon Aug. 18, 2008

Aug. 18, 2008

After Christian mentioned how we could speed up interpreter start-up by removing some dead imports he found, I decided to write up a quick script that generates the AST for a source file and (very roughly) tries to find imports that are never used. People think it's worth tossing into Tools, even if it is kind of rough? Otherwise I might toss it into the sandbox or make a quick Google code project out of it. Regardless, one interesting side-effect of the script is that beyond finding some extraneous imports in various places, it also found some holes in __all__. I have the script look for the definition of __all__ and consider an import used if it is listed there. -Brett

5 5

PEP-3121 and PyType_Copy
by Paul Pogonyshev Aug. 17, 2008

Aug. 17, 2008

Hi, In the mailing list archive I see a message that this PEP was implemented, dated June 10. However, while everything else PEP describes does seem to be in SVN, I cannot find PyType_Copy(). Is this function still planned for Python 3000, or are there any simple alternatives? Or are modules just supposed to share types across interpreters? Thanks, Paul

1 0

no-op symtable methods
by Benjamin Peterson Aug. 17, 2008

Aug. 17, 2008

I've been working on getting the symtable module back in working order. However, there are some methods that aren't functioning as they advertise because of changes in the compiler internally. I doubt that any cares or has noticed because I think it's been broken for several releases now. :) These methods are: Symbol.is_in_tuple() Symbol.is_vararg() Symbol.is_keyword() Anyway, if there are no objects, I will deprecate the functions in 2.6 and kill them off for good in 3.0. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."

1 0

A Testing language Construct that could also be a Distributed programming construct - How can this be done in Python
by Saravanan Shanmugham (sarvi) Aug. 17, 2008

Aug. 17, 2008

I am using Python as a test language and wondering how best to represent what is shown below in TTCN-3 TTCN-3, a testing domain specific language has a construct that looks like below Its trying to send a request and define 3 alternative outcomes/events. web_port.send("http://www.googe.com/") resonseTimer.start(300) alt { [] web_port.receive("something") { responseTimer.stop; setverdict(pass); } [] web_port.receive("somethingelse") { responseTimer.stop; setverdict(fail); } [] responseTimer.timeout { setverdict(fail); } } I am trying to do something similar with python and find myself in a fix as to how to code it clean. I can't do it with if ...elseif ... elseif .... else unless I wrap it in an event loop. Since otherwise it means that each condition function will be executed once. While what we are looking for is way to define potential events that can happen and a particular segment of code to executed for a specific event match The closest thing that I can do is something like this, assuming I implement the doalternatives method to take a list of function, code pairs. It would take the list of function-name, parameters list and run it in an event loop or in separate threads as the need may be to match one of them. When one of them matches it would be expected to run the code block associated with it. Which would get me the same behaviour. doalternatives( [web_port.receive,"something"], "responseTimer.stop; setverdict(pass);" [web_port.receive,"somethingelse"], "responseTimer.stop; setverdict(fail);" [responseTimer.timeout], "responseTimer.stop; setverdict(pass);" } The above looks pretty ok. Except that I have to define the python code block as a string. It would be nice if there was a python language construct that would allow me to define a block of python code that can be passed as a code object into a function. That would serve the above purpose as well as cases for distributed or parallel programming as well. A construct like invoke doalternatives with: param [web_port.receive,"something"] param: responseTimer.stop() setverdict(pass) param [web_port.receive,"something else"] param: responseTimer.stop() setverdict(fail) param [responseTimer.timeout] param: responseTimer.stop() setverdict(pass) I am sure we can do better than what I have proposed above. But the general idea is to be able to define and pass code segments as code objects around a function invocation and and pass the code objects as parameters into the invoked function. What do people think? Is there any existing construct that I might be missing to achieve the above? Sarvi

2 1