Hi, Skip Montanaro wrote:

I know this has been discussed before. In light of the recent PEP8 update:

Avoid the use of the string module; instead use string methods. These are always much faster and share the same API with unicode strings.

I thought I'd raise it again.

How about deprecating the string module?

I'm absolutely against depreceating the string module! Instead I suggest to change the cited wording from PEP8 into Avoid the use of the string module unless you want to keep compatibility with Python 1.5.2; instead use the string methods introduced in later releases of Python. These are always much faster and share the same API with unicode strings. Python 1.5.2 is still very important and even the latest Red Hat distributions still use it. Since the bytecode (.pyc) has changed inbetween, we decided to ship all our Python Software with 1.5.2 and backport useful new library modules from 2.x to 1.5.2 if we want to use them. Of course the edits needed to turn string method calls back into string module function calls for 1.5.2 are trivial but they are nevertheless tedious. Very often the overall performance win of using string methods will be so negligible, that I tend to believe that the CPU cycles saved due to this change don't sum up to the amount of programmer time wasted by editing Python software from string function calls into string method calls or vice versa. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen, Germany)

Peter Funk wrote:

Hi,

Skip Montanaro wrote:

...

I know this has been discussed before. In light of the recent PEP8 update:

Avoid the use of the string module; instead use string methods. These are always much faster and share the same API with unicode strings.

I thought I'd raise it again.

How about deprecating the string module?

I'm absolutely against depreceating the string module! Instead I suggest to change the cited wording from PEP8 into

Avoid the use of the string module unless you want to keep compatibility with Python 1.5.2; instead use the string methods introduced in later releases of Python. These are always much faster and share the same API with unicode strings.

Python 1.5.2 is still very important and even the latest Red Hat distributions still use it. Since the bytecode (.pyc) has changed inbetween, we decided to ship all our Python Software with 1.5.2 and backport useful new library modules from 2.x to 1.5.2 if we want to use them.

Of course the edits needed to turn string method calls back into string module function calls for 1.5.2 are trivial but they are nevertheless tedious. Very often the overall performance win of using string methods will be so negligible, that I tend to believe that the CPU cycles saved due to this change don't sum up to the amount of programmer time wasted by editing Python software from string function calls into string method calls or vice versa.

There's a good example of what I was talking about in the "Stability and Change" thread: careless use of deprecations would cause serious grief among developers and certainly also users (who are then confronted with tons of warnings which they don't understand). Now for Python modules the situation is a little better, since it is possible to wrap up those deprecated modules in a distutils package for users to install on top of their Python install. However, when touching core features of the language things become completely unmanageable. The reason is that various extensions out there start to rely on features which are only available in later releases while others are not migrated yet to these versions and would result in endless streams of deprecation warnings or even failures. As a result you'd lose the ability to fish in the sea of Python extensions... BTW, I don't see the tradeoff in saving 11k worth of diskspace for string.py compared to the good vibes we lose in the Python world for this. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/

>> How about deprecating the string module? Martin> I think one needs to offer the alternatives first, and deprecate Martin> the module then. So have alternatives for *everything* in string Martin> available in 2.3, deprecate it in 2.4, add a DeprecationWarning Martin> in 2.5. I don't see that as being a major problem. As I mentioned in my reply to Peter Funk, I believe you can probably let the deprecation schedule slip according to how important continued 1.5.2 compliance is determined to be down the road. That is, deprecate it no earlier than 2.4 and add a DeprecationWarning no sooner than one or two releases after that. The following string module functions don't seem to have equivalent string methods: zfill - only because string.zfill accepts non-string arguments, otherwise it is already available capwords - I believe it was explicitly decided to not implement this as a string method maketrans - shouldn't be too hard to rewrite in C as a method of str. Also, the data objects obviously have to be put somewhere. Before doing any of this, we need to decide where this stuff belongs. I doubt the technical effort involved will be too challenging. Skip

Skip Montanaro wrote:

mal> There's a good example of what I was talking about in the mal> "Stability and Change" thread: careless use of deprecations would mal> cause serious grief among developers and certainly also users (who mal> are then confronted with tons of warnings which they don't mal> understand).

I don't believe I said "let's carelessly deprecate the string module".

Looking at the subject line, you're almost there ;-)

mal> Now for Python modules the situation is a little better, since it mal> is possible to wrap up those deprecated modules in a distutils mal> package for users to install on top of their Python install.

I don't see why this can't be done for string.py.

Sure it can; don't see what we gain, though. Note that I was just addressing the more general case discussed in the other thread "Stability and change".

mal> BTW, I don't see the tradeoff in saving 11k worth of diskspace for mal> string.py compared to the good vibes we lose in the Python world mal> for this.

It has nothing to do with 11k worth of disk space and everything to do with "there's one (best) way to do it".

That's a silly phrase. I agree that there should always be a straight-forward and intuitive way to do things, but I don't go for such a dogma type argument and I'm sure you don't either :-) The intuitive way to do e.g. string.find has changed from import string string.find(x,y) to x.find(y) and that's worth making clear, but forcing the Python people to change their previously adapted intuition sounds too much like dictatorship to me. If I want to write code which works in all Python versions starting from 1.5.2 onwards, I should be able to do this. Deprecating important modules like string and types and then removing them altogether makes this impossible without extra hackery or providing special bwcompat packages to the users. Just look at the hoops which the email package has to go through to maintain such compatibility. That's not the old Python philosophy I'm used to and that's also why I dislike the idea to rip out code for no apparently needed reason at all. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/

Hi, Skip Montanaro:

mal> BTW, I don't see the tradeoff in saving 11k worth of diskspace for mal> string.py compared to the good vibes we lose in the Python world mal> for this.

It has nothing to do with 11k worth of disk space and everything to do with "there's one (best) way to do it".

In some situations application of zen-rule number 8 (this is "* Although practicality beats purity.") is stronger than zen-rule number 12 (this is "* There should be one-- and preferably only one --obvious way to do it."), which you cited somewhat sloppy above. In my opponion the string module is one such situation and another one is the '<>' operator. Most of my employees work with Modula-2 a lot and we have a huge code base. So they prefer to use '<>' over '!=' in Python also and they will not stop to do so, although the use of '<>' is discouraged in the Python documentation. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen, Germany)

Skip Montanaro wrote:

>> It has nothing to do with 11k worth of disk space and everything to >> do with "there's one (best) way to do it".

mal> That's a silly phrase. I agree that there should always be a mal> straight-forward and intuitive way to do things, but I don't go for mal> such a dogma type argument and I'm sure you don't either :-)

It's not dogma. It's a catch phrase, I agree, but I think the concept does have merit.

Sure it does, but not in the sense of "there's only one way to do it: mine" ;-)

mal> If I want to write code which works in all Python versions starting mal> from 1.5.2 onwards, I should be able to do this.

This seems like a good project for the Python Business Forum. How about developing some hard numbers that indicate what fraction of Python users use what version of Python? It would have to be sensitive to the type of users and their platform, but would be useful information for all Python programmers to have.

Indeed.

I am personally getting rather tired of the "you can't do that! it's not 1.5.2-compatible!" whine without any justification other than "RedHat still ships 1.5.2".

eGenix and most other companies providing Python extensions I know of still support Python 1.5.2. Many users still like 1.5.2 for its stability and better performance. For some statistics, I get around 4000 hits on Google for "Python 1.4" 52000 hits on Google for "Python 1.5" 31000 hits on Google for "Python 2.0" 44000 hits on Google for "Python 2.1" 36000 hits on Google for "Python 2.2" 2000 hits on Google for "Python 2.3" From this I take that the world has moved away from 1.4 but we're still far from saying Python 1.5.2 is dead. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/

...

...

...

...

"MAL" == M <mal@lemburg.com> writes:

MAL> Just look at the hoops which the email package has to go MAL> through to maintain such compatibility. That's not a great analogy though. email's got those compatibility modules largely because generators were such a natural fit for three of the methods. I wrote them in Py2.2 first to learn how to use generators and then had to figure out how to backport them. email only works with Python 2.1 and beyond, with a strong bias against the string module. All in all, I'm still not convinced that the compatibility modules are worth it, but for now, I'm sticking with them. They definitely cause pain with distutils. ;/ There's a price to be paid for living on the bleeding edge (or scabbed edge for Python 2.2 ;). But there's also a price to pay for maintaining backwards compatibility and sticking with that forever, More important (to me) than the feature or perceived stability of Py1.5.2, is that so much has been fixed by Python 2.1.3 that it made no sense to use anything earlier. I think/hope that the PBF's Pytie releases will help ease that pain. -Barry

...

If I want to write code which works in all Python versions starting from 1.5.2 onwards, I should be able to do this. Deprecating important modules like string and types and then removing them altogether makes this impossible without extra hackery or providing special bwcompat packages to the users.

I can understand this, but isn't "1.5.2" a little arbitrary.

have you tried migrating a huge python system from 1.5.2 to 2.x? if so, what did you learn? </F>

I'm absolutely against depreceating the string module!

Maybe we need a new concept, "silent deprecation"? We would do we could to discourage the use of modules (like types or string) in the documentation, maybe even removing their documentation altogether, but the interpreter would not issue a warning message. If done well, this could have approximately the same effect as a deprecation warning, but without the negative PR effects. Or maybe we could introduce a new warning category, SilentDeprecationWarning, which is normally ignored (like OverflowWarning already is). This could be turned on explicitly with a -W option so someone wanting to check that their code is future-proof would have an easy way to do so. I do not want to ignore all DeprecationWarning messages by default, as it would defeat the main purpose of the warning. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, May 29, 2002, Guido van Rossum wrote:

Or maybe we could introduce a new warning category, SilentDeprecationWarning, which is normally ignored (like OverflowWarning already is). This could be turned on explicitly with a -W option so someone wanting to check that their code is future-proof would have an easy way to do so.

I do not want to ignore all DeprecationWarning messages by default, as it would defeat the main purpose of the warning.

+1 -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "In the end, outside of spy agencies, people are far too trusting and willing to help." --Ira Winkler

...

...

...

...

"GvR" == Guido van Rossum <guido@python.org> writes:

GvR> Or maybe we could introduce a new warning category, GvR> SilentDeprecationWarning, which is normally ignored (like GvR> OverflowWarning already is). This could be turned on GvR> explicitly with a -W option so someone wanting to check that GvR> their code is future-proof would have an easy way to do so. +1 -Barry

From: "Guido van Rossum" <guido@python.org>

Maybe we need a new concept, "silent deprecation"? We would do we could to discourage the use of modules (like types or string) in the documentation, maybe even removing their documentation altogether, but the interpreter would not issue a warning message.

+100 Last month, I took the bait and went to comp.lang.py with a proposal to deprecate some builtins. I learned that every builtin (except for input()) has a lot of friends. With each set of flames, I mean comments, I modified my proposal until it evolved to "psuedo-deprecation". Amazingly, this attracted no flames at all. The net result is that psuedo-deprecation seems to be acceptable as way of removing cruft and lowering the sum total pool of working knowledge that a Python programmer has to keep in mind. Instead of de-documenting obsolete tools, I propose moving their documentation to a separate section of the docs set aside for cruft. This makes it possible to understand exactly what old code was doing. It makes sure that the newly dedocumented features don't take on never-documented assumptions. Putting it in a separate place allows us to document the rationale for psuedo-deprecation and to suggest alternatives. Collecting it in one place provides authors with a checklist of things to take out of their book updates. On the warning side of the equation, I have two ideas. While there would not be warnings kicking out automatically, we could add an option or tool that developers could use to temporarily flag use of psuedo-deprecated features. The second idea, is to move responsibility for obsolesence warnings to PyChecker. Raymond Hettinger

[Changed subject] [Raymond Hettinger]

Last month, I took the bait and went to comp.lang.py with a proposal to deprecate some builtins. I learned that every builtin (except for input()) has a lot of friends.

And input() has one important friend. :-)

With each set of flames, I mean comments, I modified my proposal until it evolved to "psuedo-deprecation". Amazingly, this attracted no flames at all. The net result is that psuedo-deprecation seems to be acceptable as way of removing cruft and lowering the sum total pool of working knowledge that a Python programmer has to keep in mind.

I guess this means that people don't mind us telling them which features are obsolete, but they hate it with a vengeance when their programs that they have deployed in the field with end users start spewing warning messages.

Instead of de-documenting obsolete tools, I propose moving their documentation to a separate section of the docs set aside for cruft. This makes it possible to understand exactly what old code was doing.

Hm, getting the docs for a previous version is easy enough. We never throw anything away.

It makes sure that the newly dedocumented features don't take on never-documented assumptions. Putting it in a separate place allows us to document the rationale for psuedo-deprecation and to suggest alternatives. Collecting it in one place provides authors with a checklist of things to take out of their book updates.

I think we can do two things. Either we can keep the docs for deprecated features but clearly mark the chapter or section with a deprecation note at the start, in bold. Or we can remove the docs for deprecated features, and add a chapter "deprecated features" which mentions each deprecated feature without describing it in detail, and provides information about what to use instead.

On the warning side of the equation, I have two ideas. While there would not be warnings kicking out automatically, we could add an option or tool that developers could use to temporarily flag use of psuedo-deprecated features.

This is what I meant by having a SilentDeprecationWarning category -- a special form of the -W option can cause it to spew messages, but by default it won't.

The second idea, is to move responsibility for obsolesence warnings to PyChecker.

This is not always feasible; some things can only be discovered at run-time (e.g. the oct/hex/<< warnings). --Guido van Rossum (home page: http://www.python.org/~guido/)

aahz> This is ridiculous. Perhaps you missed the smiley? Skip

Note: there's an patch available at http://python.org/sf/561928 Guido van Rossum wrote:

I think we can do two things. Either we can keep the docs for deprecated features but clearly mark the chapter or section with a deprecation note at the start, in bold.

Or we can remove the docs for deprecated features, and add a chapter "deprecated features" which mentions each deprecated feature without describing it in detail, and provides information about what to use instead.

Either of these approaches works for me.

...

The second idea, is to move responsibility for obsolesence warnings to PyChecker.

This is not always feasible; some things can only be discovered at run-time (e.g. the oct/hex/<< warnings).

Agreed. PyChecker will probably just be an early warning system. Especially since I'm more aggressive on my definition of 'deprecated.' :-) Neal

Note: there's an patch available at http://python.org/sf/561928

Thanks! I agree with the name change to PendingDeprecationWarning. Check it in before I change my mind! :-)

Guido van Rossum wrote:

...

I think we can do two things. Either we can keep the docs for deprecated features but clearly mark the chapter or section with a deprecation note at the start, in bold.

Or we can remove the docs for deprecated features, and add a chapter "deprecated features" which mentions each deprecated feature without describing it in detail, and provides information about what to use instead.

Either of these approaches works for me.

I personally like the second version better -- by not providing full documentation, it discourages new users more strongly from using deprecated features. --Guido van Rossum (home page: http://www.python.org/~guido/)

Sometimes I wish pychecker was integrated with the distro... But I'm sure there are good reasons for avoiding this.

Mostly that the PyChecker development cycle is several orders of magnitude faster than Python's, so at best you would have an out-of-date version of PyChecker in the distro. Once PyChecker slows down a bit, I'd be happy to incorporate it. --Guido van Rossum (home page: http://www.python.org/~guido/)

Title changed. Guido van Rossum wrote:

...

Sometimes I wish pychecker was integrated with the distro... But I'm sure there are good reasons for avoiding this.

Mostly that the PyChecker development cycle is several orders of magnitude faster than Python's, so at best you would have an out-of-date version of PyChecker in the distro. Once PyChecker slows down a bit, I'd be happy to incorporate it.

Pychecker development has slowed down a bit, but there are some other reasons to not include it just yet. There's several issues that are slowly converging. The new compiler which Jeremy did a bunch of work on is an important part. Ideally, pychecker would be implemented on top of the new compiler. This will make integration of pychecker easier and should also allow it to work with jython. There's also been work on using ASTs for pychecker, rather than byte codes. These are 2 important parts which are on-going. I've thought about returning to the compiler, but I'm also keen to clean up a lot of cruft. I think that's more important. Generally, I'd like to finish cleaning up the deprecation issues, which include: using PendingDeprecations, Py_DEPRECATED in C headers, and fixing the docs. I'm still thinking about optimizations too (remove SET_LINENO and others). And finally, the compiler and pychecker. (Also, generally improving test coverage is hrown in somewhere.) I'm hopeful that 2.4 may be a good time to get the compiler and pychecker into Python. But I suspect that pychecker will still be maintained separately for a while. Neal

What shall we Silently Deprecate?

string module

Yes, after providing substitutes.

types module (after providing substitutes)

Yes.

apply()

Yes.

oct() hex()

Why? I use these a lot... --Guido van Rossum (home page: http://www.python.org/~guido/)

From: "Guido van Rossum" <guido@python.org>

...

What shall we Silently Deprecate?

string module

Yes, after providing substitutes.

I commented on the substitutes patch, www.python.org/sf/561832, but thought it would be better to kick the idea around here on Py-dev. Instead of making direct substitutes for the character lists, I propose we take advantage of the opportunity and provide them as mappings rather than strings. That way, we can get O(1) behavior instead of O(n) behavior for code like: if c in str.printable: c='*'. If someone needs to know the contents, they can run str.printable.keys(). Also, because the dictionary is mutable, someone can (at runtime) expand or contract the definitions: str.whitespace.append('_'). Raymond Hettinger

[Alex Martelli]

I assume the duplication of oct and hex wrt '%o'% and '%x'% was the reason to suggest silently-deprecating the former (trying to have 'just one obvious way' and all that).

The same kind of reason says that `str()' and `repr()' could be faded out in favour of `%s' and `%r' specifiers. This is not likely to happen! :-) -- François Pinard http://www.iro.umontreal.ca/~pinard

Skip Montanaro wrote:

Still, it sounds to me like for most purposes there is ample reason to advocate not using the string module.

Sure. Move the documentation for the module into an appendix and add a note saying people should use string methods instead.

Then, my natural inclination is to wonder if it should simply be deprecated.

Removing it will break lots of code. Leaving it alone until Python 3k costs us almost nothing. Can we please just leave it alone? Neil

Removing it will break lots of code. Leaving it alone until Python 3k costs us almost nothing. Can we please just leave it alone?

That's exactly what the PendingDeprecationWarning is for. --Guido van Rossum (home page: http://www.python.org/~guido/)

Steven Lott wrote:

The numbering scheme should cover this need. After all, Wirth had a series of numbered versions for Modula (<empty>, 2, 3).

I think the individual modules may need explicit version numbering, also. I find 15 of 158 .py files in my release of the library have __version__ numbers.

IMO Enforcing version numbers in standard libraries is a good idea. Eventually, a good versioning scheme for the standard-lib with automated deprecation may be what is needed. Making the introduction of new (or deprecation of) features a) by hand b) by measures of 'x years', example from from PEP4: "The deprecation warning will be added to the module one year after Python 2.3 is released, and the module will be removed one year after that." seems unreliable. How do you construct an if-statement for 'One year after 2.3 is released' if the current version is 2.2 <wink>. Instead deprecating a) (semi-) automatically b) by saying '2.3 issues deprecation warning, 2.4 does not support it'. seems much saner. Even a program can be teached to check this. The more intransparent the versioning/deprecation scheme the harder it is to handle and the more people will scream at every deprecation-proposal. deprecated-4223-seconds-after-7th-reply'ly yours, holger

Guido van Rossum wrote:

Most of the constants already have a predicate companion:

whitespace -- isspace() lowercase -- islower() uppercase -- isupper() letters -- isalpha() digits -- isdigit()

That leaves:

hexdigits -- isxdigit() octdigits -- isodigit() punctuation -- ispunct() printable -- isprint()

Perhaps we should add isalnum, iscntrl, is graph, to match <ctype.h>? Or perhaps not? (Maybe I'd also like to add isword(), which would be isalnum() or '_' -- this is the definition of \w in the re module.)

FYI, Unicode has these: {"islower", (PyCFunction) unicode_islower, METH_NOARGS, islower__doc__}, {"isupper", (PyCFunction) unicode_isupper, METH_NOARGS, isupper__doc__}, {"istitle", (PyCFunction) unicode_istitle, METH_NOARGS, istitle__doc__}, {"isspace", (PyCFunction) unicode_isspace, METH_NOARGS, isspace__doc__}, {"isdecimal", (PyCFunction) unicode_isdecimal, METH_NOARGS, isdecimal__doc__}, {"isdigit", (PyCFunction) unicode_isdigit, METH_NOARGS, isdigit__doc__}, {"isnumeric", (PyCFunction) unicode_isnumeric, METH_NOARGS, isnumeric__doc__}, {"isalpha", (PyCFunction) unicode_isalpha, METH_NOARGS, isalpha__doc__}, {"isalnum", (PyCFunction) unicode_isalnum, METH_NOARGS, isalnum__doc__}, Note that unlike for ASCII strings, the characters all have defined categories. Strings miss a few of these: {"islower", (PyCFunction)string_islower, METH_NOARGS, islower__doc__}, {"isupper", (PyCFunction)string_isupper, METH_NOARGS, isupper__doc__}, {"isspace", (PyCFunction)string_isspace, METH_NOARGS, isspace__doc__}, {"isdigit", (PyCFunction)string_isdigit, METH_NOARGS, isdigit__doc__}, {"istitle", (PyCFunction)string_istitle, METH_NOARGS, istitle__doc__}, {"isalpha", (PyCFunction)string_isalpha, METH_NOARGS, isalpha__doc__}, {"isalnum", (PyCFunction)string_isalnum, METH_NOARGS, isalnum__doc__}, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/

On Wednesday 29 May 2002 07:28 pm, Raymond Hettinger wrote: ...

strings. That way, we can get O(1) behavior instead of O(n) behavior for code like: if c in str.printable: c='*'. If someone needs to know the contents, they can run str.printable.keys(). Also, because the dictionary is mutable, someone can (at runtime) expand or contract the definitions: str.whitespace.append('_').

append would of course not work on a dictionary, but the prospect of allowing easy mutation of fundamental built-ins is quite negative in Python -- goes against the grain of the language. A read-only dictionary might be OK. Alex

Guido van Rossum wrote:

...

FYI, Unicode has these:

{"islower", (PyCFunction) unicode_islower, METH_NOARGS, islower__doc__}, {"isupper", (PyCFunction) unicode_isupper, METH_NOARGS, isupper__doc__}, {"istitle", (PyCFunction) unicode_istitle, METH_NOARGS, istitle__doc__}, {"isspace", (PyCFunction) unicode_isspace, METH_NOARGS, isspace__doc__}, {"isdecimal", (PyCFunction) unicode_isdecimal, METH_NOARGS, isdecimal__doc__}, {"isdigit", (PyCFunction) unicode_isdigit, METH_NOARGS, isdigit__doc__}, {"isnumeric", (PyCFunction) unicode_isnumeric, METH_NOARGS, isnumeric__doc__}, {"isalpha", (PyCFunction) unicode_isalpha, METH_NOARGS, isalpha__doc__}, {"isalnum", (PyCFunction) unicode_isalnum, METH_NOARGS, isalnum__doc__},

Note that unlike for ASCII strings, the characters all have defined categories.

Strings miss a few of these:

{"islower", (PyCFunction)string_islower, METH_NOARGS, islower__doc__}, {"isupper", (PyCFunction)string_isupper, METH_NOARGS, isupper__doc__}, {"isspace", (PyCFunction)string_isspace, METH_NOARGS, isspace__doc__}, {"isdigit", (PyCFunction)string_isdigit, METH_NOARGS, isdigit__doc__}, {"istitle", (PyCFunction)string_istitle, METH_NOARGS, istitle__doc__}, {"isalpha", (PyCFunction)string_isalpha, METH_NOARGS, isalpha__doc__}, {"isalnum", (PyCFunction)string_isalnum, METH_NOARGS, isalnum__doc__},

I think all of the unicode methods should be added to 8-bit strings, even if they are just aliases for others (what's title case applied to Latin-1? I suppose same as upper case?).

...

...

for i in range(256): ... assert unichr(i).istitle() == unichr(i).isupper() ...

Seems so :-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/

"Fredrik Lundh" <fredrik@pythonware.com> writes:

...

I can understand this, but isn't "1.5.2" a little arbitrary.

have you tried migrating a huge python system from 1.5.2 to 2.x? if so, what did you learn?

That it is easier than porting from 1.4. Regards, Martin

Guido van Rossum <guido@python.org> writes:

I think all of the unicode methods should be added to 8-bit strings, even if they are just aliases for others (what's title case applied to Latin-1? I suppose same as upper case?).

So those would be locale dependent? (the Unicode ones are not). Regards, Martin

[Guido van Rossum]

Perhaps we should add isalnum, iscntrl, is graph, to match <ctype.h>? Or perhaps not? (Maybe I'd also like to add isword(), which would be isalnum() or '_' -- this is the definition of \w in the re module.)

This reminds me that I often miss, in the standard `ctype.h' and related, a function that would un-combine a character into its base character and its diacritic, and the complementary re-combining function. Even if this might be easier for Latin-1, it is difficult to design something general enough. Characters may have a more complex structure than a mere base and single diacritic. I do not know what to suggest. -- François Pinard http://www.iro.umontreal.ca/~pinard

...

I think all of the unicode methods should be added to 8-bit strings, even if they are just aliases for others (what's title case applied to Latin-1? I suppose same as upper case?).

So those would be locale dependent? (the Unicode ones are not).

Yes. isalpha() etc. for 8-bit strings are already locale dependent aren't they? BTW, how about deprecating strop while we're at it? --Guido van Rossum (home page: http://www.python.org/~guido/)

This reminds me that I often miss, in the standard `ctype.h' and related, a function that would un-combine a character into its base character and its diacritic, and the complementary re-combining function.

Even if this might be easier for Latin-1, it is difficult to design something general enough. Characters may have a more complex structure than a mere base and single diacritic. I do not know what to suggest.

I bet the Unicode standard has a standard way to do this. Maybe we can implement that, and then project the same interface on 8-bit characters? Of course character encoding issues might get in the way if <ctype.h> doesn't provide the data -- so you may be better off doing this in Unicode only. (We must never assume that 8-bit strings contain Latin-1.) --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum <guido@python.org> writes:

...

This reminds me that I often miss, in the standard `ctype.h' and related, a function that would un-combine a character into its base character and its diacritic, and the complementary re-combining function. [...] I bet the Unicode standard has a standard way to do this.

This is called 'unicode normalization forms'. Each "pre-combined" character can also be represented as a base character, and a "combining diacritic". There are symmetric normalization forms: NFC favours pre-combined characters, NFD favours combining characters. There is also a "compatibility decomposition" (K), where e.g. ANGSTROM SIGN decomposes to LATIN CAPITAL LETTER A WITH RING ABOVE.

Maybe we can implement that, and then project the same interface on 8-bit characters?

Not really. Needing to know the character set is one issue; the other issue is that the stand-alone diacritic characters in ASCII are *not* combining. We could certainly provide a mapping between the Unicode combining diacritics and the stand-alone diacritics, say as a codec, but that would be quite special-purpose. Providing a good normalization library is necessary, though, since many other algorithms (both from W3C and IETF) require Unicode normalization as part of the processing (usually to NFKC). Regards, Martin

Guido van Rossum <guido@python.org> writes:

...

...

Also, the data objects obviously have to be put somewhere. Before doing any of this, we need to decide where this stuff belongs. I doubt the technical effort involved will be too challenging.

So we don't need to make a decision today, right? We can delay that until those easy problems are solved.

What about my proposal to get rid of the data objects and add a few isxxx() methods instead?

That's a good thing to do, I agree.

I don't think that the data objects have any other function except for membership testing, and a method can be faster.

That is not true. Asking google for "string.letters" brings, as the first hit, non_letters = string.translate(norm, norm, string.letters) I also found random.choice(string.lowercase[:26] + string.uppercase[:26] + string.digits) This is, of course, nonsense, since it tries to "unlocalize" string.lowercase, where a string literal would have been better. I'm sure people have found other uses for these constants. Regards, Martin

On Wed, May 29, 2002 at 12:40:02PM -0400, Raymond Hettinger wrote:

From: "Guido van Rossum" <guido@python.org>

...

Thanks! I agree with the name change to PendingDeprecationWarning. Check it in before I change my mind! :-)

Awesome! Now, down to business. What shall we Silently Deprecate?

string module types module (after providing substitutes)

It looks like many of the names in the types module already have substitutes in __builtins__:

...

...

import types for name, t in types.__dict__.items(): ... if type(t) is type and hasattr(__builtins__, t.__name__): ... print 'types.%s -> %s' % (name, t.__name__) ... types.IntType -> int types.TypeType -> type types.StringType -> str types.FloatType -> float types.ObjectType -> object types.DictionaryType -> dict types.FileType -> file types.DictType -> dict types.ListType -> list types.TupleType -> tuple types.LongType -> long types.BufferType -> buffer types.UnicodeType -> unicode types.ComplexType -> complex types.SliceType -> slice types.XRangeType -> xrange

Some of these are new in 2.2 (like object, dict and file). Some of them used to be functions before Python 2.2 (like str, int and list). Three of them are still builtin functions in Python 2.2: xrange, buffer and slice. Perhaps they should also be converted to types for consistency. Some more factory functions that could be unified with the type of the objects they create module can be found in the new module. They, too can be used as substitutes for names in the types module.

...

...

import new for name, t in types.__dict__.items(): ... if type(t) is type and hasattr(new, t.__name__): ... print 'types.%s -> new.%s -> %s' % (name, t.__name__, t.__name__) types.CodeType -> new.code -> code types.ModuleType -> new.module -> module types.LambdaType -> new.function -> function types.InstanceType -> new.instance -> instance types.FunctionType -> new.function -> function

There are two that almost made it to this list but the name of the factory function in module new is not exactly the same as the type's __name__: types.MethodType -> new.instancemethod -> instancemethod ('instance method') types.ClassType -> new.classobj -> classobj ('class') For instancemethod it's easy to remove the space from the type's __name__. The word class is a reserved word. The type's __name__ could be changed to 'classobj' to match the factory function's name. Some other alternatives I can think of are 'class_', 'ClassType' or 'classtype'. Instances of the remaining types can't be instanciated from Python code. Most of them can be safely identified by their __name__: types.BuiltinMethodType -> builtin_function_or_method types.BuiltinFunctionType -> builtin_function_or_method types.TracebackType -> traceback types.GeneratorType -> generator types.FrameType -> frame types.NoneType -> NoneType The last two remaining troublemakers: types.DictProxyType -> dict_proxy ('dict-proxy') 'dict-proxy' is not a valid Python identifier. types.EllipsisType -> EllipsisType ('ellipsis') The name 'ellipsis' is easily confused with 'Ellipsis'. The name EllipsisType is consistent with NoneType. Both are the type of a specific singleton object. Should all these names be added to __builtins__? Many of them are not very useful in everyday programming. Perhaps the less important ones can be put away in some module. Now how should that module be named? Ummm... maybe 'types'? :-) Oren

...

...

...

I think all of the unicode methods should be added to 8-bit strings, even if they are just aliases for others (what's title case applied to Latin-1? I suppose same as upper case?).

So those would be locale dependent? (the Unicode ones are not).

Yes. isalpha() etc. for 8-bit strings are already locale dependent aren't they?

Yes, certainly. I'm just confirming, since this *is* a notable difference to Unicode strings.

Yes, but that's because locale-dependency is not a Unicode concept!

...

BTW, how about deprecating strop while we're at it?

That seems acceptable to me, once string.py stops importing it.

I wonder how much time after deprecating a builtin or extension module we should stop building it automatically in setup.py.

Me too. There are probably still places like Greg Stein's original import hack that import strop because they haven't been converted to string methods. --Guido van Rossum (home page: http://www.python.org/~guido/)

From: "Guido van Rossum" <guido@python.org>

These "use cases" don't convince me that there's a legitimate use case for string.letters etc. that the methods don't cover.

This is funny. In the C++ community there's a nearly unanimous consensus that way too much of the functionality of the standard strings is expressed as member functions. -Dave

Right now in string.py, there is:

from strop import maketrans, lowercase, uppercase, whitespace letters = lowercase + uppercase

However, lowercase, uppercase, and letters are already defined in string.py. It seems the only function being used from strop is maketrans. Is this correct? Should the others be removed from string.py?

strop.letters etc. are fixed when locale.setconv(LC_CTYPE, ...) is used. string.letters etc. are *also* fixed, but if string hasn't been imported yet when the locale is set, string gets the properly localized versions from strop (which does the right thing upon initialization to reflect the locale). This mechanism would have to be copied into string.py somehow. --Guido van Rossum (home page: http://www.python.org/~guido/)

From: "Guido van Rossum" <guido@python.org>

...

...

These "use cases" don't convince me that there's a legitimate use case for string.letters etc. that the methods don't cover.

This is funny. In the C++ community there's a nearly unanimous consensus that way too much of the functionality of the standard strings is expressed as member functions.

Interesting. Python used to have the same attitude, hence the string module -- but the existence of multiple string types made methods more attractive.

What's the alternative proposed for C++?

Free functions at namespace scope. The analogy would be module-level functions in Python. C++ also has multiple string types, but the availability of overloading makes this approach practical (is it time for Python multimethods yet?) If I were to make arguments against string member functions in Python I'd be talking about the degree of coupling between algorithms and data structures, how it interferes with genericity, and the difficulty that users will have in making "string-like" types... but-i-would-never-make-such-silly-arguments-ly y'rs, dave

[Guido van Rossum]

[...] I don't think that the data objects have any other function except for membership testing [...]

This is useful being able to quickly enumerate letters, or digits. Just yesterday, I wrote: contexte = {} for nom, valeur in map(None, string.uppercase[:len(valeur)], valeur): assert valeur in '01', valeur contexte[nom] = valeur != '0' -- François Pinard http://www.iro.umontreal.ca/~pinard

On Thu, May 30, 2002 at 08:35:02AM -0400, Guido van Rossum wrote:

...

Some of these are new in 2.2 (like object, dict and file). Some of them used to be functions before Python 2.2 (like str, int and list). Three of them are still builtin functions in Python 2.2: xrange, buffer and slice. Perhaps they should also be converted to types for consistency.

You can help by contributing patches for these three. (Let us know if you plan to do this, so others can relax.)

Okay. It will probably take me 20 time longer than someone who knows his way better around the CPython sources, but I guest I gotta start somewhere. Oren

I think the "nearly unanimous" is a bit overstated. Some people like the older C-style free functions, but I think this is just old habits fighting on until the bitter end. My (perhaps wacko) preference is to carefully segregate Strings and CharacterSets. After all, iswhitespace() maps a fact about a character set to a specific string instance. I think that the classic ASCII, the various ISO 8859 variants, and the Unicode character sets should be objectified and their attributes include strings of whitespace, uppercase, lowercase, etc., etc. --- David Abrahams <david.abrahams@rcn.com> wrote:

From: "Guido van Rossum" <guido@python.org>

...

...

...

These "use cases" don't convince me that there's a legitimate use case for string.letters etc. that the methods don't cover.

This is funny. In the C++ community there's a nearly unanimous consensus that way too much of the functionality of the standard strings is expressed as member functions.

Interesting. Python used to have the same attitude, hence the string module -- but the existence of multiple string types made methods more attractive.

What's the alternative proposed for C++?

Free functions at namespace scope. The analogy would be module-level functions in Python. C++ also has multiple string types, but the availability of overloading makes this approach practical (is it time for Python multimethods yet?)

If I were to make arguments against string member functions in Python I'd be talking about the degree of coupling between algorithms and data structures, how it interferes with genericity, and the difficulty that users will have in making "string-like" types...

but-i-would-never-make-such-silly-arguments-ly y'rs, dave

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

===== -- S. Lott, CCP :-{) S_LOTT@YAHOO.COM http://www.mindspring.com/~slott1 Buccaneer #468: KaDiMa Macintosh user: drinking upstream from the herd. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

This would be very cool. Rather than having to go by python version numbers, which seem obscure, an application can declare its dependencies by module. Perhaps even some tool to determine an apps dependencies. These dependencies can then be checked using the current version in a perl-esque regression test style to determine how well the current version meets the applications needs (I say this because some code may not be run normally but require more advanced features - this could also allow for some very interesting approaches to modularity and using available python features in larger applications). It would then be very easy to determine the cause of breakage and/or the need of the application.

Hm, this sounds like overkill to me. And who's going to write the AI software to do this automatic regression testing? --Guido van Rossum (home page: http://www.python.org/~guido/)

...

...

This would be very cool. Rather than having to go by python version numbers, which seem obscure, an application can declare its dependencies by module. Perhaps even some tool to determine an apps dependencies. These dependencies can then be checked using the current version in a perl-esque regression test style to determine how well the current version meets the applications needs (I say this because some code may not be run normally but require more advanced features - this could also allow for some very interesting approaches to modularity and using available python features in larger applications). It would then be very easy to determine the cause of breakage and/or the need of the application.

Hm, this sounds like overkill to me. And who's going to write the AI software to do this automatic regression testing?

Perhaps it came across as more than it should be. I meant just specifying the version numbers of the individual modules in a CPAN-like dependency thing. Then, on start-up, the dependencies are just checked. Mostly matching of version numbers. The stats are just a fancy way of saying how screwed you are :)

This has been proposed before, but I don't think anybody really understands how to do version dependencies correctly. --Guido van Rossum (home page: http://www.python.org/~guido/)

martin wrote:

...

have you tried migrating a huge python system from 1.5.2 to 2.x? if so, what did you learn?

That it is easier than porting from 1.4.

this does not match my experiences (neither from 24/7 production systems, nor any of our gui applications). what kind of applications have you ported? </F>

Michael Gilfix wrote:

This would be very cool. Rather than having to go by python version numbers, which seem obscure, an application can declare its dependencies by module. Perhaps even some tool to determine an apps dependencies. (...)

while i agree to this basic idea i wanted to remind of the other point buried in my mail ... Changing the deprecation process to be based on *version numbers* rather than *uncertain future points in time*...

On Wed, May 29 @ 20:29, holger krekel wrote:

...

IMO Enforcing version numbers in standard libraries is a good idea.

Eventually, a good versioning scheme for the standard-lib with automated deprecation may be what is needed. Making the introduction of new (or deprecation of) features

a) by hand

b) by measures of 'x years', example from from PEP4: "The deprecation warning will be added to the module one year after Python 2.3 is released, and the module will be removed one year after that."

seems unreliable. How do you construct an if-statement for 'One year after 2.3 is released' if the current version is 2.2 <wink>.

Instead deprecating

a) (semi-) automatically

b) by saying '2.3 issues deprecation warning, 2.4 does not support it'.

seems much saner. Even a program can be teached to check this.

Am i the only one to find this an evident change for the good (tm) ? holger

Guido van Rossum wrote:

...

...

...

This would be very cool. Rather than having to go by python version numbers, which seem obscure, an application can declare its dependencies by module. Perhaps even some tool to determine an apps dependencies. These dependencies can then be checked using the current version in a perl-esque regression test style to determine how well the current version meets the applications needs (I say this because some code may not be run normally but require more advanced features - this could also allow for some very interesting approaches to modularity and using available python features in larger applications). It would then be very easy to determine the cause of breakage and/or the need of the application.

Hm, this sounds like overkill to me. And who's going to write the AI software to do this automatic regression testing?

Perhaps it came across as more than it should be. I meant just specifying the version numbers of the individual modules in a CPAN-like dependency thing. Then, on start-up, the dependencies are just checked. Mostly matching of version numbers. The stats are just a fancy way of saying how screwed you are :)

This has been proposed before, but I don't think anybody really understands how to do version dependencies correctly.

But i assume, you do agree that a *working* versioning and dependency scheme for the standard-lib would be more than nice. (IMHO the more modules and versions we have the more important it gets). holger

But i assume, you do agree that a *working* versioning and dependency scheme for the standard-lib would be more than nice. (IMHO the more modules and versions we have the more important it gets).

Depends on how you define "working". I'm skeptical that such a thing can exist. --Guido van Rossum (home page: http://www.python.org/~guido/)

From: "Guido van Rossum" <guido@python.org>

Is this still relevant to Python?

Possibly.

Why are C++ member functions difficult to generic programs?

1. built-in types don't have member functions, so there's no way to get them to work like something that does. For that reason, when a generic function relies on member functions, it's "not very generic". 2. By the same token, if a generic function requires that a type have particular member functions, some class types may be ineligible for use with that function. If the requirement is simply that the appropriate free functions exist, it's usually possible to write them. This becomes a factor when using generic library A with a type from library B.

Does the same apply to Python methods?

#1 obviously doesn't, except that of course the built-in types have a fixed set of methods. #2 might apply. The general trend towards decoupling algorithms and data structures in C++ is one of those Good Things (tm). -Dave

Guido van Rossum wrote:

...

while i agree to this basic idea i wanted to remind of the other point buried in my mail ... Changing the deprecation process to be based on *version numbers* rather than *uncertain future points in time*...

-1. It's hard to predict how often versions will be released. The PEPs (4 and 5) specify time limits, which are better defined.

ok then. how would you translate (from PEP4) "The deprecation warning will be added to the module one year after Python 2.3 is released, and the module will be removed one year after that." to an if-statement-check you want to implement *today*? Additionally, if the above was based on versions you could implement the *deprecation process* today, no need to remember at which date some PEP mentioned something which has been forgotten for three years <wink> anyway. Are we really supposed to remember release dates of python versions? I mean of course they are of great historic value, but ... holger

ok then. how would you translate (from PEP4)

"The deprecation warning will be added to the module one year after Python 2.3 is released, and the module will be removed one year after that."

to an if-statement-check you want to implement *today*?

I guess I don't see why the error message should contain an expiration date. It's enough to know that the feature will expire -- you can find more info in the docs.

Additionally, if the above was based on versions you could implement the *deprecation process* today, no need to remember at which date some PEP mentioned something which has been forgotten for three years <wink> anyway.

Define deprecation process. I don't think it's a good idea to try to automate this. I want a human to decide that a deprecated module is really ready for deletion. This involves many other factors besides the originally promised deprecation date.

Are we really supposed to remember release dates of python versions? I mean of course they are of great historic value, but ...

Why would you need to? --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum <guido@python.org> writes:

Is this still relevant to Python? Why are C++ member functions difficult to generic programs? Does the same apply to Python methods?

In a generic algorithm foo, you can write def foo1(x): bar(x) if you have global functions. With methods, you need to write def foo1(x): x.bar() which means that bar must be a method of x. This might be difficult to achieve if x is of a class that you cannot control. In C++, it is then still possible to define a function def bar(x of-type-X): pass which, by means of overload resolution, will be found from foo1 automatically. In Python, this is not so easy since you don't have overloading. Regards, Martin

...

I guess I don't see why the error message should contain an expiration date. It's enough to know that the feature will expire -- you can find more info in the docs.

You may want to check that the python-version your program is running on might not have a certain feature or library any more. Just seeing an 'ImportError' leaves the user puzzled if he e.g. might have an installation problem.

Yes, they hve an installation problem. :-) They are using a Python version that's incompatible with the program. I really don't see what you are proposing to do about this. The author of the program should know that it uses a deprecated module and fix the program, rather than simply continuing to distribute it with out change. If the program is very old, the user who downloads it should realize that it might no longer work.

...

...

Additionally, if the above was based on versions you could implement the *deprecation process* today, no need to remember at which date some PEP mentioned something which has been forgotten for three years <wink> anyway.

Define deprecation process.

the citation above is a typical example for a 'deprecation process'. OK, you are a mathematician. i try harder...

A deprecation process may be seen as an algorithm which determines the life time (or die-time?) of features and modules.

I think this cannot and should not be determined algorithmically.

...

I don't think it's a good idea to try to automate this. I want a human to decide that a deprecated module is really ready for deletion. This involves many other factors besides the originally promised deprecation date.

automation does not mean there is no human intervention possible. It would be horrible indeed if computers would take over python development, no flaming wars, less and less more general modules ... :-)

Anyway, removing a module would certainly still require human intervention but its *intended* deprecation/removal could be specified precisely. If a feature lives longer due to gods mercy <wink> than this is pure luck. You can hope for it but should not rely on it.

I just happen to think that people and programs can work much better with 'version 2.5 or 3.0' than 'some years after some point in time' <wink>.

I don't see the point. Let's end this discussion. --Guido van Rossum (home page: http://www.python.org/~guido/)

I don't understand how using methods makes multiple string types easier to deal with.

Suppose I want to define my own string-like type. How do I arrange things so that " ".join(x) does the right thing when x contains instances of my new type? How is this made easier by the fact that join is a method of " " rather than a free function?

No solution in current Python deals really well with operations of two or more strings that may be of mixed types (the dispatch of binary operators comes closest). The current code checks for both standard string types to overcome this, and that doesn't work for a third, new string type. The point of methods was that homogeneous use (and all operations on a single string like s.lower() are homogeneous) is supported well. Because Python has no dispatch on argument type, the alternative would have been to rewrite the string module to do argument type tests in *all* functions -- and it would not support a third string type at all, not even when used homogeneous. IOW, if I write a function that calls s.lower() for an argument s, I can write a custom string type (e.g. UserString) that will work with f. If I wrote the same function using string.lower(s), I have no hope (short of modifying the string module). --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:

IOW, if I write a function that calls s.lower() for an argument s, I can write a custom string type (e.g. UserString) that will work with f. If I wrote the same function using string.lower(s), I have no hope (short of modifying the string module).

unless the functions in the string module delegate everything to the object (just like len(), getattr(), and others), and you make sure that your type behaves well when mixed with basic strings. something like, say: def lower(s): return s.lower() or def capwords(s, sep=None): return join(map(capitalize, s.split(sep)), sep or ' ') Cheers /F

In python, you don't need overloading, you have a variety of optional parameter mechanisms. I think the "member functions" issues from C++ don't apply to Python becuase C++ is strongly typed, meaning that many similar functions have to be written with slightly different type signatures. The lack of strong typing makes it practical to write generic operations. I find that use of free functions defeats good object-oriented design and leads to functionality being informally bound by a cluster of free functions that have similar names. I'm suspicious of this, finding it tiresome to maintain and debug. --- "Martin v. Loewis" <martin@v.loewis.de> wrote:

Guido van Rossum <guido@python.org> writes:

...

Is this still relevant to Python? Why are C++ member functions difficult to generic programs? Does the same apply to Python methods?

In a generic algorithm foo, you can write

def foo1(x): bar(x)

if you have global functions. With methods, you need to write

def foo1(x): x.bar()

which means that bar must be a method of x. This might be difficult to achieve if x is of a class that you cannot control. In C++, it is then still possible to define a function

def bar(x of-type-X): pass

which, by means of overload resolution, will be found from foo1 automatically.

In Python, this is not so easy since you don't have overloading.

Regards, Martin

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

===== -- S. Lott, CCP :-{) S_LOTT@YAHOO.COM http://www.mindspring.com/~slott1 Buccaneer #468: KaDiMa Macintosh user: drinking upstream from the herd. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

...

In python, you don't need overloading, you have a variety of optional parameter mechanisms

...which forces users to write centralized dispatching mechanism that could be much more elegantly-handled by the language. The language already does something just for operators, but the rules are complicated and don't scale well.

I don't think the situation can be improved without adding type declarations. --Guido van Rossum (home page: http://www.python.org/~guido/)

...

...

In python, you don't need overloading, you have a variety of optional parameter mechanisms

...which forces users to write centralized dispatching mechanism that could be much more elegantly-handled by the language. The language already does something just for operators, but the rules are complicated and don't scale well.

I don't think the situation can be improved without adding type declarations.

I thought this was the issue interfaces were supposed to handle? -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "In the end, outside of spy agencies, people are far too trusting and willing to help." --Ira Winkler

[Alex Martelli]

On Wednesday 29 May 2002 06:42 pm, Guido van Rossum wrote: ...

...

...

oct() hex()

Why? I use these a lot...

I assume the duplication of oct and hex wrt '%o'% and '%x'% was the reason to suggest silently-deprecating the former (trying to have 'just one obvious way' and all that).

Hi, people. I'm revising many accumulated notes, while writing the draft of a Python style and migration guide (in French) for a small team of Python programmers, here. By the way, I thank you all for the richness of the exchanged ideas in that area, lately. Also, poking around, I see even a bit deeper than before how beautiful the Python project is! Stumbling on the above message, I feel like making a further comment. When I was learning Python, I found elegant to discover that Python had all that is required so one could rewrite the `FORMAT % THINGS' operator, if one wanted to. If we deprecate built-ins (like `repr', `hex' and `oct') in favour of leaving `%' as the only way, we would loose that elegance. Moreover, it might be more speedy not having to go through the interpretation of a format string, and this might matter in some circumstances. -- François Pinard http://www.iro.umontreal.ca/~pinard