[Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

2009-05-04 Thread Larry Hastings 


I should have brought this up to python-dev before--sorry for being so 
slow.  It's already in the tracker for a couple of days:


   http://bugs.python.org/issue5880

The idea: PyGetSetDef has this "void *closure" field that acts like a 
context pointer.  You stick it in the PyGetSetDef, and it gets passed 
back to you when your getter or setter is called.  It's a reasonable API 
design, but in practice you almost never need it.  Meanwhile, it 
clutters up CPython, particularly typeobject.c; there are all these 
function calls that end with ", NULL);", just to satisfy the 
getter/setter prototype internally.


Most of the time, the "closure" parameter is not only unused, it is 
skipped.  PyGetSetDef definitions generally skip it, and often getter 
and setter implementations omit it.  The "closure" was only actually 
*used* once in CPython, a silly use in Objects/longobject.c where it was 
abused as an integer value.  And yes, I said "was": inspired by this 
discussion, Mark Dickinson removed this use in r72202 (trunk) and r72203 
(py3k).  So the "closure" field is now 100% unused in the python and 
py3k trunks.


Mr. Dickinson also located an extension using the "closure" pointer, 
pyephem, which... *also* uses it to store an integer.  Indeed, I have 
yet to see a use where someone stores a pointer in "closure".


Anyone who needed functionality like this could roll it themselves with 
stub functions:


   PyObject *my_getter_with_context(PyObject *self, void *context) {
 /* ... */
   }

   PyObject *my_getter_A(PyObject *self) {
 return my_getter_with_context(self, "A");
   }


   PyObject *my_getter_B(PyObject *self) {
 return my_getter_with_context(self, "B");
   }

   /* etc. */
 


(Although it'd make my example more realistic if "context" were an int!)

So: you don't need it, it clutters up our code (particularly 
typeobject.c), and it adds overhead.  The only good reason to keep it is 
backwards compatibility, which I admit is a fine reason.


Whaddya think?  To be honest I'd be surprised if you guys went for 
this.  But I thought it was worth suggesting.



/larry/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Changing float.__format__

2009-05-04 Thread Eric Smith 
In issue 5920, Mark Dickinson raises an issue having to do with 
float.__format__ and how it handles the default format presentation type 
(that is, none of 'f', 'g', or 'e') versus how str() works on floats: 
http://bugs.python.org/issue5920


I agree with him that the current behavior is confusing and should be 
changed. I'm going to make this change, unless anyone objects. Please 
comment on the issue itself if you have any feedback.


Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

2009-05-04 Thread Mark Dickinson 
On Mon, May 4, 2009 at 10:10 AM, Larry Hastings  wrote:

> So: you don't need it, it clutters up our code (particularly typeobject.c),
> and it adds overhead.  The only good reason to keep it is backwards
> compatibility, which I admit is a fine reason.

Presumably whoever added the context field had a reason for doing so.
Does anyone remember what the intended use was?

Trawling through the history, all I could find was this comment,
attached to revision 23270: [Modified Thu Sep 20 21:45:26 2001
UTC (7 years, 7 months ago) by gvanrossum]

"""
Add optional docstrings to getset descriptors.  Fortunately, there's
no backwards compatibility to worry about, so I just pushed the
'closure' struct member to the back -- it's never used in the current
code base (I may eliminate it, but that's more work because the getter
and setter signatures would have to change.)
"""

Still, binary compatibility seems like a fairly strong reason not to
remove the closure field.

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] turtle.py update for 3.1

2009-05-04 Thread Gregor Lingl 

Hi,

Encouraged by a conversation with Martin at PyCon 2009
I've prepared a version 1.1b of the turtle module and I'd like to
get some advice or assistance to get it into the beta as explained
below. Thus I'd appreciate very much if also the release manager
would take notice of this posting.

python 2.0 had the version 1.0 and for now I'll give a terse
summary of the changes I did:

1. a few bugfixes, with 1 - 5 lines of code changed for each;
   these concern bugs that prevented turtle to run correctly

2. I've added four methods to the class TurtleScreeenBase:
   _onkeypress(fun, key)  (supplementing _onkeyrelease)
   mainloop()  (which is now a Screen-method and a function)
   textinput(title, prompt)
   numinput(title, prompt, default, minval, maxval)
  the latter two remedy the complete lack of input methods

   _onkey, an internal method name is changed to _onkeyrelease

3. I've added one method to the class TurtleScreen:
   onkeypress(fun, key=None) 
   implemented in analogy to the already present onkey()

   which got onkeyrelease as an alias.

4. I've changed several portions of the code that affect
  the representation of the turtleshape thus making it
  more compact (by removing some duplicated code) and more
  powerful, i. e. by adding the possibility to apply
  shearings to turtleshapes (in addition to the already present
  scaling and rotating transformations). Thus now the full
  range of (non singular) linear transformations is available.

  New methods in class RawTurtle:
   shearfactor(shear=None)set or get the shearfactor
   shapetransform(t11, t12, t21, t22)
   set or get the shape transform directly
   get_shapepoly() return the polygon of the current shape

  I've enhanced the functionality of tiltangle(angle=None)
  to contain also that of settiltangle and I propose to
  declare settiltangle as deprecated.
  
5. I've removed a lot of codelines that were commented out

  during the process of transferring the module from 2.6
  to 3.0

6. I've implemented the bugfix for http://bugs.python.org/issue4117
  according do my proposition there and I strongly
  recommend this change again, as the bug described is very
  annoying, the fix is easy and no one proposed a better
  solution.

7. I've tested the present version 1.1 extensivly. It runs
  all the demo scripts without problems and many others
  too (some of them significantly better than version 1.1).
  I'd like to add two additional scripts to the demo
  directory, one of them using new features so it only runs
  with this new version.

I've *not* touched the issue of the Screen singleton, so that
remains unchanged as it was as a result of Martins patch.

Thus, as a summary, this update does some bugfixes and eliminates
three deficiencies of the module: (1) accept keypress event,
(2) provide user input functions and (3) complement scaling
and rotating of turtleshapes by shearing, thus providing
the full range of linear transforms.

HOW TO PROCEED NOW?

(1) Submit the new version as a single file
(2) submit a unified diff containing all the changes
(3) Divide the changes into several chunks of
   related changes and submit the according diffs separately
   That would pose the problems, that there are lines
   in the code that are affected by several changes,
   e. g. those lines that define __all__
   And also: does the order of applying the patches matter?
   How do I have to account for this?
(4) Some other approach?

I'd appreciate to discuss open issues as needed and I'm
prepared to give more elaborate explanations and rationales
as wanted or as needed.

Docs for the changes are (to a large extent) contained in the
docstrings and I'm going to update the Documentation of the
turtle module (on the basis of theses docstrings) now.

Thanks in advance for your support

Gregor


 
  







 









___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PyPI copyright

2009-05-04 Thread Oleg Broytmann 
http://pypi.python.org/pypi

"Copyright © 1990-2007, Python Software Foundation"

   :s/2007/2009/

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[email protected]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] RFC: Threading-Aware Profiler for Python

2009-05-04 Thread Christian Schubert 
Hi,

Python ships with a profiler module which, unfortunately, is almost useless in 
a multi-threaded environment. *

I've created an alternative profiler module which queries per-thread CPU usage 
via netlink/taskstats, which limits the applicability to Linux (which shouldn't 
be much of an issue, profiling is usually not done by end users). It implements 
two modes: a "sampling" (does CPU time accounting based on stack fraames 100 
times per second, by default) and a "deterministic" profiler (does CPU time 
accounting on each function call/return, based on sys.profiler interface). The 
deterministic profiler is currently implemented in pure python (except for 
taskstats interface) and much slower than the sampling profiler.

Usage (don't forget make to build the c module):
python
>> from Profiler import *
>> def f(): do_something()
>> sampling_profiler(f)
or
>> deterministic_profiler(f)


Output is currently in the form of annotated source code (xyz.py.html, in the 
same directory where xyz.py resides). Before the *_profiler function returns, 
it iterates over all code objects it encountered and annotates the source files 
with 2 columns in front:
- 1st column: real time
- 2nd column: CPU time

numbers are log2(time_in_ns), colors are green-to-yellow for below-average and 
yellow-to-red for above-average metrics (relative to the average metric for all 
lines of the code object with a metric > 0).

Is there common need for such a module? 

Is it possible to have this included in the standard cPython distribution?

Which functional changes (besides a modification of the annotation output which 
shouldn't spread its result all over the FS) would be required to get this 
included?

Which non-functional changes would be required to get this included?


Please direct traffic regarding this subject to 
[email protected] (no I'm not subscribed to python-dev).


SF project page:

https://sourceforge.net/projects/pyprof/


git repository:

git://pyprof.git.sourceforge.net/gitroot/pyprof


Regards,
Christian


*) to be more exact there are at least three profiler modules: profile, 
cProfile, and hotshot, while I did only try (and failed) to use profile in a 
multi-threaded environment (by manually setting threading.profile to the 
profiling function), glancing at the source, I'm pretty sure that cProfile 
behaves similarly; I didn't test the hotshot module, but it does some other 
trade-offs (space-for-time), so I think that "pyprof" still adds some value


signature.asc
Description: This is a digitally signed message part.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RFC: Threading-Aware Profiler for Python

2009-05-04 Thread Aahz 
On Mon, May 04, 2009, Christian Schubert wrote:
>
> Python ships with a profiler module which, unfortunately, is almost
> useless in a multi-threaded environment. *
>
> I've created an alternative profiler module which queries per-thread
> CPU usage via netlink/taskstats, which limits the applicability to
> Linux (which shouldn't be much of an issue, profiling is usually
> not done by end users). It implements two modes: a "sampling" (does
> CPU time accounting based on stack fraames 100 times per second, by
> default) and a "deterministic" profiler (does CPU time accounting
> on each function call/return, based on sys.profiler interface). The
> deterministic profiler is currently implemented in pure python (except
> for taskstats interface) and much slower than the sampling profiler.

If you want to discuss this, please subscribe to python-ideas and repost
your message.  Generally speaking, in order to include modules like this,
they need to prove themselves over time and may require PEP approval.  If
you choose to move the discussion to python-ideas, it would help if you
mention known uses of your module.
-- 
Aahz ([email protected])   <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RFC: Threading-Aware Profiler for Python

2009-05-04 Thread Robert Brewer 
Christian Schubert wrote:
 > I've created an alternative profiler module which queries per-thread
 > CPU usage via netlink/taskstats, which limits the applicability to
 > Linux (which shouldn't be much of an issue, profiling is usually not
 > done by end users).

One of the uses for a profiling module is to compare runs on various 
platforms. And please, stop perpetuating the myth that only end-users 
use anything but Linux.


Robert Brewer
[email protected]



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RFC: Threading-Aware Profiler for Python

2009-05-04 Thread Bill Janssen 
Hi, Christian.

Christian Schubert  wrote:

> I've created an alternative profiler module which queries per-thread
> CPU usage via netlink/taskstats, which limits the applicability to
> Linux (which shouldn't be much of an issue, profiling is usually not
> done by end users).

A surprisingly large # of developers are running on OS X these days,
though.  I suggest make it work there, too.

Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

2009-05-04 Thread Larry Hastings 


Mark Dickinson wrote:

Still, binary compatibility seems like a fairly strong reason not to
remove the closure field.


My understanding is that there a) 2.x extension modules are not binary 
compatible with 3.x, and b) there are essentially no 3.x extension 
modules in the field.  Is that accurate?  If we don't have an installed 
base (yet) to worry about, now's the time to make this change.



/larry/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

2009-05-04 Thread Amaury Forgeot d'Arc 
Hi,

Larry Hastings wrote:
>
> Mark Dickinson wrote:
>>
>> Still, binary compatibility seems like a fairly strong reason not to
>> remove the closure field.
>
> My understanding is that there a) 2.x extension modules are not binary
> compatible with 3.x, and b) there are essentially no 3.x extension modules
> in the field.  Is that accurate?  If we don't have an installed base (yet)
> to worry about, now's the time to make this change.

cx_Oracle at least uses this closure field, and has already been ported to 3.x:
http://www.google.com/codesearch?q=Connection_SetOCIAttr+trunk

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

2009-05-04 Thread Larry Hastings 

Amaury Forgeot d'Arc wrote:

Larry Hastings wrote:
  

My understanding is that there a) 2.x extension modules are not binary
compatible with 3.x, and b) there are essentially no 3.x extension modules
in the field.  Is that accurate?  If we don't have an installed base (yet)
to worry about, now's the time to make this change.


cx_Oracle at least uses this closure field, and has already been ported to 3.x:
http://www.google.com/codesearch?q=Connection_SetOCIAttr+trunk


And they're using it as a pointer, too!  Nice to see it not abused for once.

If it helps, I volunteer to port cx_Oracle to the new PyGetSetDef if my 
patch is accepted.  The resulting code would be backwards-compatible 
with Python 3.0, so it could be incorporated immediately.  Given the 
lack of interest in the proposal so far, this is an easy vow to make!



/larry/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

2009-05-04 Thread Daniel Stutzbach 
On Mon, May 4, 2009 at 4:10 AM, Larry Hastings  wrote:

> So: you don't need it, it clutters up our code (particularly typeobject.c),
> and it adds overhead.  The only good reason to keep it is backwards
> compatibility, which I admit is a fine reason.
>

If you make the change, will 3rd party code that relies on it fail in
unexpected ways, or will they just get a compile error?

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RFC: Threading-Aware Profiler for Python

2009-05-04 Thread Paul Moore 
2009/5/4 Bill Janssen :
> Hi, Christian.
>
> Christian Schubert  wrote:
>
>> I've created an alternative profiler module which queries per-thread
>> CPU usage via netlink/taskstats, which limits the applicability to
>> Linux (which shouldn't be much of an issue, profiling is usually not
>> done by end users).
>
> A surprisingly large # of developers are running on OS X these days,
> though.  I suggest make it work there, too.

And Windows. I doubt that the various Windows-specific modules
available were developed on Linux. And I wouldn't assume that all of
the platform-neutral modules are developed on Linux, or even that the
developers have access to Linux. (I know I don't, short of building a
brand new virtual machine...)

Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

2009-05-04 Thread Mark Dickinson 
On Mon, May 4, 2009 at 8:11 PM, Daniel Stutzbach
 wrote:
> If you make the change, will 3rd party code that relies on it fail in
> unexpected ways, or will they just get a compile error?

I *think* that third party code that's recompiled for 3.1 and that
doesn't use the closure field will either just work, or will produce an
easily-fixed compile error.  Larry, does this sound right?

But I guess the bigger issue is that extensions already compiled against 3.0
that use PyGetSetDef (even if they don't make use of the closure field)
won't work with 3.1 without a recompile:  they'll segfault, or otherwise behave
unpredictably.

If that's not considered a problem, then surely we ought to be getting rid of
tp_reserved?

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

2009-05-04 Thread Daniel Stutzbach 
On Mon, May 4, 2009 at 3:00 PM, Mark Dickinson  wrote:

> But I guess the bigger issue is that extensions already compiled against
> 3.0
> that use PyGetSetDef (even if they don't make use of the closure field)
> won't work with 3.1 without a recompile:  they'll segfault, or otherwise
> behave
> unpredictably.
>

I was under the impression that binary compatibility was only guaranteed
within a minor revision (e.g., 2.6.1 must run code compiled for 2.6.0, but
2.7.0 doesn't have to).  I've been wrong before, though.

Certainly the C extension module I maintain is sprinkled with #ifdef's so it
will compile under 2.5, 2.6, and 3.0. ;-)

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

2009-05-04 Thread Antoine Pitrou 
Mark Dickinson  gmail.com> writes:
> 
> I *think* that third party code that's recompiled for 3.1 and that
> doesn't use the closure field will either just work, or will produce an
> easily-fixed compile error.  Larry, does this sound right?

This doesn't sound right. The functions in the third party code will get
compiled with the wrong signature, so they can crash (or behave unexpectedly)
when called by Python.



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

2009-05-04 Thread Mark Dickinson 
On Mon, May 4, 2009 at 9:15 PM, Antoine Pitrou  wrote:
> Mark Dickinson  gmail.com> writes:
>>
>> I *think* that third party code that's recompiled for 3.1 and that
>> doesn't use the closure field will either just work, or will produce an
>> easily-fixed compile error.  Larry, does this sound right?
>
> This doesn't sound right. The functions in the third party code will get
> compiled with the wrong signature, so they can crash (or behave unexpectedly)
> when called by Python.

Yes, of course the signature of the getters and setters changes.  Please
ignore me. :-)

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

2009-05-04 Thread Larry Hastings 


Mark Dickinson wrote:

I *think* that third party code that's recompiled for 3.1 and that
doesn't use the closure field will either just work, or will produce an
easily-fixed compile error.  Larry, does this sound right?
  


Yep.


But I guess the bigger issue is that extensions already compiled against 3.0
that use PyGetSetDef (even if they don't make use of the closure field)
won't work with 3.1 without a recompile:  they'll segfault, or otherwise behave
unpredictably.
  


Well, I think they'd work if they didn't use the closure and they had 
only one entry in their array of PyGetSetDefs.  But more than one, and 
yes it would behave unpredictably.  Probably segfault.



If that's not considered a problem, then surely we ought to be getting rid of
tp_reserved?


In principle they are equivalent, but in practice removing tp_reserved 
is a much bigger change.  Removing the closure field would result in 
obvious compile errors, and plenty of folks wouldn't even experience 
those.  Removing tp_reserved would affect everybody, with inscrutable 
compiler errors.


Personally I'd be up for removing tp_reserved.  But I lack the caution 
regarding backwards compatibility that has served Python so well, so 
you're ill-advised to listen to me.



Daniel Stutzbach wrote:
I was under the impression that binary compatibility was only 
guaranteed within a minor revision (e.g., 2.6.1 must run code compiled 
for 2.6.0, but 2.7.0 doesn't have to).  I've been wrong before, though.


My understanding is that that's the explicit guarantee.  However Python 
has been well-served by being much more cautious than that, a policy 
with which I cannot find fault.


Certainly the C extension module I maintain is sprinkled with #ifdef's 
so it will compile under 2.5, 2.6, and 3.0. ;-)


Happily this is one change where you could maintain backwards 
compatibility without #ifdefs.  If you use the closure field, change 
your code to use stub functions and pass the closure data in yourself.



/larry/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] turtle.py update for 3.1

2009-05-04 Thread Gregory P. Smith 
On Mon, May 4, 2009 at 7:33 AM, Gregor Lingl  wrote:

> Hi,
>
> Encouraged by a conversation with Martin at PyCon 2009
> I've prepared a version 1.1b of the turtle module and I'd like to
> get some advice or assistance to get it into the beta as explained
> below. Thus I'd appreciate very much if also the release manager
> would take notice of this posting.
>
> python 2.0 had the version 1.0 and for now I'll give a terse
> summary of the changes I did:
>
> 1. a few bugfixes, with 1 - 5 lines of code changed for each;
>   these concern bugs that prevented turtle to run correctly
>
> 2. I've added four methods to the class TurtleScreeenBase:
>   _onkeypress(fun, key)  (supplementing _onkeyrelease)
>   mainloop()  (which is now a Screen-method and a function)
>   textinput(title, prompt)
>   numinput(title, prompt, default, minval, maxval)
>  the latter two remedy the complete lack of input methods
>
>   _onkey, an internal method name is changed to _onkeyrelease
>
> 3. I've added one method to the class TurtleScreen:
>   onkeypress(fun, key=None)   implemented in analogy to the already
> present onkey()
>   which got onkeyrelease as an alias.
>
> 4. I've changed several portions of the code that affect
>  the representation of the turtleshape thus making it
>  more compact (by removing some duplicated code) and more
>  powerful, i. e. by adding the possibility to apply
>  shearings to turtleshapes (in addition to the already present
>  scaling and rotating transformations). Thus now the full
>  range of (non singular) linear transformations is available.
>
>  New methods in class RawTurtle:
>   shearfactor(shear=None)set or get the shearfactor
>   shapetransform(t11, t12, t21, t22)
>   set or get the shape transform directly
>   get_shapepoly() return the polygon of the current shape
>
>  I've enhanced the functionality of tiltangle(angle=None)
>  to contain also that of settiltangle and I propose to
>  declare settiltangle as deprecated.
>  5. I've removed a lot of codelines that were commented out
>  during the process of transferring the module from 2.6
>  to 3.0
>
> 6. I've implemented the bugfix for http://bugs.python.org/issue4117
>  according do my proposition there and I strongly
>  recommend this change again, as the bug described is very
>  annoying, the fix is easy and no one proposed a better
>  solution.
>
> 7. I've tested the present version 1.1 extensivly. It runs
>  all the demo scripts without problems and many others
>  too (some of them significantly better than version 1.1).
>  I'd like to add two additional scripts to the demo
>  directory, one of them using new features so it only runs
>  with this new version.
>
> I've *not* touched the issue of the Screen singleton, so that
> remains unchanged as it was as a result of Martins patch.
>
> Thus, as a summary, this update does some bugfixes and eliminates
> three deficiencies of the module: (1) accept keypress event,
> (2) provide user input functions and (3) complement scaling
> and rotating of turtleshapes by shearing, thus providing
> the full range of linear transforms.
>
> HOW TO PROCEED NOW?
>
> (1) Submit the new version as a single file
> (2) submit a unified diff containing all the changes
> (3) Divide the changes into several chunks of
>   related changes and submit the according diffs separately
>   That would pose the problems, that there are lines
>   in the code that are affected by several changes,
>   e. g. those lines that define __all__
>   And also: does the order of applying the patches matter?
>   How do I have to account for this?
> (4) Some other approach?


I'm happy with option #1.  If you find it reasonable to break things into
mutliple changes, feel free to do it, but at this point the turtle module
hasn't had a much love in ages so a large update in one commit is not a
problem IMHO.


>
>
> I'd appreciate to discuss open issues as needed and I'm
> prepared to give more elaborate explanations and rationales
> as wanted or as needed.
>
> Docs for the changes are (to a large extent) contained in the
> docstrings and I'm going to update the Documentation of the
> turtle module (on the basis of theses docstrings) now.
>
> Thanks in advance for your support
>
> Gregor
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Building types programmatically (was: drop unnecessary "context" pointer from PyGetSetDef)

2009-05-04 Thread Greg Ewing 

Larry Hastings wrote:


Removing tp_reserved would affect everybody, with inscrutable 
compiler errors.


This would have to be considered in conjunction with the
proposed programmatic type-building API, I think.

I'd like to see a migration towards something like that,
BTW. Recently I had occasion to do some work on a Ruby
extension module, and I was struck by how much more
pleasant it was to be able to create a class and add a
few functions to it using calls, rather than having to
wrestle with a huge static struct declaration. While
I like the Python language better than Ruby, I think
Ruby's extension API is ahead in this particular area.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 383 and Tahoe [was: GUI libraries]

2009-05-04 Thread Zooko O'Whielacronx 
Thank you for sharing your extensive knowledge of these issues, SJT.

On Sun, May 3, 2009 at 3:32 AM, Stephen J. Turnbull  wrote:
> Zooko O'Whielacronx writes:
>
>  > However, it is moot because Tahoe is not a new system. It is
>  > currently at v1.4.1, has a strong policy of backwards-
>  > compatibility, and already has lots of data, lots of users, and
>  > programmers building on top of it.
>
> Cool!

Thanks!  Actually yes it is extremely cool that it really does this
encryption, erasure-encoding, capability-based access control, and
decentralized topology all in a fully functional, stable system.  If
you're interested in such stuff then you should definitely check it
out!

> Question: is there a way to negotiate versions, or better yet,
> features?

For the peer-to-peer protocol there is, but the persistent storage is
an inherently one-way communication.  A Tahoe client writes down
information, and at a later point a Tahoe client, possibly of a
different version, reads it.  There is no way for the original writer
to ask what versions or features the readers may eventually have.
But, the writer can write down optional information which will be
invisible to readers that don't know to look for it, but adding it
into the "metadata" dictionary.  For example:
http://testgrid.allmydata.org:3567/uri/URI%3ADIR2%3Adjrdkfawoqihigoett4g6auz6a%3Ajx5mplfpwexnoqff7y5e4zjus4lidm76dcuarpct7cckorh2dpgq/?t=json
renders the directory contents into json and results in this:

  "r\u00e9sum\u00e9.html": [
"filenode",
{
 "mutable": false,
 "verify_uri":
"URI:CHK-Verifier:63y4b5bziddi73jc6cmyngyqdq:5p7cxw7ofacblmctmjtgmhi6jq7g5wf77tx6befn2rjsfpedzkia:3:10:8328",
 "metadata": {
  "ctime": 1241365319.0695441,
  "mtime": 1241365319.0695441
 },
 "ro_uri": 
"URI:CHK:no2l46woyeri6xmhcrhhomgr5a:5p7cxw7ofacblmctmjtgmhi6jq7g5wf77tx6befn2rjsfpedzkia:3:10:8328",
 "size": 8328
}
   ],

A new version of Tahoe writing entries like this is constrained to
making the primary key (the filename) be a valid unicode string (if it
wants older Tahoe clients to be able to read the directory at all).
However, it is not constrained about what new keys it may add to the
"metadata" dict, which is where we propose to add the "failed_decode"
flag and the "original_bytes".

> Well, it's a high-dimensional problem.  Keeping track of all the
> variables is hard.

Well put.

>  That's why something like PEP 383 can be important
> to you even though it's only a partial solution; it eliminates one
> variable.

Would that it were so!  The possibility that PEP 383 could help me or
other like me is why I am trying so hard to explain what kind of help
I need.  :-)


>  > Suppose you have run "tahoe cp -r myfiles/ tahoe:" on a Linux
>  > system and then you inspect the files in the Tahoe filesystem,
>  > such as by examining the web interface [1] or by running
>  > "tahoe ls", either of which you could do either from the same
>  > machine where you ran "tahoe cp" or from a different machine
>  > (which could be using any operating system). We have the
>  > following requirements about what ends up in your Tahoe directory
>  > after that cp -r.
>
> Whoa! Slow down!  Where's "my" "Tahoe directory"?  Do you mean the
> directory listing?  A copy to whatever system I'm on?  The bytes that
> the Tahoe host has just loaded into a network card buffer to tell me
> about it?  The bytes on disk at the Tahoe host?  You'll find it a lot
> easier to explain things if you adopt a precise, consistent
> terminology.

Okay here's some more detail.

There exists a Tahoe directory, the bytes of which are encrypted,
erasure-coded, and spread out over multiple Tahoe servers.  (To the
servers it is utterly opaque, since it is encrypted with a symmetric
encryption key that they don't have.)  A Tahoe client has the
decryption key and it recovers the cleartext bytes.  (Note: the
internal storage format is not the json encoding shown above -- it is
a custom format -- the json format above is what is produced to be
exported through the API, and it serves as a useful example for e-mail
discussions.)  Then for each bytestring childname in the directory it
decodes it with utf-8 to get the unicode childname.

Does that all make sense?

>  > Requirement 1 (unicode):  Each filename that you see needs to be valid
>  > unicode
>
> What does "see" mean?  In directory listings?

Yes, either with "tahoe ls", with a FUSE plugin, wht the web UI.
Remove the trailing "?t=json" from the URL above to see an example.

>  Under what
> circumstances, if any, can what I see be different from what I get?

This a good question!  In the previous iteration of the Tahoe design,
you could sometimes get something from "tahoe cp" which is different
from what you saw with "tahoe ls".  In the current design --
http://allmydata.org/trac/tahoe/ticket/534#comment:66 , this is no
longer the case, because we abandon the requirement to have
"round-trip fidelity of bytes".

>  > Requireme

[Python-Dev] Undocumented change / bug in Python3's PyMapping_Check

2009-05-04 Thread John Millikin 
In Python 2, PyMapping_Check will return 0 for list objects. In Python
3, it returns 1. Obviously, this makes it rather difficult to
differentiate between mappings and other sized iterables. In addition,
it differs from the behavior of the ``collections.Mapping`` ABC --
isinstance([], collections.Mapping) returns False.

I believe the new behavior is erroneous, but would like to confirm
that before filing a bug.

The behavior can be seen from a C extension, or if you're lazy, using ctypes:

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.CDLL('libpython2.6.so').PyMapping_Check(ctypes.py_object([]))
0

Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.CDLL('libpython3.0.so').PyMapping_Check(ctypes.py_object([]))
1
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com