Mailman 3 December 2000 - Python-Dev

What's up with PEP 209: Adding Multidimensional Arrays
by Paul Barrett 08 Dec '00

08 Dec '00

What is the status of PEP 209? I see David Ascher is the champion of this PEP, but nothing has been written up. Is the intention of this PEP to make the current Numeric a built-in feature of Python or to re-implement and replace the current Numeric module? The reason that I ask these questions is because I'm working on a prototype of a new N-dimensional Array module which I call Numeric 2. This new module will be much more extensible than the current Numeric. For example, new array types and universal functions can be loaded or imported on demand. We also intend to implement a record (or C-structure) type, because 1-D arrays or lists of records are a common data structure for storing photon events in astronomy and related fields. The current Numeric does not handle record types efficiently, particularly when the data type is not aligned and is in non-native endian format. To handle such data, temporary arrays must be created and alignment and byte-swapping done on them. Numeric 2 does such pre- and post-processing inside the inner-most loop which is more efficient in both time and memory. It also does type conversion at this level which is consistent with that proposed for PEP 208. Since many scientific users would like direct access to the array data via C pointers, we have investigated using the buffer object. We have not had much success with it, because of its implementation. I have scanned the python-dev mailing list for discussions of this issue and found that it now appears to be deprecated. My opinion on this is that a new _fundamental_ built-in type should be created for memory allocation with features and an interface similar to the _mmap_ object. I'll call this a _malloc_ object. This would allow Numeric 2 to use either object interchangeably depending on the circumstance. The _string_ type could also benefit from this new object by using a read-only version of it. Since its an object, it's memory area should be safe from inadvertent deletion. Because of these and other new features in Numeric 2, I have a keen interest in the status of PEPs 207, 208, 211, 225, and 228; and also in the proposed buffer object. I'm willing to implement this new _malloc_ object if members of the python-dev list are in agreement. Actually I see no alternative, given the current design of Numeric 2, since the Array class will initially be written completely in Python and will need a mutable memory buffer, while the _string_ type is meant to be a read-only object. All comments welcome. -- Paul -- Dr. Paul Barrett Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Group FAX: 410-338-4767 Baltimore, MD 21218

3 3

[development doc updates]
by Fred L. Drake 07 Dec '00

07 Dec '00

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Lots of small changes, but most important, more DOM documentation: http://python.sourceforge.net/devel-docs/lib/module-xml.dom.html

1 0

unit testing and Python regression test
by David Goodger 07 Dec '00

07 Dec '00

There is another unit testing implementation out there, OmPyUnit, available from: http://www.objectmentor.com/freeware/downloads.html -- David Goodger dgoodger(a)bigfoot.com Open-source projects: - The Go Tools Project: http://gotools.sourceforge.net - reStructuredText: http://structuredtext.sourceforge.net (soon!)

1 0

PEP 231, __findattr__()
by Martin v. Loewis 06 Dec '00

06 Dec '00

> Isn't there a way to accomplish the desired effect without modifying > the instance? In the context of __findattr__, *we* know that we > don't want to get a recursive call. Let's assume __getattr__ and > __setattr__ had yet another optional parameter: infindattr, > defaulting to 0. We would than have to pass a positive value in > this context, which would object.c tell to not try to invoke > __findattr__ again. Who is "we" here? The Python code implementing __findattr__? How would it pass a value to __setattr__? It doesn't call __setattr__, instead it has "self.__myfoo = x"... I agree that the current implementation is not thread-safe. To solve that, you'd need to associate with each instance not a single "infindattr" attribute, but a whole set of them - one per "thread of execution" (which would be a thread-id in most threading systems). Of course, that would need some cooperation from the any thread scheme (including uthreads), which would need to provide an identification for a "calling context". Regards, Martin

7 17

Re: [Python-Dev] A house upon the sand
by Michael Hudson 04 Dec '00

04 Dec '00

"Tim Peters" <tim.one(a)home.com> writes: > On the deprecation of the string module: where did this idea come from? > I've never seen anything saying that the string module is deprecated. I thought this, and went looking. I found on http://www.python.org/1.6/, about four fifths of the way down: Changed Modules string - most of this module is deprecated now that strings have methods. This no longer uses the built-in strop module, but takes advantage of the new string methods to provide transparent support for both Unicode and ordinary strings. I hope (and believe) this is Wrong. http://www.python.org/2.0/new-python.html says: The old string module is still around for backwards compatibility, but it mostly acts as a front-end to the new string methods. which is IMHO better. Cheers, M. -- Every day I send overnight packages filled with rabid weasels to people who use frames for no good reason. -- The Usenet Oracle, Oracularity #1017-1

12 32

unit testing and Python regression test
by Jeremy Hylton 04 Dec '00

04 Dec '00

There was recently some idle chatter in Guido's living room about using a unit testing framework (like PyUnit) for the Python regression test suite. We're also writing tests for some DC projects, and need to decide what framework to use. Does anyone have opinions on test frameworks? A quick web search turned up PyUnit (pyunit.sourceforge.net) and a script by Tres Seaver that allows implements xUnit-style unit tests. Are there other tools we should consider? Is anyone else interested in migrating the current test suite to a new framework? I hope the new framework will allow us to improve the test suite in a number of ways: - run an entire test suite to completion instead of stopping on the first failure - clearer reporting of what went wrong - better support for conditional tests, e.g. write a test for httplib that only runs if the network is up. This is tied into better error reporting, since the current test suite could only report that httplib succeeded or failed. Jeremy

8 13

PEP 231, __findattr__()
by barry＠digicool.com 04 Dec '00

04 Dec '00

I've just uploaded PEP 231, which describes a new hook in the instance access mechanism, called __findattr__() after a similar mechanism that exists in Jython (but is not exposed at the Python layer). You can do all kinds of interesting things with __findattr__(), including implement the __of__() protocol of ExtensionClass, and thus implicit and explicit acquisitions, in pure Python. You can also do Java Bean-like interfaces and C++-like access control. The PEP contains sample implementations of all of these, although the latter isn't as clean as I'd like, due to other restrictions in Python. My hope is that __findattr__() would eliminate most, if not all, the need for ExtensionClass, at least within the Zope and ZODB contexts. I haven't tried to implement Persistent using it though. Since it's a long PEP, I won't include it here. You can read about it at this URL http://python.sourceforge.net/peps/pep-0231.html It includes a link to the patch implementing this feature on SourceForge. Enjoy, -Barry

4 7

Re: CVS: python/dist/src/Lib urllib.py,1.107,1.108
by Martin v. Loewis 03 Dec '00

03 Dec '00

> You should make this: 'ascii' -- encoding names are lower case per > convention (and the implementation has a short-cut to speed up > conversion to 'ascii' -- not for 'ASCII'). With conventions, it is a difficult story. I'm pretty certain that users typically see that particular american standard as ASCII (to the extend of calling it "a s c two"), not ascii. As for speed - feel free to change the code if you think it matters. > + raise UnicodeError("URL "+repr(url)+" contains non-ASCII characters") > Would it be better to use a simple ValueError here ? (UnicodeError > is a subclass of ValueError, but the error doesn't really have > something to do with Unicode conversions...) Why does it not have to do with Unicode conversion? A conversion from Unicode to ASCII was attempted, and failed. I guess I would be more open to suggested changes if you had put them into the patch manager at the time you've reviewed the patch... Regards, Martin

2 1

Re: [Python-checkins] CVS: python/dist/src/Lib filecmp.py,1.6,1.7
by Christian Tismer 03 Dec '00

03 Dec '00

Moshe Zadka wrote: > > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv9465 > > Modified Files: > filecmp.py > Log Message: > Call of _cmp had wrong number of paramereters. > Fixed definition of _cmp. ... > ! return not abs(cmp(a, b, sh, st)) > except os.error: > return 2 Ugh! Wouldn't that be a fine chance to rename the cmp function in this module? Overriding a built-in is really not nice to have in a library. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com

2 2

Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.107,1.108
by M.-A. Lemburg 03 Dec '00

03 Dec '00

"Martin v. Löwis" wrote: > > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv30506 > > Modified Files: > urllib.py > Log Message: > Convert Unicode strings to byte strings before passing them into specific > protocols. Closes bug #119822. > > ... > + > + def toBytes(url): > + """toBytes(u"URL") --> 'URL'.""" > + # Most URL schemes require ASCII. If that changes, the conversion > + # can be relaxed > + if type(url) is types.UnicodeType: > + try: > + url = url.encode("ASCII") You should make this: 'ascii' -- encoding names are lower case per convention (and the implementation has a short-cut to speed up conversion to 'ascii' -- not for 'ASCII'). > + except UnicodeError: > + raise UnicodeError("URL "+repr(url)+" contains non-ASCII characters") Would it be better to use a simple ValueError here ? (UnicodeError is a subclass of ValueError, but the error doesn't really have something to do with Unicode conversions...) > + return url > > def unwrap(url): -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0