I've just put together a binary distribution of 2.3a2 for OS/2 EMX, and
for the hell of it compared the pystone ratings of 2.3a2 against 2.2.2
on 2 different systems.
2.2.2 2.3a2 change
system 1 18200 21700 +19.2%
system 2a 5600 6975 +24.5%
system 2b 6600 8540 +29.4%
(Pystone on 2.2.2 adjusted to 50000 loops, average of 3 runs)
system 1: Athlon 1.4GHz, 512MB (PC133), OS/2 v4.0 FP12, gcc 2.8.1 -O2
system 2a: Via C3 800MHz, 256MB (PC133), OS/2 v4.0 FP15, gcc 2.8.1 -O2
system 2b: " , " , FreeBSD 4.7, gcc 2.95.4 -g -O3
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac(a)bullseye.apana.org.au | Snail: PO Box 370
andymac(a)pcug.org.au | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
In trying to support user requests for C++-like behavior of wrapped
static data members, I noticed the following little assymetry:
>>> #define a property class
... class Prop(object):
... def __get__(self, obj, type=None):
... print '__get__', (self, obj, type)
... return 'value'
... def __set__(self, obj, type=None):
... print '__set__', (self, obj, type)
... def __delete__(self, obj, type=None):
... print '__delete__', (self, obj, type)
>>> # use it in a class Y
... class Y(object):
... x = Prop()
>>> a = Y()
>>> a.x # all accesses to a.x are intercepted
__get__ (<__main__.Prop object at 0x00877BC8>, <__main__.Y object at 0x00878108>, <class '__main__.Y'>)
>>> a.x = 42
__set__ (<__main__.Prop object at 0x00877BC8>, <__main__.Y object at 0x00878108>, 42)
>>> Y.x # Prop intercepts reads of the class attribute
__get__ (<__main__.Prop object at 0x00877BC8>, None, <class '__main__.Y'>)
>>> Y.x = 1 # But not assignments
>>> class mc(object.__class__): # to intercept Y.x assignment
... x = Prop() # I have to define this
>>> class Y(object):
... __metaclass__ = mc
>>> Y.x # now all accesses to Y.x are intercepted
__get__ (<__main__.Prop object at 0x00876AB8>, <class '__main__.Y'>, <class '__main__.mc'>)
>>> Y.x = 1
__set__ (<__main__.Prop object at 0x00876AB8>, <class '__main__.Y'>, 1)
>>> a = Y() # But not accesses to a.x
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'Y' object has no attribute 'x'
As you can see, the only way to intercept assignment to Y.x is to
stick a property Y's class, i.e. the metaclass (or to modify
__setattr__ in the metaclass, but it amounts to the same thing).
In C++, a mutable static data member can be modified via the class
Y::x = 1;
or an instance of the class
a.x = 1;
I notice that Python supports this sort of dual access for reading
attributes and calling static functions, but getting that behavior for
mutable attributes seems unreasonably difficult: I need a property in
the metaclass *and* in the class.
1. To throw out a straw-man suggestion, what about adding an
additional protocol __set2__ which, if found, will be called
instead of __set__ both for reading _and_ writing attributes on the
2. What are the optional type=None arguments for? It seems as though
only the middle argument (obj) is ever None. I just copied this
protocol out of descrintro.html
3. Is there documentation for __delete__ anywhere?
I notice with some despair that regular expression bugs and patches in
SF don't get fixed. Assigning these to effbot seems a black hole. Is
there someone who would like to take up maintenance of the SRE code?
--Guido van Rossum (home page: http://www.python.org/~guido/)
(This may be off-topic, but only slightly IMO.)
I'm looking for one, two, or three experienced Python developers
on Windows to participate in an exciting open-source project.
As some people on this list might know, the ctypes project
http://starship.python.net/crew/theller/ctypes.html has had a good
In short, ctypes is an improved calldll replacement. The longer
description is that it lets you in pure Python build, access, and
manipulate simple, but also very complicated C data types (structures,
unions, pointers, function pointers, callback functions) and use them
to call functions in shared libraries/dlls. It currently runs on
Windows, Linux, and MacOS X, the latter two with the help of the
Not only allows it to call, for example, win32 functions not (yet)
exposed by Mark Hammond's win32all stuff, I think it is powerful
enough to create bindings in pure Python to whole systems or
frameworks. (That's the reason I think this post is not totally
off-topic for this forum).
Using ctypes is sometimes like programming C in a Python syntax, this
may sound strange, but it's where I as a Python and C hacker feel
quite at home ;-), just that I don't need the compiler any more...
I would now like to create a COM framework. ctypes makes it easy to
access COM vtables, and also easy to build them at runtime. Different
from Mark's pythoncom, it would concentrate more on custom interfaces
than on IDispatch - just what is needed if you have to interface to
clients and servers implemented in ATL.
My ultimate goal would be to be able to write ActiveX controls in pure
Python, and write containers for AX controls in pure Python.
So far, I have written proof-of-concept code with fairly good
typelibrary/typeinfo support for both the client side and the server
side. I have local and inproc servers running, can send and receive
events via the connection point mechanism, can automatically create
type libraries for COM interfaces written in Python, can decompile
type libraries and generate Python source code wrappers for them, so
that it's easy to use these interfaces in Python, and so on. All for
simple cases only, though.
As things usually go, I'm not happy with this code, although I've
learned a lot, and started the first rewrite. The rewritten code is
in the ctypes CVS repository, in a sandbox subdirectory.
Supporting open-source projects is a large goal, and I'm quite sure I
cannot do it for the ctypes COM stuff alone. So currently I have to
decide whether this stays at the level of 'ctypes sample code', or if
it will evolve into a useful addition to the Python toolkit on
Windows, but, I need some help.
Thanks for the attention,
I've implemented a 'k' format code for getargs.c, and uploaded a patch
for it http://www.python.org/sf/595026.
This code accepts integers or longs, does no range checking, and
returns the lower bits in an unsigned long.
Is this also the fix for the hex constant issue which has been
discussed here before? Are extension writers supposed to replace 'i'
with 'k' in the PyArg_Parse calls in their extensions now?
Then, I'm not sure how to proceed.
Sure, a 'K' format code, which returns a LONG_LONG will also be needed,
and I can implement that.
Are the other changes proposed in the SF item (changes to the 'B',
'H', 'I' codes) needed?
Do I have to add code somewhere to test these format codes or the
Py.._From..Mask functions, probably in testcapi.c?
There are already 2 bug reports with the build failing because the
iconv module raises a RuntimeError. A patch to setup.py is below.
The patch corrects the problem, but should anything else be done?
The problem is that iconv builds ok, but the iconv_open fails so
the module initialization failed, IIRC.
RCS file: /cvsroot/python/python/dist/src/setup.py,v
retrieving revision 1.146
diff -w -u -r1.146 setup.py
--- setup.py 18 Feb 2003 10:24:34 -0000 1.146
+++ setup.py 20 Feb 2003 23:09:35 -0000
@@ -207,7 +207,7 @@
- except ImportError, why:
+ except (ImportError, RuntimeError), why:
self.announce('*** WARNING: renaming "%s" since importing it'
I've been trying for some time to build Python-2.2.x with
thread support for SCO Open Server 5.0.5, with no luck.
I'm using the FSU pthreads-3.9 library included in Skunkware.
Any ideas on what should be done??
Is there thread support for this platform.
Thanks in advance
Democracy is two wolves and a sheep voting on what to have for dinner.
Liberty is two wolves attempting to have a sheep for dinner and
finding a well-informed, well-armed sheep.
Centro de Datos
Raymond Hettinger writes:
> After Neal's changes to PyArg_ParseTuple, will Tim still
> be able to use a floating argument to the wink() function
> which has only been documented to accept a boolean state?
Yes, but I want to know what happens when I try this:
-- Michael Chermside
I think it would be a good idea to release Python 2.2.3 soon -- say
within a few weeks. I plan this to be a low-key release: all it does
is add various important bugfixes, most of which were backported from
2.3. This is in tune with the Python-in-a-Tie idea for Python 2.2
(any idea what happened to the PBF plans for that?).
If you have or know of something that you think should go into 2.2.3
but isn't in CVS yet, please let me know. The best way is to simply
make the changes in CVS to the release22-maint branch. Do this only
for things that are clearly bugfixes that introduce no backwards
incompatibilities. When in doubt, use the second-best way. The
second-best way is to (re)open a SF patch and assign it to me.
--Guido van Rossum (home page: http://www.python.org/~guido/)