Mailman 3 May 2008 - Python-Dev

FWD: 26 Python-Dev moderator request(s) waiting
by Aahz 30 May '08

30 May '08

I just processed two weeks of backlog on python-dev (I'm only a backup moderator). Would anyone object to changing the list policy so that non-member posts get discarded instead of held? -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ Need a book? Use your library!

5 7

http://bugs.python.org/issue708007 - telnetpopen
by Luke Kenneth Casson Leighton 30 May '08

30 May '08

my apologies, i found the issue "closed" after doing a search for my own work, requiring (again) the telnetlib code for yet another project. since 2001, the work done has been reimplemented time and time again, by different individuals, in different projects, in different ways, all solving exactly the same issues, providing exactly the same type of functionality, as that provided by TelnetPopen3. e.g. Pexpect is the one i found today, listed off of http://en.wikipedia.org/wiki/Expect l.

2 1

Re: [Python-Dev] [Python-3000] PyString -> PyBytes C API renaming
by Nick Coghlan 29 May '08

29 May '08

Stefan Behnel wrote: > M.-A. Lemburg wrote: >> If you use PyBytes APIs, you expect to find PyBytes functions in >> the libs and also set breakpoints on these. > > AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem here. The PyBytes_* functions appear to be there, but a preprocessor macro means it is actually the PyString_* functions that appear in the Python DLL. That's great from a backwards compatibility point of view, but seriously confusing from the point of view of anyone trying to embed or otherwise debug Python 2.6. > Besides, how likely is it that users set a breakpoint on the PyBytes/PyString > functions? Not very likely at all - but it would still be nice if the PyBytes_* symbols were visible to the linker as well as the preprocessor. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

3 3

Re: [Python-Dev] Stabilizing the C API of 2.6 and 3.0
by Christian Heimes 29 May '08

29 May '08

Stefan Behnel schrieb: > Christian Heimes wrote: >> * add a new file stringobject.h which contains the aliases PyString_ -> >> PyBytes_ > > Just a quick note that that file is still missing from SVN, so it's kind of > hard to compile existing code against the current branch state... No, the file is in SVN. It's just not in the py3k branch because it's not vital to the core. I had plans to add a Python 2.x compatibility header to Python 3.0 But I'm not going to spend any more time on the topic or any other development until we have reached an agreement on the naming. I don't want to waste more of my free time in vain. Christian

2 1

Re: [Python-Dev] PyString -> PyBytes C API renaming
by Christian Heimes 29 May '08

29 May '08

Stefan Behnel schrieb: > M.-A. Lemburg wrote: >> If you use PyBytes APIs, you expect to find PyBytes functions in >> the libs and also set breakpoints on these. > > AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem here. In Python 2.6 the PyBytes_* functions are only available to the compiler but not to the linker. In 2.6 the ABI functions are PyString_* and in 3.0 it's PyBytes_* Christian

1 0

Why is type_modified() in typeobject.c not a public function?
by Stefan Behnel 29 May '08

29 May '08

[reposting this to python-dev, as it affects both 2.6 and 3.0] Hi, when we build extension classes in Cython, we have to first build the type to make it available to user code, and then update the type's tp_dict while we run the class body code (PyObject_SetAttr() does not work here). In Py2.6+, this requires invalidating the method cache after each attribute change, which Python does internally using the type_modified() function. Could this function get a public interface? I do not think Cython is the only case where C code wants to modify a type after its creation, and copying the code over seems like a hack to me. Stefan

4 6

Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
by Brett Cannon 28 May '08

28 May '08

On Wed, May 28, 2008 at 10:08 AM, Bill Janssen <janssen(a)parc.com> wrote: >> I'm beginning to wonder whether I'm the only one who cares about >> the Python 2.x branch not getting cluttered up with artifacts caused >> by a broken forward merge strategy. > > I share your concern. Seems to me that perhaps (not sure, but > perhaps) the rush to back-port from 3.x, and the concern about > minimizing pain of moving from 2.x to 3.x, has become the tail wagging > the dog. > Speaking for myself, I know that if fixing something in 2.x means a pain in forward-porting, I will just do it in 3.x and leave it someone else to back-port to 2.x which will lower the chances of the back-port ever occurring. I don't want to do this, but I am fighting damn hard against burn-out at this point and if I have to choose between complete burn-out and only working on the leading edge version of Python, I will choose the latter. So I for one appreciate Christian taking all of us into account in terms of the approach taken to make our lives easier when we work on Python. -Brett

1 0

Deprecated Cookie classes in Py3k
by techtonik 28 May '08

28 May '08

I've noticed that some classes in Cookies module (namely SerialCookie and SmartCookie) deprecated since 2.3 still present in Python3000 documentation. http://docs.python.org/dev/3.0/library/http.cookies.html Is it because ... ?: 1. Docs are not synchronized with API 2. Classes are not removed yet (http://wiki.python.org/moin/Py3kDeprecatedis actually a TODO) 3. Manual reference should contain information about all historical API changes -- --anatoly t.

2 2

Issue 643841: Including a new-style proxy base class in 2.6/3.0
by Nick Coghlan 28 May '08

28 May '08

One of the tasks where classic classes are currently far superior to new-style classes is in writing proxy classes like weakref.proxy - cases where nearly all operations need to be delegated to some other object, with only a few being handled via the proxy type object itself. With classic classes, this is trivial, since __getattr__ is always consulted, even for retrieval of special methods. With new-style classes, however, the __getattribute__ machinery can be bypassed, meaning the only way to proxy an arbitrary instance is to define all of the special methods that have C-level slots. This issue was actually first raised five and a half years ago [1], but has never been a particularly pressing problem, as anyone with any sense that needed to write a proxy object just used a classic class instead of a new-style one. In 3.0, with the demise of classic classes, that workaround goes away. So what do people think of including a ProxyBase implementation in 2.6 and 3.0 that explicitly delegates all of the C-level slots to a designated target instance? For some proxy class implementers, it would be possible to use this class as a base-class to get the special method delegation 'for free', and for others with more esoteric needs, it would at least provide a reference for which special methods needed to be provided explicitly by the proxy type. I attached a sample implementation to [1] which is essentially equivalent to weakref.proxy, but with a strong reference to the target, and written in Python rather than C. I expect the target audience for such a feature to be quite small, but without better support for it in the standard library, I also suspect it could prove to be a show-stopper for the affected developers as far as Py3k migration is concerned. Cheers, Nick. [1] http://bugs.python.org/issue643841 -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

5 16

Re: [Python-Dev] Iterable String Redux (aka String ABC)
by Raymond Hettinger 28 May '08

28 May '08

> Steven D'Aprano" <limeguin(a)pearwood.info> > If built-in objects grew an __atomic__ attribute, you could > simplify the atomic() function greatly: I may not have been clear enough in my previous post. Atomicity is not an intrinsic property of an object or class. How could you know in advance what various applications would want to consider atomic? The decision is application specific and best left to the caller of the flattener: def flatten(obj, predicate=None): if predicate is not None and predicate(obj): yield obj else: for item in obj: for i in flatten(item): yield i > However atomic() is defined, now flatten() is easy: Rule of thumb: if you find a need to change the language (adding a new builtin, adding a new protocol, and adding a property to every builtin and pure python container) just to implement a simple recipe, then it is the recipe that needs fixing, not the language. Raymond P.S. You're on the right track by factoring the decision away from the internals of flatten(); however, the atomic() predicate needs to be user definable for a given application not hardwired into the language itself.

1 0