[Python-Dev] Deprecated Cookie classes in Py3k
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stabilizing the C API of 2.6 and 3.0
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. How can it be that we allow major C API changes such as the renaming of the PyString APIs to go into the trunk without discussion or a PEP ? We're having lengthy discussions about the addition of single method to an object, but such major changes just go in like that and nobody seems to really care. Puzzled, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 28 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, Lithuania39 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 On 2008-05-27 12:10, M.-A. Lemburg wrote: 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. Wouldn't it be possible to have a 2to3.py converter take the 2.x code (including the C code), convert it and then apply any changes to the 3.x branch ? This wouldn't be merging in the classical sense, it would be automated forward porting. I find the approach less confusing than your suggestion and my initial idea. I disagree on that. Renaming old APIs to use the new names by adding a header file with #define oldname newname is standard practice. Renaming the old APIs in the source code and undoing the renaming with a header file is not. The internal API names are consistent for Python 2.6 and 3.0. The byte string C API is prefixed PyBytes and the unicode C API is prefixed PyUnicode. A core developer has just to remember that 'str' is a byte string in 2.x but an unicode object in 3.0. So you've solved part of the problem for 3.x by moving the naming mixup back to 2.x. Extension developers don't have to worry at all. The ABI and external API is mostly the same and still exposes the 'str' functions as PyString. Well, yes, but only due to a preprocessor hack that turns the names used in bytesobject.c back into names you'd normally look for in stringobject.c. And all this, just because Subversion can't handle merging of symbol renaming. You'd have to add an aliase bytes - str to the builtins to at least reduce the confusion a bit. Python 2.6 already has an alias bytes - str Yes, but please let's first discuss this some more. I don't think that the timing was right you started this thread just yesterday and the patches are already checked in. I'm sorry if I was too hasty for you. I got +1 from a couple of developers and it's basically Guido's suggestion. Please discuss any changes of the 2.x code base on python-dev. Such major changes do need more discussion and possibly a PEP as well. Thanks, ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterable String Redux (aka String ABC)
Armin Ronacher wrote: Basically *the* problematic situation with iterable strings is something like a `flatten` function that flattens out every iterable object except of strings. To flesh out the span of your something like, recently I had a WSGI-based app that to some request mistakenly returned a 200K string instead of the same wrapped as a 1-element list; and the WSGI layer -according to spec- served it back character by character. Which worked - and durably confused not only me but IIS and a network router as well. While blame can certainly be assigned elsewhere - WSGI spec or implementation (wsgiref included) - unwelcome iterability of strings was a necessary cause. Cheers, BB ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is type_modified() in typeobject.c not a public function?
Stefan Behnel schrieb: Straight forward patch is attached (against 3.0a5). Works for me in Cython. I thought about a name like Taint(t) or ClearTypeCache(t), but then went with the coward solution of calling the function PyType_Modified() as it was (almost) named internally. BTW, I noticed that the code in typeobject.c uses DECREF before set two times, like this: method_cache[h].version = type-tp_version_tag; method_cache[h].value = res; /* borrowed */ Py_INCREF(name); Py_DECREF(method_cache[h].name); method_cache[h].name = name; During the call to Py_DECREF, the cache content is incorrect, so can't this run into the same problem that Py_CLEAR() aims to solve? I attached a patch for that, too, just in case. Please create two tickets in the bug tracker and append the patches. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterable String Redux (aka String ABC)
On 27/05/2008, Raymond Hettinger [EMAIL PROTECTED] wrote: Conceptually, this is a fine idea, but three things bug me. First, there is a mismatch between the significance of the problem being addressed versus the weight of the solution. Agreed, absolutely. Second, this seems like the wrong solution to the problem as it places the responsibility in the wrong place and thereby hardwires its notion of what kind of objects should be split. Again, agreed. The flatten function is one of the canonical examples of the visitor patterns. I see no generalisation of this proposal to other visitor patterns. I'd rather see a solution which addressed the wider visitor use case (I think I just sprained my back bending over backwards to avoid mentioning generic functions :-)) Third, I thought ABCs were introduced as an optional feature [...] Again, I agree absolutely. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On 28/05/2008, M.-A. Lemburg [EMAIL PROTECTED] 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 care, but I struggle to understand the implications and/or what is being proposed in many cases. Recent examples are the ABC backports and the current thread (string C API). I simply don't follow the issues well enough to comment. How can it be that we allow major C API changes such as the renaming of the PyString APIs to go into the trunk without discussion or a PEP ? Christian has raised this a couple of times, but there has been little discussion. I suspect that this is because there is not enough clarity over the practical consequences. A PEP may help here, but I'm not sure how much - it could spark discussion, but would anyone actually end up any better informed? We're having lengthy discussions about the addition of single method to an object, but such major changes just go in like that and nobody seems to really care. I suspect deadline pressure and burnout are involved here. In all honesty, there's been little or no work done on the C API, which is just as much in need of review and possible cleanup for 3.0 as the language. It's as close as makes no difference to too late now - does that mean we've lost the chance? Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On 2008-05-28 14:29, Paul Moore wrote: On 28/05/2008, M.-A. Lemburg [EMAIL PROTECTED] 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 care, but I struggle to understand the implications and/or what is being proposed in many cases. Thanks, so I'm not the only :-) Recent examples are the ABC backports and the current thread (string C API). I simply don't follow the issues well enough to comment. How can it be that we allow major C API changes such as the renaming of the PyString APIs to go into the trunk without discussion or a PEP ? Christian has raised this a couple of times, but there has been little discussion. I suspect that this is because there is not enough clarity over the practical consequences. A PEP may help here, but I'm not sure how much - it could spark discussion, but would anyone actually end up any better informed? Probably, yes. The reason is that if you have a PEP, more people are likely to review it and make comments. If you start a discussion with a general subject line which then results in lots of little sub-threads, important aspects of the discussion are likely to go unnoticed in the noise. We're having lengthy discussions about the addition of single method to an object, but such major changes just go in like that and nobody seems to really care. I suspect deadline pressure and burnout are involved here. In all honesty, there's been little or no work done on the C API, which is just as much in need of review and possible cleanup for 3.0 as the language. It's as close as makes no difference to too late now - does that mean we've lost the chance? Perhaps, but the C API is certainly not used by as many people as the Python front-end and changes to the C API also have much deeper consequences due the API being written in C rather than Python. Overall, I don't think there's a lot to cleanup in the C API. Perhaps remove a few of those '...Ex()' APIs that were introduced to extend the original APIs and maybe remove or free up a few type slots that are no longer needed, but that's about it. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 28 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, Lithuania39 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyString - PyBytes C API renaming (Stabilizing the C API of 2.6 and 3.0)
On 2008-05-28 14:02, Christian Heimes wrote: M.-A. Lemburg schrieb: 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. We don't have better tools at our hands. I don't think we'll get any tools in time or chance the VCS right before a major release. Wouldn't it be possible to have a 2to3.py converter take the 2.x code (including the C code), convert it and then apply any changes to the 3.x branch ? Such a converter would be nice for 3rd party code but it's not an option for the core. In the past few months I've merged a lot of code from trunk to py3k. A 2to3 C converter doesn't help with merge conflicts. Naming differences make any merge more painful I was suggesting to not use SVN to merge changes directly, but to instead use an intermediate step in the process: Init: 1. grab the latest trunk 2. apply a 2to3 converter to the Python code and the C code, applying any renaming that may be necessary 3. save this converted version in a separate branch merge-branch Update: 1. checkout the merge-branch, . grab the latest trunk and 3.x branch 2. apply a 2to3 converter to the Python code and the C code, applying any renaming that may be necessary 3. copy the files over your working copy of the merge-branch 4. create a diff on the merge-branch 5. apply the diffs to 3.x branch, resolving any conflicts as necessary This doesn't require new tools (except for some C renaming support in the 2to3 tool). It only changes the procedure. We'd basically follow our own suggestions w/r to porting to 3.x, which is to make changes in the 2.x code, apply 2to3 and then apply remaining fixes there. I'm suggesting this, since 3.x is likely to introduce more Python stdlib and C API changes. The process would likely also makes a lot of other changes more easily manageable and reduce the overall merge conflicts. I find the approach less confusing than your suggestion and my initial idea. I disagree on that. Renaming old APIs to use the new names by adding a header file with #define oldname newname is standard practice. Renaming the old APIs in the source code and undoing the renaming with a header file is not. I wasn't talking about standard practice here. I talked about less confusion for core developers. My approach doesn't split our internal API in two. No, but it does apply a well hidden renaming which will cause confusion when using a debugger to trace calls in C code. If you use PyBytes APIs, you expect to find PyBytes functions in the libs and also set breakpoints on these. With the renaming we don't have two sets of APIs (old and new) exposed in the lib, like what we normally do when applying changes to API names. And by the way it *is* a standard approach fore Python. Guido told me that the same approach was used during the 1.x to 2.0 migration. There was no API change between 1.6 and 2.0. You are probably talking about the great renaming between 1.4 and 1.5. That was different, since it changes almost all C APIs in Python. And it used the standard practice... from rename2.h in Python 1.5: /* This file contains a bunch of #defines that make it possible to use old style names (e.g. object) with the new style Python source distribution. */ #define True Py_True #define False Py_False #define None Py_None ie. #define oldname newname And all this, just because Subversion can't handle merging of symbol renaming. As I said earlier we don't have better tools at our disposal. We have to make some compromises. Sometimes practicality beat purity. See above. Please discuss any changes of the 2.x code base on python-dev. Such major changes do need more discussion and possibly a PEP as well. In the last few months I started at least three topics about the C API renaming. It's in the thread 2.6 and 3.0 tasks http://permalink.gmane.org/gmane.comp.python.devel/93016 Thanks. I stopped reading that thread after Guido's reply in http://comments.gmane.org/gmane.comp.python.devel/92541 It would really help if subject lines were more specific. This thread also uses a much to general subject line (which is why I changed it). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 28 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, Lithuania39 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
Re: [Python-Dev] [Python-3000] PyString - PyBytes C API renaming (Stabilizing the C API of 2.6 and 3.0)
M.-A. Lemburg wrote: You are probably talking about the great renaming between 1.4 and 1.5. That was different, since it changes almost all C APIs in Python. And it used the standard practice... from rename2.h in Python 1.5: /* This file contains a bunch of #defines that make it possible to use old style names (e.g. object) with the new style Python source distribution. */ #define True Py_True #define False Py_False #define None Py_None ie. #define oldname newname This is what I expected to see in stringobject.h, along with some code in stringobject.c to allow the linker to see the old names *as well as* the new names. At the moment, all the code appears to be using the new names, but stringobject.h implicitly converts the new names back to the old names - so trying to use ctypes to retrieve the PyBytes_* functions from the Python DLL will fail. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecated Cookie classes in Py3k
techtonik schrieb: 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/Py3kDeprecated is actually a TODO) 3. Manual reference should contain information about all historical API changes It was most likely an oversight on my part. I've now removed the classes from the 3000 module. Thanks, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecated Cookie classes in Py3k
On Wed, May 28, 2008 at 6:57 PM, Georg Brandl [EMAIL PROTECTED] wrote: It was most likely an oversight on my part. I've now removed the classes from the 3000 module. Nice! =) If you're up to fixing the docs, could you, please, also review the fresh issue about this module. http://bugs.python.org/issue2988 Browsers allow to create invalid (non RFC) cookies rather easily and they crash python web scripts on the same domain, because developers usually not aware of this problem to catch the exception. There is a test case and several proposals for workarounds in Cookie (http.cookies) module. -- --anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 371 Discussion (pyProcessing Module)
Georg kindly published the PEP I submitted last night to the PEP site: http://www.python.org/dev/peps/pep-0371/ This PEP includes some of the previous discussion on the processing module's inclusion, and I hope clears up/clarifies some of the goals/non goals and issues. I also included benchmark data and a link to the code used for said benchmarks. I would like to renew the discussion now that there is a PEP to see if there are any outstanding things people would like to get resolved. I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback both here and elsewhere that people would rather see this in sooner in some form, rather than later (i.e.: 2.7/3.1). -Jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
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. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On Wed, May 28, 2008 at 10:08 AM, Bill Janssen [EMAIL PROTECTED] 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On Wed, May 28, 2008 at 3:12 AM, M.-A. Lemburg [EMAIL PROTECTED] 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. How can it be that we allow major C API changes such as the renaming of the PyString APIs to go into the trunk without discussion or a PEP ? I do not consider it a C API change. The API and ABI have not changed. Old code still compiles. Old binaries still dynamically load and work fine. (I just confirmed this by importing a couple python2.4 .so files into my non-debug build of 2.6 trunk) A of the PyString APIs are the real implementations in 2.x and are still there. We only switched to using their PyBytes equivalent names within the Python trunk code base. Are you objecting to our own code switching to use a different name even though the actual underlying API and ABI haven't changed? I suppose to people reading the code and going against old reference books it could be confusing but they've got to get used to the new names somehow and sometime. I strongly support changes like this one that makes the life of porting C code forwards and backwards between 2.x and 3.x easier without breaking compatibility with earlier 2.x version because that is going to be a serious pain for all of us otherwise. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterable String Redux (aka String ABC)
I'm not against this, but so far I've not been able to come up with a good set of methods to endow the String ABC with. If we stay minimalistic we could consider that the three basic operations that define a string are: - testing for substring containment - splitting on a substring into a list of substrings - slicing in order to extract a substring Which gives us ['__contains__', 'split', '__getitem__'], and expands intuitively to ['__contains__', 'find', 'index', 'split', 'rsplit', '__getitem__']. With the Sequence ABC, you already get index, contains, __len__, count, __iter__, and __getitem__. What's the benefit of an additional ABC with just three more methods? What can be learned from any known use cases for abstract strings (iirc, idlelib has an interesting example of subclassing UserString). Is there anything about this proposal that is intrinsically texty? In the 3.0 world, text is an abstract sequence of code points. Would you want to require an encode() method so there will always be a way to make it concrete? The split()/rsplit() methods have a complex specification. Including them may make it hard to write a compliant class. From what's been discussed so far, I don't see any advantage of isinstance(o, String) over hasattr(o, 'encode') or somesuch. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterable String Redux (aka String ABC)
I'm not against this, but so far I've not been able to come up with a good set of methods to endow the String ABC with. If we stay minimalistic we could consider that the three basic operations that define a string are: - testing for substring containment - splitting on a substring into a list of substrings - slicing in order to extract a substring Which gives us ['__contains__', 'split', '__getitem__'], and expands intuitively to ['__contains__', 'find', 'index', 'split', 'rsplit', '__getitem__']. With the Sequence ABC, you already get index, contains, __len__, count, __iter__, and __getitem__. What's the benefit of an additional ABC with just three more methods? What can be learned from any known use cases for abstract strings (iirc, idlelib has an interesting example of subclassing UserString). Is there anything about this proposal that is intrinsically texty? In the 3.0 world, text is an abstract sequence of code points. Would you want to require an encode() method so there will always be a way to make it concrete? I would. The split()/rsplit() methods have a complex specification. Including them may make it hard to write a compliant class. From what's been discussed so far, I don't see any advantage of isinstance(o, String) over hasattr(o, 'encode') or somesuch. Look, even if there were *no* additional methods, it's worth adding the base class, just to differentiate the class from the Sequence, as a marker, so that those of us who want to ask isinstance(o, String) can do so. Personally, I'd add in all the string methods to that class, in all their gory complexity. Those who need a compliant class should subclass the String base class, and override/add what they need. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterable String Redux (aka String ABC)
On 28-May-08, at 2:33 PM, Bill Janssen wrote: From what's been discussed so far, I don't see any advantage of isinstance(o, String) over hasattr(o, 'encode') or somesuch. Look, even if there were *no* additional methods, it's worth adding the base class, just to differentiate the class from the Sequence, as a marker, so that those of us who want to ask isinstance(o, String) can do so. Personally, I'd add in all the string methods to that class, in all their gory complexity. Those who need a compliant class should subclass the String base class, and override/add what they need. I'm not sure I agree with you on the solution, but I definitely agree that although str/unicode are conceptually sequences of characters, it is rarely useful to think of them as iterables of objects, unlike all other Sequences. (Note: I don't dispute that it is occasionally useful to treat them as such.) In my perfect world, strings would be indicable and sliceable, but not iterable. A character iterator could be obtained using a new method, such as .chars(). s = 'hello world' list(s) # exception set(s) # exception tuple(s) # exception for char in s: # exception [ord(c) for c in s] # exception s[2] # ok s[::-1] # ok for char in s.chars(): # ok [ord(c) for c in s.chars()] # ok Though an argument could be made against this, I consider the current behaviour of strings one of the few instances where purity beats practicality in python. It is often the cause of errors that fail too late in my experience. -Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A thought on generic functions
Paul Moore wrote: I'd rather see a solution which addressed the wider visitor use case (I think I just sprained my back bending over backwards to avoid mentioning generic functions :-)) Speaking of generic functions, while thinking about the recent discussion on proxy objects, it occurred to me that this is something you can do with an OO system that you can't do so easily with a generic function system. If the operations being proxied were generic functions rather than methods, you'd have to override them all individually instead of having a central point to catch them all. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterable String Redux (aka String ABC)
Bill Janssen wrote: Look, even if there were *no* additional methods, it's worth adding the base class, just to differentiate the class from the Sequence, as a marker, so that those of us who want to ask isinstance(o, String) can do so. Doesn't isinstance(x, basestring) already cover that? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterable String Redux (aka String ABC)
Mike Klaas wrote: In my perfect world, strings would be indicable and sliceable, but not iterable. An object that was indexable but not iterable would be a very strange thing. If it has __len__ and __getitem__, there's nothing to stop you iterating over it by hand anyway, so disallowing __iter__ would just seem perverse. A case could be made for strings being sliceable but neither indexable nor iterable, but it's probably too late to make such a radical change now. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterable String Redux (aka String ABC)
On 28-May-08, at 5:44 PM, Greg Ewing wrote: Mike Klaas wrote: In my perfect world, strings would be indicable and sliceable, but not iterable. An object that was indexable but not iterable would be a very strange thing. If it has __len__ and __getitem__, there's nothing to stop you iterating over it by hand anyway, so disallowing __iter__ would just seem perverse. Python has a beautiful abstraction in iteration: iter() is a generic function that allows you lazily consume a sequence of objects, whether it be lists, tuples, custom iterators, generators, or what have you. It is trivial to write your code to be agnostic to the type of iterable passed-in. Almost anything else a consumer of your code passes in will result in an immediate exception. Unfortunately, python has two extremely common data types which do not fail when this generic function is applied to them, and instead almost always returns a result which is not desired. Instead, it iterates over the characters of the string, a behaviour which is rarely needed in practice due to the wealth of methods available. I agree that it would be perverse to disallowing iterating over a string. I just wish that the way to do that wasn't glommed on to the object-iteration abstraction. As it stands, any consumer of iterables has to keep strings in mind. It is particularly irksome when the target input is an iterable of strings. I recall a function that accepts a list/iterable of item keys, hashes them, and then retrieves values based on the item hashes (usually over the network, so it is necessary to batch requests). This function is often used in the interactive interpreter, and it is thus very prone to being passed-in a string rather than a list. There was no good way to prevent the (frequent) mysterious not found errors save adding an explicit type check for basestring. String already behaves slightly differently from the way other sequences act: It is the only sequence for which 'seq in seq' is true, and the only sequence for which 'x in seq' can be true but 'any(x==item for item in seq)' is false. Abstractions are sometimes imperfect: this is why there is an explicit typecheck for strings in the sum() builtin. I'll stop here as I realize that the likelihood that this will be accepted is terribly small, especially considering the late stage of the process. But I would be willing to develop a patch that implements this behaviour on the off chance it is. -Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Finishing up PEP 3108
The issues related to PEP 3108 now total 14. With the beta (supposedly) in a week, I am hoping the last minor details can be pulled together or decisions made on what can be postponed and what should definitely be considered a release blocker. Issue 2847 - the aifc module still imports the cl module in 3.0. Problem is that the cl module is gone. =) So it seems silly to have the imports lying about. This can probably be changed to critical. Issue 2848 - mimetools has been deprecated for a while, but it is still used in a bunch of places. Since this has been deprecated in PEP 4 for a long time, should we add the removal warning in 2.6 now and then make its actual removal of usage something to do by another beta? Issue 2849 - rfc822 is the same problem as mimetools. Issue 2854 - gestalt needs to be added back into 3.0. This is Benjamin's issue. =) Issue 2873 - htmllib is slated to go, but pydoc still uses it. Then again, pydoc is busted thanks to the new doc format. Issue 2874 - the stat module is not so useful anymore, but it still has functions that are useful. Currently the value returned by os.stat() is a named tuple, but that won't support methods. So the object returned by os.stat() needs to probably become a proper object in posix. Issue 2876 - The UserDict module has been removed in 3.0, but two classes were moved and renamed in collections and another was removed. The removal is a 3.0 warning, but the class renaming might be a tricky 2to3 fixer (not sure if the fix_imports fixer can be tweaked to handle this). Issue 2877 - UserString.UserString moved. Just need to apply the patch. Issue 2878 - Ditto for UserList. Issue 2885 - Creation of the urllib package. Jeremy has been working on this. I believe his patch is up on rietveld. Issue 2917 - This is merging pickle and cPickle. Alexandre's thing. Issue 2918 - Same for StringIO/cStringIO. Issue 2919 - profile and cProfile needs to be merged. This has not been dealt with yet. Would it be reasonable to deprecate importing cProfile directly in 2.6 with the assumption the merge will work out for 3.0? So that is everything that's left. Issue 2775 is the tracking issue so you can look there to see what issues are still open and need work. I was hoping to spend Monday and Tuesday trying to tie up as many loose ends as possible, but the conference paper I have been working on that was due Sunday is now due a week later, and so Monday and Tuesday will be spent on that (supervisor's orders). Plus I am flying out Wednesday for 10 days to help my mother move and I don't know when I will get Net again. In other words, I still need help. =) -Brett P.S.: A huge thanks goes to everyone who has helped so far. My life has been nothing but stress for a while now and you guys have helped keep the stress from reaching epic proportions. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
