Mailman 3 September 2005 - Python-Dev

Re: [Python-Dev] Replacement for print in Python 3.0
by Guido van Rossum 02 Sep '05

02 Sep '05

On 9/1/05, Bill Janssen <janssen(a)parc.com> wrote: > After reviewing the PEP 3000 notes, I can find no justification there > for removing "print" other than your statement here -- that it has > served honorably and well in many programming languages for many > years, a curious reason for abandoning it. Some reasons to drop it have to do with the arcane syntax: (a) the trailing comma (is there anyone who likes that?), and (b) the optional ">>file" part. While I've always defended the latter against powerful opposition, that was only because print was already a statement and I find it important to have a way to do whatever print does to an arbitrary file. Of course, if print() were a function, we wouldn't need special syntax, we could just use stream.print() with the same signature; so that's one argument for dropping the syntax. Another real problem with print is that, while the automatic insertion of spaces is nice for beginners, it often gets in the way, and what you have to do to avoid this is pretty nasty: either drop print altogether in favor of sys.stdout.write(), or use string concatenation or a format string, assuming you have all the pieces available at the same time (which often you don't). Surely you don't want to suggest an extension, for example doubling the comma could make the extra space go away... :-) It looks to me like most arguments for keeping print are motivated by backwards compatibility (in its many guises, like the existence of 15 years of tutorials) and not by what would be best if we were to design a language from scratch. It seems to me that, as long as write() and writeln() were built-ins taking multiple args, teaching a beginner to use >>> writeln("The answer is: ", 4+4) is perfectly clear (and might be a gentle introduction to function calls as well). I've been thinking about some ancient Python history recently, which reminded me that one theme in Python's design is to have a minimalist syntax without being syntax-free like Lisp. (In a very early version of Python, 'dir' was a statement, just so that I wouldn't have to type the parentheses. Glad I dropped that one!) I really believe that dropping print in favor of a few built-in functions is an improvement -- backwards compatibility be damned! -- --Guido van Rossum (home page: http://www.python.org/~guido/)

7 7

Re: [Python-Dev] String views
by Michael Chermside 01 Sep '05

01 Sep '05

Tim Delaney writes: > One of the big disadvantages of string views is that they need to keep > the original object around, no matter how big it is. But in the case of > partition, much of the time the original string survives for at least a > similar period to the partitions. Why do you say that? Didn't several of Raymond's examples use the idiom: part_1, _, s = s.partition(first_sep) part_2, _, s = s.partition(second_sep) part_3, _, s = s.partition(third_sep) --- Skip writes: > I'm skeptical about performance as well, but not for that reason. A string > object can have a referent field. If not NULL, it refers to another string > object which is INCREFed in the usual way. At string deallocation, if the > referent is not NULL, the referent is DECREFed. If the referent is NULL, > ob_sval is freed. Won't work. A string may have multiple referrents, so a single referent field isn't sufficient. --- My own contribution: I know that the Java string class has support for this. The String class contains a reference to a char array along with start and length indices. The substring() method constructs what we're calling "string views". I wonder whether there is a way to instrument a JVM to record how often the underlying buffers are shared, then run some common Java apps. Since the feature is exactly analogous to what is being proposed here, I would find such such analysis very helpful. -- Michael Chermside

3 2

Python 3 design principles
by Jim Jewett 01 Sep '05

01 Sep '05

Nick Craig-Wood wrote: > If come python 3, there is a 99% accurate program which can turn your > python 2.x into python 3 code, then that would ease the transition > greatly. Guido wrote: > That might not be so easy given the desire to change most > list-returning functions and methods into iterator-returning ones. I assume part of the cleanup will include adding a choke point for import hooks. That way people could do the conversion on modules that they aren't sure about. There would be a performance penalty, but things would still work, and could be sped up as it was justified. > This means that *most* places where you use keys() your code will > still run, but *some* places you'll have to write list(d.keys()). How > is the translator going to know? So do it everywhere, in the auto-import. > Worse, there's a common idiom: > L = D.keys() > L.sort() > that should be replaced by > L = sorted(D) L = list(D.keys()) L = sorted(L) Not as efficient. Not as pretty. With work, even a mechanical importer could do better. But the old code would still run correctly. -jJ

1 0

String views
by Jim Jewett 01 Sep '05

01 Sep '05

Tim Delaney writes: > One of the big disadvantages of string views is that they need to keep > the original object around, no matter how big it is. But in the case of > partition, much of the time the original string survives for at least a > similar period to the partitions. Michael Chermside writes: > Didn't several of Raymond's examples use the idiom: > part_1, _, s = s.partition(first_sep) > part_2, _, s = s.partition(second_sep) > part_3, _, s = s.partition(third_sep) Yes, but in those cases, generally the entire original string was being kept by at least some part_#, so there really wasn't any wasted space. The problem only really shows up when a single 5-byte string keeps a 10K buffer alive. If it supports 2000 such strings, then everything is fine. Skip writes: > I'm skeptical about performance as well, but not for that reason. A string > object can have a referent field. If not NULL, it refers to another string > object which is INCREFed in the usual way. At string deallocation, if the > referent is not NULL, the referent is DECREFed. If the referent is NULL, > ob_sval is freed. Michael Chermside writes: > Won't work. A string may have multiple referrents, so a single referent > field isn't sufficient. I think you're looking at it backwards. A string would use a reference to a (series of characters) instead of ob_sval, just as dictionaries point to a table instead of small_table. The catch (as Tim mentioned) is that the underlying series of characters might be much larger than *this* string needs. If it isn't shared, then the extra is wasted. One way to deal with this might be have the strings clean up when they're called. If the string's length multiplied by the number of references to the buffer is much less than the size of the buffer, then the string should make its own small copy. Whether the complication is worth it, I don't know. -jJ

1 0

Re: [Python-Dev] Replacement for print in Python 3.0
by Guido van Rossum 01 Sep '05

01 Sep '05

(Please don't send private replies.) On 9/1/05, Eric Nieuwland <eric.nieuwland(a)xs4all.nl> wrote: > I have a lot of code that uses read()/write() to for binary file access. > Will that break by this change? > If so, I'd like to propose writes() instead of write() as proposed. No, that's the beauty. (Assuming the file is opened in binary mode.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
by Eric Nieuwland 01 Sep '05

01 Sep '05

Raymond Hettinger wrote: >> I think it's convenient but also rather odd that split() with a static >> string argument was moved from module string to a method in class str, >> while split() with a regexp has remained in module re. > > I don't see what you find odd. With str and unicode objects being > builtin, you don't need a separate module. In contrast, re is a > stand-alone extension which, of course, requires an import. That's an implementation oriented view. IMHO it is all a match-and-cut operation with fixed strings the simplest form of match expressions. From that point of view the distinction between the two is quite arbitrary. Of course, when turning from principles to daily practice again it is quite clear the distinction is useful. --eric

1 0

Re: [Python-Dev] Proof of the pudding: str.partition()
by Phillip J. Eby 01 Sep '05

01 Sep '05

At 04:55 AM 8/31/2005 -0700, Michael Chermside wrote: >Raymond's original definition for partition() did NOT support any >of the following: > > (*) Regular Expressions This can be orthogonally added to the 're' module, and definitely should not be part of the string method. > (*) Ways to generate just 1 or 2 of the 3 values if some are > not going to be used Yep, subscripting and slicing are more than adequate to handle *all* of those use cases, even the ones that some people have been jumping through odd hoops to express: before = x.partition(sep)[0] found = x.partition(sep)[1] after = x.partition(sep)[2] before, found = x.partition("foo")[:2] found, after = x.partition("foo")[1:] before, after = x.partition("foo")[::2] Okay, that last one is maybe a little too clever. I'd personally just use '__' or 'DONTCARE' or something like that for the value(s) I didn't care about, because it actually takes slightly less time to unpack a 3-tuple into three function-local variables than it does to pull out a single element of the tuple, and it's almost twice as fast as taking a slice and unpacking it into two variables. So, using three variables is both faster *and* easier to read than any of the variations anybody has proposed, including the ones I just showed above. > (*) Clever use of indices to avoid copying strings > (*) Behind-the-scenes tricks to allow repeated re-partitioning > to be faster than O(n^2) Yep, -1 on these. >The absence of these "features" is a GOOD thing. It makes the >behavior of partition() so simple and straightforward that it is >easily documented and can be instantly understood by a competent >programmer. I *like* keeping it simple. In fact, if anything, I'd >give UP the one fancy feature he chose to include: > > (*) An rpartition() function that searches from the right > >...except that I understand why he included it and am convinced >by the arguments (use cases can be demonstrated and people would >expect it to be there and complain if it weren't). I'd definitely like to keep rpartition. For example, splitting an HTTP url's hostname from its port should be done with rpartition, since you can have a 'username:password@' part before the host, and because the host can be a bracketed bracketed IPv6 host address with colons in it. >Simplicity and elegence are two of the reasons that this is such >an excellent proposal, +1.

9 10

Status of PEP 328
by Nicolas Fleury 01 Sep '05

01 Sep '05

Hi, I would like to know what is the status of PEP 328? Can absolute_import be expected in 2.5? Any help needed? I'll be interested. Also, the content of the PEP doesn't seem to be up-to-date with the status quo, since it is mentioned support in 2.4 for "from __future__ import absolute_import". Thx and regards, Nicolas

2 1

Re: [Python-Dev] [Python-checkins] python/dist/src/Lib/test test_re.py, 1.45.6.3, 1.45.6.4
by Jim Jewett 01 Sep '05

01 Sep '05

On 8/31/05, akuchling(a)users.sourceforge.net <akuchling(a)users.sourceforge.net> wrote: > Log Message: > ... the tests aren't run by default because I wanted to minimize > upheaval to the 2.3 test suite What is the reasoning behind this? It seems to me that if a (passing) test is being added, maintenance releases are the *most* important places to run them. On the other hand, I've also seen Raymond check (regression) tests into only development, so it seems to be a conscious choice. *I* just don't understand it. -jJ

2 1

Re: [Python-Dev] Proof of the pudding: str.partition()
by Michael Chermside 01 Sep '05

01 Sep '05

Raymond's original definition for partition() did NOT support any of the following: (*) Regular Expressions (*) Ways to generate just 1 or 2 of the 3 values if some are not going to be used (*) Clever use of indices to avoid copying strings (*) Behind-the-scenes tricks to allow repeated re-partitioning to be faster than O(n^2) The absence of these "features" is a GOOD thing. It makes the behavior of partition() so simple and straightforward that it is easily documented and can be instantly understood by a competent programmer. I *like* keeping it simple. In fact, if anything, I'd give UP the one fancy feature he chose to include: (*) An rpartition() function that searches from the right ...except that I understand why he included it and am convinced by the arguments (use cases can be demonstrated and people would expect it to be there and complain if it weren't). Simplicity and elegence are two of the reasons that this is such an excellent proposal, let's not lose them. We have existing tools (like split() and the re module) to handle the tricky problems. -- Michael Chermside

7 7