-----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-----
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
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
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>
-----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-----
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
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
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.htmlhttp://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/
