Mailman 3 September 2008 - Python-Dev

Patch review needed
by Jesus Cea Sept. 22, 2008

Sept. 22, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry to bother you, but I would like a patch review, since this code must be merged for 2.6. http://bugs.python.org/issue3885 Thanks in advance. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSNfaK5lgi5GaxT1NAQJCOAP+IVtGPcjjzWT/AefvEzxPajRmqf0H+MVn 5TO0STwkWuJHyYdv/z4OtA9UD6NTQ3Z4gLPOc5ZwlvhTW1gd856IBhVEFy1JARoJ ZERR7cp/WcdUSksHlC5qgTd2ZD1Y1VYcgCwTkL59D8R7I2wq752om6ZzhKs3SKC7 SG8kLYMlo9I= =P9mB -----END PGP SIGNATURE-----

1 0

Python documentation
by Barry Warsaw Sept. 22, 2008

Sept. 22, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin points out that in the past, as part of the release process, we've built separate downloadable documentation. Do we still want to do that for Python 2.6 and 3.0, and if so, how do we go about doing that? I have this feeling that building the documentation is much different now than in the past, and I don't really have a good feel for how it's done now. If you think we should release separate downloadable documentation and can help integrate that into the release project, you just might be a Documentation Expert <wink>. Please let me know if you can help. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSNOLBnEjvBPtnXfVAQIQnAQAm6thEThGufep6hzHxBwAN8MTsLb9jxsu Z8GAtX1bdMNOrJczYpU6by0oXPLR2pupnGV1YrAyQyoqpk+K7W8by5Qtg8+ZZcYH GerkqMVtNYn2zY1HhKigivp2JvlqIidRc5D36XS2EJixhZEPcOQDVm34THNQyRJT QasCQwdSAHI= =MbMY -----END PGP SIGNATURE-----

8 10

turtle.Screen.__init__ issue
by Gregor Lingl Sept. 22, 2008

Sept. 22, 2008

Hello there, its high time to resolve an issue, which I have already addressed twice some weeks ago. (You can find a more elaborate description in my former posting cited below) There is a tiny difference (also in behaviour!) in turtle.Screen.__init__() between the versions for 2.6 and 3.0. The difference results from the fact, that I submitted the 3.0 version approx. a week later, after having it ported to 3.0. In this process I had found what I now consider to be a bug in 2.6 and changed it accordingly. Shortly: If you have already a Screen object containing some turtles and some graphics, in 2.6: s = Screen() returns an object with identical state and behaviour, but clears (re-initializes) the screen and thus destroys the content in 3.0 s = Screen() returns an object with identical state and behaviour, but leaves the content untouched The difference in code consist only in indenting the call of the __init__ method of the parent class, so it will be executed only conditionally. Anyway, as this difference between the two versions is highly undesirable there are (imho) three options to proceed: (1) correct 2.6 in order that it will work like 3.0 (2) undo the change in 3.0 in order that it will work like 2.6 (3) find a different solution for both I would (like Vern, see below) decisevely prefer option (1), and I suppose that there is not enough time left to chose option (3) as this would probably need some discussions. What is your opinion, and who should decide? For your convenience I've attached a diff-file which also contains the description of three other small bugs, which I've found in the meantime and which shouldn't cause any controversies. Regards, Gregor %%%%%%%%%% Here follows the answer of Vern Ceder - a long term turtle graphics user and author of several patches for the old turtle module - to my former posting: >> 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 -------- Original-Nachricht -------- Betreff: [Python-Dev] turtle.Screen- how to implement best a Singleton Datum: Mon, 18 Aug 2008 10:15:45 +0200 Von: Gregor Lingl <gregor.lingl(a)aon.at> An: python-dev(a)python.org CC: Toby Donaldson <tjd(a)sfu.ca>, python-3000(a)python.org, jjposner(a)snet.net, Brad Miller <bonelake(a)gmail.com>, Vern Ceder <vceder(a)canterburyschool.org> 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 _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gregor.lingl%40aon.at --- turtle26rc2.py Thu Jun 12 20:39:36 2008 +++ turtle.py Mon Sep 22 00:02:25 2008 @@ -359,7 +359,9 @@ def __init__(self, master, width=500, height=350, canvwidth=600, canvheight=500): TK.Frame.__init__(self, master, width=width, height=height) - self._root = self.winfo_toplevel() + # renamed: self._root ==> self._rootwindow + # to avoid name conflict with TK.Frame method self._root + self._rootwindow = self.winfo_toplevel() self.width, self.height = width, height self.canvwidth, self.canvheight = canvwidth, canvheight self.bg = "white" @@ -379,7 +381,7 @@ self.hscroll.grid(padx=1, in_ = self, pady=1, row=1, column=0, rowspan=1, columnspan=1, sticky='news') self.reset() - self._root.bind('<Configure>', self.onResize) + self._rootwindow.bind('<Configure>', self.onResize) def reset(self, canvwidth=None, canvheight=None, bg = None): """Ajust canvas and scrollbars according to given canvas size.""" @@ -732,7 +734,7 @@ """Configure image item as to draw image object at position (x,y) on canvas) """ - self.cv.coords(item, (x, -y)) + self.cv.coords(item, (x * self.xscale, -y * self.yscale)) self.cv.itemconfig(item, image=image) def _setbgpic(self, item, image): @@ -3571,7 +3573,7 @@ self._root.setupcanvas(width, height, canvwidth, canvheight) Screen._canvas = self._root._getcanvas() self.setup(width, height, leftright, topbottom) - TurtleScreen.__init__(self, Screen._canvas) + TurtleScreen.__init__(self, Screen._canvas) Turtle._screen = self def setup(self, width=_CFG["width"], height=_CFG["height"], @@ -3612,6 +3614,7 @@ if starty is None: starty = (sh - height) / 2 self._root.set_geometry(width, height, startx, starty) + self.update() def title(self, titlestring): """Set title of turtle-window

2 2

Possible issue in warnings.py
by Scott David Daniels Sept. 21, 2008

Sept. 21, 2008

Does someone who knows the design of warnings.py a bit better than I know whether it would be an improvement to switch from: > try: > file.write(formatwarning(message, category, filename, > lineno, line)) > except IOError: > pass # the file (probably stderr) is invalid > # - this warning gets lost. to: > complaint = formatwarning(message, category, filename, > lineno, line) > try: > file.write(complaint) > except IOError: > pass # the file (probably stderr) is invalid > # - this warning gets lost. on the grounds that you might not want failures in the linecache code to behave the same as failures in writing the complaint to the target area? I'm working on a patch where the Idle warnings code seems to accidentally escalating warnings into errors, and it looked to me like this would accidentally swallow errors getting warning context and make them fail silently. The Idle issue that I'm fiddling with is that it doesn't take the new showwarning call format, and it looked like this should possibly be fixed at the same time. --Scott David Daniels Scott.Daniels(a)Acm.Org

2 1

Deploying a Python Service on Apache Axis2
by Heshan Suriyaarachchi Sept. 21, 2008

Sept. 21, 2008

Hi guys, Apache Axis2/Java, is a popular open source Web service engine. It currently supports exposing services written in Java, Javascript as Web services. This article [1] discusses the Python data Binding that enable exposing Web services written in Python. [1] - http://wso2.org/library/articles/deploying-python-service-axis2 [2] - http://heshans.blogspot.com/2008/09/wso2-wsfjython-10-alpha.html [3] - http://wso2.org/library/invoking-enterprise-web-services-using-jython -- Regards, Heshan Suriyaarachchi http://heshans.blogspot.com/

2 1

how about updating PEP 290?
by Fredrik Lundh Sept. 21, 2008

Sept. 21, 2008

the "Code Migration and Modernization" PEP hasn't been updated for 2.5 and 2.6. http://www.python.org/dev/peps/pep-0290/ surely there's something new in 2.5 and 2.6 that might be worth mentioning? </F>

1 0

bsddb tests disabled by default
by Jesus Cea Sept. 20, 2008

Sept. 20, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just installing 2.6rc2, I see that bsddb3 testsuite is disabled by default. Current testsuite is far more fast and stable that the old one (entire test: 17 seconds in my machine). I was wondering if it is time to enable bsddb3 testsuite by default. BTW: How is a "resource" enabled by an user, without touching sourcecode?. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSNJktZlgi5GaxT1NAQI7YQP+PwnNpfnJCsd3u/bAgjFQfHaRXMYlS1PN dZPb8lkzMbyanNituTC9VLxI97BXsSPSM7VNnbyO3lBVSvJxvsDaRDmoUynno+VX rw7+dD/mqKdyPujBjLzqYhbvQAoUOxLNac44/pTjvqoGiDa5CeR0AunUDnqnVVJa 4by7SBBxYrs= =sllZ -----END PGP SIGNATURE-----

5 7

Code coverage
by Walter Dörwald Sept. 19, 2008

Sept. 19, 2008

Hello all! The code coverage site at http://coverage.livinglogic.de/ was broken for the last few months. It's fixed again now and runs the test suite once per day with regrtest.py -T -N -uurlfetch,largefile,network,decimal Servus, Walter

2 1

What this code should do?
by Maciej Fijalkowski Sept. 19, 2008

Sept. 19, 2008

Hello, I'm a little clueless about exact semantics of following snippets: http://paste.pocoo.org/show/85698/ is this fine? or shall I fill the bug? (the reason to ask is because a) django is relying on this b) pypy implements it differently) cheers, fijal

5 5

ANNOUNCE: CapPython, an object-capability subset of Python
by Mark Seaborn Sept. 19, 2008

Sept. 19, 2008

During the past couple of months I have been working on an object-capability subset of Python - in other words, a restricted execution scheme for sandboxing Python code. It has been influenced by other object-capability subset languages, such as Joe-E (a subset of Java [1]), Caja/Cajita (subsets of Javascript [2]) and Caperl (based on Perl [3]). I'm calling it CapPython because the name doesn't seem to have been taken yet. :-) I believe it is now secure, so it seems like a good time to announce it here! The basic idea behind CapPython is to enforce encapsulation by restricting access to private attributes of objects. This is achieved through a combination of static checking and limiting access to unsafe builtins and modules. Private attributes may only be accessed through "self" variables. "Self" variables are defined as being the first arguments of functions defined inside class definitions, with a few restrictions intended to prevent these functions from escaping without being safely wrapped. Private attribute names are those starting with "_". Additionally, "im_self", "im_func" and some other special cases are treated as private attributes. Assignments to attributes are only allowed via "self" variables. For example, the following code is accepted by the static verifier: class Counter(object): def __init__(self): self._count = 0 def get_next(self): self._count += 1 return self._count But the following code reads a private attribute and so it is rejected as violating encapsulation: counter._count -= 1 CapPython consists of three parts: - a static verifier; - a "safe exec" function, which will check code before executing it and can run code in a safe scope; - a module loader which implements a safe __import__ function. Eventually this will be runnable as untrusted CapPython code. I am documenting CapPython via my blog at the moment, with the following posts so far: http://lackingrhoticity.blogspot.com/2008/08/introducing-cappython.html http://lackingrhoticity.blogspot.com/2008/09/dealing-with-modules-and-built… http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-methods-and-… The code is available from a Bazaar repository on Launchpad: https://code.launchpad.net/cappython I am currently working on creating a simple example program, which will be a wsgiref-based web server with a form for executing CapPython code. This involves taming some of the standard libraries to pass the verifier. There are some design notes here - http://plash.beasts.org/wiki/CapPython - although these notes are more a list of references and problems CapPython needs to address than an explanation of the current design. There was also a thread about CapPython on the e-lang mailing list: http://www.eros-os.org/pipermail/e-lang/2008-August/012828.html Mark [1] http://code.google.com/p/joe-e/ [2] http://code.google.com/p/google-caja/ [3] http://caperl.links.org/

6 8