Mailman 3 May 2001 - Python-Dev

"data".decode(encoding) ?!
by M.-A. Lemburg 07 May '01

07 May '01

We already have "data".encode(encoding) which encodes the string data by passing it through the encoder of the given encoding. Wouldn't it be worthwhile to add direct access to codec decoders through string methods as well ? (Note that this addition only makes sense for string objects, since Unicode cannot be decoded.) Also, would there be any objections adding some more standard codecs to the system ? I'm thinking of wrapping the binascii module APIs in form of codecs... -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

4 10

Moving MacPython to sourceforge
by Martin von Loewis 07 May '01

07 May '01

> There's two ways I can go about this: start a new MacPython project > or merge the MacPython stuff into the main Python CVS repository. There is actually a third option: Use the Python SF project, but create a new module in the Python CVS repository (so no merging would be done). I don't know how much code this is. I'd favour merging the Mac code into the core distribution. If there are loads of Mac-specific modules that not every MacPython user needs, it might be advisable to create a distutils package that contains the extra modules. Such a package should still live in cvs.python.sourceforge.net:/cvsroot/python. Just my 0.02EUR, Martin

2 1

Re: [Python-Dev] Added a machine-dependent file to the core
by Jack Jansen 07 May '01

07 May '01

> Jack Jansen wrote: > > To my surprise I noticed that the whole configure/Makefile.pre.in/setup setup > > of Python does not allow for an easy addition of a platform-dependent > > sourcefile to the core interpreter (or am I missing something?). > [...] > > > > Is it OK if I add a MACHDEP_OBJS to PYTHON_OBJS? > > How would this work? Would MACHDEP_OBJS be set by an autoconf > subsitution? Yes, that's what I had in mind (haven't written the code yet). Similar to the way DYNLOADFILE is set, but empty for all platforms except for OSX. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Added a machine-dependent file to the core
by Jack Jansen 07 May '01

07 May '01

To my surprise I noticed that the whole configure/Makefile.pre.in/setup setup of Python does not allow for an easy addition of a platform-dependent sourcefile to the core interpreter (or am I missing something?). This is a bit of functionality I need to port the various Mac modules to MacOSX-python. The platform depende sourcefile has various glue routines for turning MacOS error codes into exceptions and that sort of stuff. Is it OK if I add a MACHDEP_OBJS to PYTHON_OBJS? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

2 1

Need a search path for modules in setup.py
by Jack Jansen 07 May '01

07 May '01

(Don't worry, this is the last in my flurry of OSX related messages:-) Life would be a lot simpler for me if setup.py (the one for the main extension modules) would have a search path for module sourcefiles. As Mac modules currently live in Python/Mac/Modules (as opposed to Python/Modules) not having a search path measn I get ugly "../Mac/Modules/foomodule.c" constructs. I have the code for setup.py ready, is it OK if I check it in? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

1 0

multiple inheritance -- what I meant
by Paul F. Dubois 05 May '01

05 May '01

When I suggested a modification to the inheritance clause, class X (Y rename a as b, c as d, Z rename foo as bar): someone suggested this was the same as class X (Y, Z): b = Y.a d = Y.c bar = Z.foo I meant two things by my suggestion: 1. I meant that Y.a would never be found when searching for X.a. In particular, if Z.a exists, and a is not explicity defined in X, X.a is Z.a. 2. More philosophically, rather than being a consequence of the language like the second method is, the proposed syntax is intended to be a clear message to someone reading the class about how the inherited names are being handled. Compare the effort required of a reader to understand these two. (If you think the second one is easier, you probably attended Spam III.) If you can rename in this way there are no problems with multiple inheritance. To be complete you should probably also allow Y undefine x, ... which simply makes Y.x unavailable from X.

1 0

PySequence_Contains
by Guido van Rossum 05 May '01

05 May '01

In a checkin message, Tim wrote: > The full story for instance objects is pretty much unexplainable, because > instance_contains() tries its own flavor of iteration-based containment > testing first, and PySequence_Contains doesn't get a chance at it unless > instance_contains() blows up. A consequence is that > some_complex_number in some_instance > dies with a TypeError unless some_instance.__class__ defines __iter__ but > does not define __getitem__. This kind of thing happens everywhere -- instances always define all slots but using the slots sometimes fails when the corresponding __foo__ doesn't exist. Decisions based on the presence or absence of a slot are therefore in general not reliable; the only exception is the decision to *call* the slot or not. The correct solution is not to catch AttributeError and pretend that the slot didn't exist (which would mask an AttributeError occurring inside the __contains__ method if there was one), but to reimplement the default behavior in the instance slot implementation. In this case, that means that PySequence_Contains() can be simplified (no need to test for AttributeError), and instance_contains() should fall back to a loop over iter(self) rather than trying to use instance_item(). --Guido van Rossum (home page: http://www.python.org/~guido/)

2 5

"".tokenize() ?
by M.-A. Lemburg 05 May '01

05 May '01

Gustavo Niemeyer submitted a patch which adds a tokenize like method to strings and Unicode: "one, two and three".tokenize([",", "and"]) -> ["one", " two ", "three"] I like this method -- should I review the code and then check it in ? PS: Haven't gotten any response regarding the .decode() method yet... should I take this as "no objections" ? -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

5 8

::
by Paul Prescod 04 May '01

04 May '01

I'll throw out a partially formed thought in case it is useful to anybody. "::" might be useful to solve another problem I've been struggling with: how to have multiple package distributions share a namespace (xml::dom::minidom, xml::dom::4dom, xml::dom::corbadom). "::" might mean, in general, that you are walking through abstract, potentially merged namespaces and not through concrete dictionary implementations. I think that Python's using the same syntax for package namespaces and attribute accesses might seem more elegant than it is in practice. Things that "seem like" they should work do not because packages are fundamentally different than attributes: >>> from xml import dom.minidom File "<stdin>", line 1 from xml import dom.minidom ^ SyntaxError: invalid syntax Why isn't this symmetric? I would like to use "." on either side of the import >>> import xml >>> print xml.dom Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'xml' module has no attribute 'dom' >>> from xml.dom import minidom >>> print xml.dom <module 'xml.dom' from 'c:\program files\python21\lib\xml\dom\__init__.pyc'> I find it a little bit weird that importing one module has the side effect of populating a package. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook

2 1

Change to PyIter_Next()?
by Tim Peters 04 May '01

04 May '01

In spare moments, I've been plugging away at making various functions work nice with iterators (map, min, max, etc). Over and over this requires writing code of the form: op2 = PyIter_Next(it); if (op2 == NULL) { /* StopIteration is *implied* by a NULL return from * PyIter_Next() if PyErr_Occurred() is false. */ if (PyErr_Occurred()) { if (PyErr_ExceptionMatches(PyExc_StopIteration)) PyErr_Clear(); else goto Fail; } break; } This is wordy, obscure, and in my experience is needed every time I call PyIter_Next(). So I'd like to hide this in PyIter_Next instead, like so: /* Return next item. * If an error occurs, return NULL and set *error=1. * If the iteration terminated normally, return NULL and set *error=0. * Else return the next object and set *error=0. */ PyObject * PyIter_Next(PyObject *iter, int *error) { PyObject *result; if (!PyIter_Check(iter)) { PyErr_Format(PyExc_TypeError, "'%.100s' object is not an iterator", iter->ob_type->tp_name); *error = 1; return NULL; } result = (*iter->ob_type->tp_iternext)(iter); *error = 0; if (result) return result; if (PyErr_Occurred()) { if (PyErr_ExceptionMatches(PyExc_StopIteration)) PyErr_Clear(); else *error = 1; } /* Else StopIteration is implicit, and there is no error. */ return NULL; } Then *calls* could be the simpler: op2 = PyIter_Next(it, &error); if (op2 == NULL) { if {error) goto Fail; break; } Objections? So far I'm almost the only user of PyIter_Next(); the only other use is in ceval's FOR_ITER, which goes thru a similar dance. However, I'm not clear on why FOR_ITER doesn't clear the exception if PyErr_Occurred() and PyErr_ExceptionMatches(PyExc_StopIteration) are both true -- that sure smells like a bug (but, if so, the change above would squash it by magic). Note that I'm not proposing to change the signature of the tp_iternext slot similarly. PyIter_Next() is a (IMO appropriately) higher-level function.

2 2