Python-Dev May 2008

python-dev@python.org

140 participants
133 discussions

http://bugs.python.org/issue708007 - telnetpopen

by Luke Kenneth Casson Leighton

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.

12 years, 7 months

Re: [Python-Dev] [Python-3000] PyString -> PyBytes C API renaming

by Nick Coghlan

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

12 years, 7 months

Re: [Python-Dev] Stabilizing the C API of 2.6 and 3.0

by Christian Heimes

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

12 years, 7 months

Re: [Python-Dev] PyString -> PyBytes C API renaming

by Christian Heimes

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

12 years, 7 months

Why is type_modified() in typeobject.c not a public function?

by Stefan Behnel

[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

12 years, 7 months

Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0

by Brett Cannon

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

12 years, 7 months

Deprecated Cookie classes in Py3k

by techtonik

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.

12 years, 7 months

Issue 643841: Including a new-style proxy base class in 2.6/3.0

by Nick Coghlan

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

12 years, 7 months

Re: [Python-Dev] Iterable String Redux (aka String ABC)

by Raymond Hettinger

> 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.

12 years, 7 months

Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0

by M.-A. Lemburg

On 2008-05-27 12:56, Thomas Heller wrote: > M.-A. Lemburg schrieb: >> On 2008-05-26 23:34, Christian Heimes wrote: >>> M.-A. Lemburg schrieb: >>>> Isn't that an awefuly confusing approach ? >>>> >>>> Wouldn't it be better to keep PyString APIs and definitions in >>>> stringobject.c|h and only add a new bytesobject.h header file >>>> that #defines the PyBytes APIs in terms of PyString APIs ? That >>>> maintains backwards compatibility and allows Python internals to >>>> use the new API names. >>>> >>>> With your approach, you've basically backported the confusing >>>> notion in Py3k that str() maps PyUnicode, only that in Py2 str() >>>> will now map to PyBytes. >>> The last time I brought up the topic, I had a lengthy discussion >>> with Guido. At first I wanted to rename the API in Python 3.0 only. >>> Guido argued that it's going to cause too much merge conflicts. He >>> then suggested the approach I implemented today. >> That's the same argument that came up in the module renaming >> discussion. >> >> I have a feeling that we should be looking for better merge tools, >> rather than implement code changes that cause more trouble than do >> good, just because our existing tools aren't smart enough. > > There are applications out there that dynamically import the python dll > and link to the exported functions by name; they will all break. The exported APIs still use the old names. Just the source code versions of the APIs change to the new names and they now live in different files as well. > I believe in the past we have been more carefull with changes like these. > Even when python api functions were turned into cpp macros, we provided > exported functions for them; for a few examples see the function definitions > near line 1778 in file Python/pythonrun.c . IMO, we should keep using that strategy for Python 2.x. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 27 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2008-07-07: EuroPython 2008, Vilnius, Lithuania 40 days to go :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611

12 years, 7 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev May 2008