Mailman 3 October 2005 - Python-Dev

Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
by Guido van Rossum Oct. 25, 2005

Oct. 25, 2005

On 10/24/05, Bill Janssen <janssen(a)parc.com> wrote: > > > - yet others think: "I want all of Unicode, with proper, efficient > > > indexing, so I want four bytes per char". > > > > I doubt the last one though. Probably they really don't want efficient > > indexing, they want to perform higher-level operations that currently > > are only possible using efficient indexing or slicing. With the right > > API. perhaps they could work just as efficiently with an internal > > representation of UTF-8. > > I just got mail this morning from a researcher who wants exactly what > Martin described, and wondered why the default MacPython 2.4.2 didn't > provide it by default. :-) Oh, I don't doubt that they want it. But often they don't *need* it, and the higher-level goal they are trying to accomplish can be dealt with better in a different way. (Sort of my response to people asking for static typing in Python as well. :-) Did they tell you what they were trying to do that MacPython 2.4.2 wouldn't let them, beyond "represent a large Unicode string as an array of 4-byte integers"? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
by Phillip J. Eby Oct. 24, 2005

Oct. 24, 2005

At 06:06 PM 10/23/2005 -0700, Guido van Rossum wrote: >Folks, please focus on what Python 3000 should do. > >I'm thinking about making all character strings Unicode (possibly with >different internal representations a la NSString in Apple's Objective >C) and introduce a separate mutable bytes array data type. But I could >use some validation or feedback on this idea from actual >practitioners. +1. Chandler has been going through quite an upheaval to get its unicode handling together. Having a bytes type would be great, as long as there was support for files and sockets to produce bytes instead of strings (unless an encoding was specified). I'm tempted to say it would be even better if there was a command line option that could be used to force all binary opens to result in bytes, and require all text opens to specify an encoding. The Chandler i18n project lead would jump for joy if we had a way to keep "legacy" strings out of the system, apart from ASCII string constants found in code. It would then be okay not to drop support for the implicit conversions; if you can't get strings on input, then conversion's not really an issue. Anyway, I think all of the things I'd like to see can be done without breakage in 2.5. For Chandler at least, we'd be willing to go with a command-line option that's more strict, in order to be able to ensure that plugin developers can't accidentally put 8-bit strings in somewhere, just by opening a file.

3 2

Definining properties - a use case for class decorators?
by Nick Coghlan Oct. 24, 2005

Oct. 24, 2005

On and off, I've been looking for an elegant way to handle properties using decorators. It hasn't really worked, because decorators are inherently single function, and properties span multiple functions. However, it occurred to me that Python already contains a construct for grouping multiple related functions together: classes. And that thought led me to this decorator: def def_property(cls_func): cls = cls_func() try: fget = cls.get.im_func except AttributeError: fget = None try: fset = cls.set.im_func except AttributeError: fset = None try: fdel = cls.delete.im_func except AttributeError: fdel = None return property(fget, fset, fdel, cls.__doc__) Obviously, this decorator can only be used by decorating a function that returns the class of interest: class Demo(object): @def_property def test(): class prop: """This is a test property""" def get(self): print "Getting attribute on instance" def set(self, value): print "Setting attribute on instance" def delete(self): print "Deleting attribute on instance" return prop Which gives the following behaviour: Py> Demo.test <property object at 0x00B9CC38> Py> Demo().test Getting attribute on instance Py> Demo().test = 1 Setting attribute on instance Py> del Demo().test Deleting attribute on instance Py> help(Demo.test) Help on property: This is a test property <get> = get(self) <set> = set(self, value) <delete> = delete(self) If we had class decorators, though, the decorator could be modified to skip the function invocation: def def_property(cls): try: fget = cls.get.im_func except AttributeError: fget = None try: fset = cls.set.im_func except AttributeError: fset = None try: fdel = cls.delete.im_func except AttributeError: fdel = None return property(fget, fset, fdel, cls.__doc__) And the usage would be much more direct: class Demo(object): @def_property class test: """This is a test property""" def get(self): print "Getting attribute on instance" def set(self, value): print "Setting attribute on instance" def delete(self): print "Deleting attribute on instance" Comments? Screams of horror? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

22 57

cross compiling python for embedded systems
by giovanniangeli＠iquattrocastelli.it Oct. 23, 2005

Oct. 23, 2005

is this the right place to ask: How could I build the python interpreter for an embedded linux target system (arm9 based), cross-compiling on a linux PC host? thanks, Giovanni Angeli.

3 2

Proposed resolutions for open PEP 343 issues
by Nick Coghlan Oct. 23, 2005

Oct. 23, 2005

I'm still looking for more feedback on the issues raised in the last update of PEP 343. There hasn't been much direct feedback so far, but I've rephrased and suggested resolutions for the outstanding issues based on what feedback I have received, and my own thoughts over the last week of so. For those simply skimming, my proposed issue resolutions are: 1. Use the slot name "__context__" instead of "__with__" 2. Reserve the builtin name "context" for future use as described below 3a. Give generator-iterators a native context that invokes self.close() 3b. Use "contextmanager" as a builtin decorator to get generator-contexts 4. Special case the __context__ slot to avoid the need to decorate it For those that disagree with the proposed resolutions above, or simply would like more details, here's the reasoning: 1. Should the slot be named "__with__" or "__context__"? Guido raised this as a side comment during the discussion of PJE's task variables pre-PEP, and it's a fair question. The closest analogous slot method ("__iter__") is named after the protocol it relates to, rather than the associated statement/expression keyword (that is, the method isn't called "__for__"). The next closest analogous slot is one that doesn't actually exist yet - the proposed "boolean" protocol. This again uses the name of a protocol rather than the associated keyword (that is, the name "__bool__" was suggested rather than "__if__"). At the moment, PEP 343 makes the opposite choice - it uses the keyword, rather than the protocol name (that is, it uses "__with__" instead of using "__context__"). That inconsistency would be a bad thing, in my opinion, and I propose that the slot should instead be named "__context__". 2. If the slot is called "__context__" what should a "context" builtin do? Again, considering existing slot names, a slot with a given name is generally invoked by the builtin type or function with the same name. This is true of the builtin types, and also true of iter, cmp and pow. getattr, setattr and delattr get in on the act as well. So, to be consistent, one would expect a "context" builtin to be able to be used such that "context(x)" invoked "x.__context__()". Such a method might special-case certain types, or have a two-argument form that accepted an "enter" function and an "exit" function, but using it to mark a generator that is to be used as a context manager (as currently suggested in PEP 343) would not be appropriate. I don't mind either way whether or not a "context" builtin is actually included for Python 2.5. However, even if it isn't included, the name should be reserved for that purpose (that is, we shouldn't be using it to name a generator decorator or a module). 3. How should generators behave when used as contexts? With PEP 342 accepted, generators pose a problem, because they have two possible uses as contexts. The first is for a generator that is intended to be used as an actual iterator. This case is a case of resource management - ensuring the close method is invoked on the generator-iterator when done with it (i.e., similar to the proposed native context for files). PEP 343 proposes a second use case for generators - to write custom context managers. In this case, the __enter__ method steps the generator once, and the __exit__ method finishes the job. I propose that we give generator-iterator objects resource management behaviour by default (i.e., __context__ and __enter__ methods that just "return self", and an __exit__ method that invokes "self.close()"). The "contextmanager" builtin decorator from previous drafts of the PEP (called simply "context" in the current draft) can then be used to get the custom context manager behaviour. I previously thought giving generators a native context caused problems with getting silent failures when the "contextmanager" decorator was inadvertently omitted. This is still technically true - the "with" statement itself won't raise a TypeError because the generator is a legal context. However, with this bug, the context manager won't be getting entered *at all* (it gets closed without its next() method ever being called). Even the most cursory testing of the generator-context function should be able to tell whether the generator-context is being entered or not. The main alternative (having yet-another-decorator to give generators "auto-close" functionality) would be possible, but the additional builtin clutter would be getting to the point where it started to concern me. And given that "yield" inside "try/finally" is now always legal, I consider it reasonable that using a generator in a "with" statement would also always be legal. Further, if type_new special cases __context__ as suggested below, then the context behaviour of generators used to define "__iter__" and "__context__" slots will always be appropriate. 4. Should the __context__ slot be special-cased in type_new? Currently, type_new special cases the "__new__" slot and automatically applies the staticmethod decorator when it finds a function occupying that slot in the class attribute dictionary. I propose that type_new also special case the situation where the "__context__" slot is occupied by a generator function, and automatically apply the "contextmanager" decorator. This looks much nicer when using a generator to write a __context__ function, and also avoids the situation where the decorator is omitted, and the object becomes legal to use directly in with statements but doesn't actually do the right thing. Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

3 4

AST reverts PEP 342 implementation and IDLE starts working again
by Raymond Hettinger Oct. 23, 2005

Oct. 23, 2005

FWIW, a few months ago, I reported that File New or File Open in IDLE would crash Python as a result of the check-in implementing PEP 342. Now, with AST checked-in, IDLE has started working again. Given the reconfirmation, I recommend that the 342 patch be regarded as suspect and not be restored until the fault is found and repaired. Raymond

2 2

Comparing date+time w/ just time
by skip＠pobox.com Oct. 22, 2005

Oct. 22, 2005

With significant input from Fred I made some changes to xmlrpclib a couple months ago to better integrate datetime objects into xmlrpclib. That raised some problems because I neglected to add support for comparing datetime objects with xmlrpclib.DateTime objects. (The problem showed up in MoinMoin.) I've been working on that recently (adding rich comparison methods to DateTime while retaining __cmp__ for backward compatibility), and have second thoughts about one of the original changes. I tried to support datetime, date and time objects. My problems are with support for time objects. Marshalling datetimes as xmlrpclib.DateTime objects is no problem (though you lose fractions of a second). Marshalling dates is reasonable if you treat the time as 00:00:00. I decided to marshal datetime.time objects by fixing the day portion of the xmlrpclib.DateTime object as today's date. That's the suspect part. When I went back recently to add better comparison support, I decided to compare xmlrpclib.DateTime objects with time objects by simply comparing the HH:MM:SS part of the DateTime with the time object. That's making me a bit queazy now. datetime.time(hour=23) would compare equal to any DateTime with its time equal to 11PM. Under the rule, "in the face of ambiguity, refuse the temptation to guess", I'm inclined to dump support for marshalling and comparison of time objects altogether. Do others agree that was a bad idea? Thx, Skip

4 4

DRAFT: python-dev Summary for 2005-09-01 through 2005-09-16
by Tony Meyer Oct. 22, 2005

Oct. 22, 2005

This is over a month late, sorry, but here it is (Steve did his threads ages ago; I've fallen really behind). Summaries for the second half of September and the first half of October will soon follow. As always, if anyone is able to give this a quick look that would be great. Feedback to me or Steve (steven.bethard(a)gmail.com). Thanks! ============= Announcements ============= ----------------------------- QOTF: Quotes of the Fortnight ----------------------------- In the thread on the print statement, Charles Cazabon provided some nice imagery for Guido's Python 3.0 strategy. Our first QOTF is his comment about the print statement: It's an anomaly. It stands out in the language as a sore thumb waiting for Guido's hammer. We also learned something important about the evolution of Python thanks to Paul Moore. In the thread on the Python 3.0 executable name, Greg Ewing worried that if the Python 3.0 executable is named "py": Python 4.0 is going to just be called "p", and by the time we get to Python 5.0, the name will have vanished altogether! Fortunately, as Paul Moore explains in our second QOTF, these naming conventions are exactly as we should expect them: That's OK, by the time Python 5.0 comes out, it will have taken over the world and be the default language for everything. So omitting the name is exactly right :-) [SJB] Contributing threads: - `Replacement for print in Python 3.0 <http://mail.python.org/ pipermail/python-dev/2005-September/055995.html>`__ - `Python 3 executable name <http://mail.python.org/pipermail/python- dev/2005-September/056377.html>`__ -------------------------------------------------- The "Swiss Army Knife (...Not)" API design pattern -------------------------------------------------- This fortnight saw a number of different discussions on what Guido's guiding principles are in making design decisions about Python. Guido introduced the "Swiss Army Knife (...Not)" API design pattern, which has been lauded by some as `the long-lost 20th principle from the Zen of Python`_. A direct quote from Guido: [I]nstead of a single "swiss-army-knife" function with various options that choose different behavior variants, it's better to have different dedicated functions for each of the major functionality types. This principle is the basis for pairs like str.split() and str.rsplit () or str.find() and str.rfind(). The goal is to keep cognitive overhead down by associating with each use case a single function with a minimal number of parameters. [SJB] .. _the long-lost 20th principle from the Zen of Python: http:// mail.python.org/pipermail/python-dev/2005-September/056228.html Contributing threads: - `Replacement for print in Python 3.0 <http://mail.python.org/ pipermail/python-dev/2005-September/056202.html>`__ - `Replacement for print in Python 3.0 <http://mail.python.org/ pipermail/python-dev/2005-September/056228.html>`__ ------------------------ A Python-to-C++ compiler ------------------------ Mark Dufour announced `Shed Skin`_, an experimental Python-to-C++ compiler, which can convert many Python programs into optimized C++ code, using static type inference techniques. It works best for Python programs written in a relatively static C++-style; much work remains to be done, and Mark would like anyone interested in getting involved to contact him. Shed Skin was one of the recent `Google`_ `Summer of Code`_ projects. .. _Shed Skin: http://shedskin.sourceforge.net .. _Google: http://www.google.com .. _Summer of Code: http://code.google.com/summerofcode.html [TAM] Contributing thread: - `First release of Shed Skin, a Python-to-C++ compiler. <http:// mail.python.org/pipermail/python-dev/2005-September/056356.html>`__ -------------------------------------------------------------- python-checkins followups now stay on the python-checkins list -------------------------------------------------------------- In a follow-up to a `thread in early July`_, the python-checkins mailing list Reply-To header munging has been turned off. Previously, follow-ups to python-checkins would be addressed to python-dev; now, follow-ups will stay on the python-checkins list by default. .. _thread in early July: http://www.python.org/dev/summary/ 2005-07-01_2005-07-15.html#behavior-of-sourceforge-when-replying-to- python-checkins [TAM] Contributing thread: - `python-checkins reply-to <http://mail.python.org/pipermail/python- dev/2005-September/056428.html>`__ ========= Summaries ========= -------------------------------------------- Converting print to a function in Python 3.0 -------------------------------------------- In Python 3.0, Guido wants to change print from a statement to a function. Some of his motivation for this change: * Converting code that uses the print statement to instead use the logging package, a UI package, etc. is complicated because of the syntax. Parentheses, commas and >>s all behave differently in the print statement than they would in a function call. * Having print as a statement makes the language harder to evolve. For example, if it's determined that Python should gain printf behavior of some sort, adding this is harder -- as a statement, it would require the introduction of new syntax, as a function, it would feel like a second-class citizen compared to print. * Since the print statement always inserts spaces, code that doesn't want these spaces will often have to use a completely different style of formatting (e.g. using sys.stdout.write and/or string formatting) * Changing the behavior of statements is hard, while builtin functions can simply be replaced by setting an attribute of __builtin__. Guido's initial proposal suggested three methods to be adopted by all stream (file-like) objects:: stream.write(a1, a2, ...) equivalent to: map(stream.write, map(str, [a1, a2, ...])) stream.writeln(a1, a2, ...) equivalent to: stream.write(a1, a2, ..., "\n") stream.writef(fmt, a1, a2, ...) equivalent to: stream.write(fmt % (a1, a2, ...)) Additionally, three new builtins would appear, write(), writeln() and writef() which called the corresponding methods on sys.stdout. People had a number of problems with this initial proposal: * People make heavy use of the space-insertion behavior of the current print statement. With Guido's initial proposal, inserting spaces would require manually adding space characters, e.g. ``write (foo, " ", bar, " ", baz)``. * People want to keep the stream API simple. With Guido's initial proposal, all file-like objects would probably need to support these three new methods. (But see also `Deriving file-like object methods from read() and write()`_.) * People primarily (about 85% of the time) use the print statement to print complete lines. With Guido's initial proposal, the function to do this, writeln(), has the longer name than the less-frequently needed write(). There were a variety of proposals following Guido's that attempted to address the issues above, most of which were posted to the wiki_. They generally all proposed a function something like:: def print(*args): sys.stdout.write(' '.join(str(arg) for arg in args)) sys.stdout.write('\n') with support for a file= keyword parameter to specify a stream other than sys.stdout, and a sep= keyword parameter to specify a separator other than ' '. There was some discussion about how the final newline could be suppressed, including a nl= keyword parameter and the usage of the Ellipsis object (e.g. so that ``print(foo, bar, ...) `` would not print the final newline). There was also substantial support for a formatting variant like:: def printf(fmt, *args): print(fmt % args) In the end, Guido seemed to be leaning towards supporting three printing variants:: * print(...) would be much like the proposals above, calling str() on each argument and then printing them with spaces in between and a following newline * printraw(...) or printbare(...) would also call str() on each argument and print them, but with no intervening spaces and no final newline (c) printf(fmt, ...) would string-substitute the arguments into the format string and then write the format string Each of these functions would also accept a keyword parameter for specifying a stream other than sys.stdout. Because ``print`` is a keyword, ``from __future__ import printing`` would be required to use the new print() function. At this point, the thread trailed off, and no final decisions were made. [SJB] .. _wiki: http://wiki.python.org/moin/PrintAsFunction Contributing threads: - `Python 3 design principles <http://mail.python.org/pipermail/ python-dev/2005-September/055944.html>`__ - `Replacement for print in Python 3.0 <http://mail.python.org/ pipermail/python-dev/2005-September/055968.html>`__ - `New Wiki page - PrintAsFunction <http://mail.python.org/pipermail/ python-dev/2005-September/056081.html>`__ - `Hacking print (was: Replacement for print in Python 3.0) <http:// mail.python.org/pipermail/python-dev/2005-September/056125.html>`__ - `Pascaloid print substitute (Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/2005-September/ 056171.html>`__ ---------------------------------- Making C code easier in Python 3.0 ---------------------------------- Nick Jacobson asked whether reference counting would be replaced in Python 3.0. Guido pointed out that the (CPython) implementation would have to be completely changed, and that isn't planned; many people also pointed out that reference counting is an implementation detail, not part of the language specification, and that there are other options that can be explored (e.g. `PyPy`_, `Jython`_, `IronPython`_). Arising from this question was a suggestion from Greg Ewing to build something akin to `Pyrex`_ (which takes care of reference count/ garbage collection issues automatically) into the standard Python distribution. This suggestion was met with general enthusiasm; some general discussion about which cases were most appropriate for Pyrex use (e.g. extension modules, wrapping C libraries, modules implemented in C for performance reasons) also followed. .. _PyPy: http://codespeak.net/pypy/ .. _Jython: http://www.jython.org/ .. _IronPython: http://www.ironpython.com/ .. _Pyrex: http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/ [TAM] Contributing thread: - `reference counting in Py3K <http://mail.python.org/pipermail/ python-dev/2005-September/056215.html>`__ -------------------------- Multiple views of a string -------------------------- Tim Delaney suggested that str.partition could return 'views' of a string, rather than new string objects, as the substrings, to avoid the time needed to create strings that are potentially unused. Raymond Hettinger pointed out that the practical cost is unlikely to be significant, as the strings are likely to be empty, small, or used, and that all the pre-Python 2.5 methods would still be available for those times when they would be more appropriate. However, using string 'views' (objects that reference the 'parent' string, rather than copying the data) caught the imagination of several Python-dev'ers. Discussion ensued about how this object could work (Skip Montanaro threw together a sample implementation); towards the end it was pointed out that buffer() objects, with some additional string methods, could provide this slice-like instance with low memory requirements. Guido also mentioned `NSString`_, the NextStep string type used by `ObjC`_, which is fairly similar. .. _ObjC: http://en.wikipedia.org/wiki/Objc .. _NSString: http://developer.apple.com/documentation/Cocoa/ Reference/Foundation/ObjC_classic/Classes/NSString.html [TAM] Contributing threads: - `Proof of the pudding: str.partition() <http://mail.python.org/ pipermail/python-dev/2005-September/055924.html>`__ - `String views (was: Re: Proof of the pudding: str.partition()) <http://mail.python.org/pipermail/python-dev/2005-September/ 055933.html>`__ - `String views <http://mail.python.org/pipermail/python-dev/2005- September/055947.html>`__ ------------------------------- String-formatting in Python 3.0 ------------------------------- Currently, using ``%`` for string formatting has a number of inconvenient consequences: * precedence issues: ``"a%sa" % "b"*4`` produces ``'abaabaabaaba'``, not ``'abbbba'`` * special-cased tuples: ``"%s" % x`` produces a string representation of x *unless* x is a tuple (in which case it unpacks it, raising a TypeError if ``len(x) != 1``). * keyword formatting issues: a number of people have complained that ``%(myvar)s`` is much more complicated than it needs to be (hence string.Template's ``$myvar``). To address the first two issues, Raymond Hettinger proposed that string formatting become a builtin function, and others proposed that formatting become a method of str/unicode objects. Guido definitely agreed with the move from ``%`` to a callable, but it was unclear as to his preference for function or method. Nick Coghlan tried to address the ``%(myvar)s`` issue by exploring a few extensions to string.Template formatting. He produced a format() function where arguments could be specified either by position (e.g. $1, $2, etc.) or with keywords (e.g. $item, $quantity), and where the usual C-style format specifiers were still supported:: format("$item: $[0.2f]quantity", quantity=0.5, item='Bees') format("$1: $[0.2f]2", 'Bees', 0.5) Nick also briefly explored format specifiers for expanding iterables, but Guido disliked the idea, explaining that adding or removing a print from a program should not drastically change the program's behavior (as it might if a print accidentally consumed an iterable that you weren't done with). There was also some high-level discussion about internationalization concerns, where format strings need to be easy for translators to read and reorganize. Since word orders may change, having either keyword parameters or positional parameters (as in Nick's scheme) is crucial. Unfortunately, this discussion seemed to get lost in the massive `Converting print to a function in Python 3.0`_ discussion, and no decisions were made about either a formatting function or Nick's format specifier extensions. [SJB] Contributing threads: - `Replacement for print in Python 3.0 <http://mail.python.org/ pipermail/python-dev/2005-September/055979.html>`__ - `string formatting options and removing basestring.__mod__ (WAS: Replacement for print in Python 3.0) <http://mail.python.org/ pipermail/python-dev/2005-September/056163.html>`__ - `string formatting and i18n <http://mail.python.org/pipermail/ python-dev/2005-September/056191.html>`__ - `string.Template format enhancements (Re: Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/2005- September/056231.html>`__ --------------------------------------------------------- Deriving file-like object methods from read() and write() --------------------------------------------------------- A variety of methods on the file object, including __iter__(), next (), readline(), readlines() and writelines(), are all derivable from the read() and write() methods. At least twice this fortnight, the issue was raised about making it easier for file-like objects to add the derivable methods if they've defined read() and write(). One suggestion was to provide a FileMixin class (like the DictMixin of UserDict) that other types could inherit from. This has the problem that the creator of the file-like object must determine at the time that the class is defined that it should support the additional methods. It is also more difficult to use mixin classes in C code (because multiple inheritance requires dealing with the type's metaclass). Fredrik Lundh suggested that something along the lines of `PEP 246`_'s object adaptation might be appropriate, but there was still some disagreement on the issue. [SJB] .. _PEP 246: http://www.python.org/peps/pep-0246.html Contributing threads: - `Mixin classes in the standard library <http://mail.python.org/ pipermail/python-dev/2005-September/056135.html>`__ - `Simplify the file-like-object interface (Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/2005- September/056218.html>`__ - `Simplify the file-like-object interface <http://mail.python.org/ pipermail/python-dev/2005-September/056229.html>`__ ------------------------------------ Making new-style classes the default ------------------------------------ Lisandro Dalcin proposed that something like:: from __future__ import new_style_classes be introduced to have newly defined classes implicitly derive from object. It was pointed out that this functionality is already available through the module-level statement:: __metaclass__ = type The argument was made that the __future__ version would be easier for non-experts to understand and to Google for, but Guido declared that the current syntax is fine -- there are much more important issues to be dealt with right now. [SJB] Contributing thread: - `PEP 3000 and new style classes <http://mail.python.org/pipermail/ python-dev/2005-September/056305.html>`__ -------------------------------------------------- Using __future__ to have builtins return iterators -------------------------------------------------- Lisandro Dalcin requested a __future__ import of some sort that would * make range() and zip() return iterators * remove xrange() * make the dict.keys(), dict.values(), dict.items() etc. methods return iterators Guido indicated that an alternate builtins module could be provided so that the first point could be covered with something like:: from future_builtins import zip, range However, there wasn't really a good way to change the dict methods. Simply importing a new dict object from "future_builtins" wouldn't solve the problem because using anyone's module that used the old dict object would mean a mix of the two types in your module. And since __future__ imports are intended to affect only the module which includes them, changing the builtin dict object globally would be inappropriate (as it would let an import in one module break code in another). [SJB] Contributing thread: - `PEP 3000 and iterators <http://mail.python.org/pipermail/python- dev/2005-September/056340.html>`__ ------------------------------------------------------------- Using compiled re methods vs. using module-level re functions ------------------------------------------------------------- After Michael Chermside commented that users should be encouraged to use the methods on compiled re objects instead of the re functions available at the module level (and after Stephen J. Turnbull promised to look into supplying such a documentation patch), there was a brief discussion about how much of a difference using the compiled re objects really makes. As it turns out, in the CPython implementation, the module-level functions cache the first 100 patterns, so in many cases, the only additional cost of using the module-level functions is a dictionary lookup. [SJB] Contributing thread: - `Revising RE docs <http://mail.python.org/pipermail/python-dev/2005- September/055938.html>`__ -------------------------------------- urlparse and urls with too many '../'s -------------------------------------- Fabien Schwob pointed out that urlparse.join() doesn't strip out any extraneous '..' directories (e.g. http://example.com/../index.html). While Guido indicated that he found the current behaviour acceptable, Jeff Epler pointed out that `RFC 2396`_ states that invalid URIs like this may be handled by removing the ".." segments from the resolved path (although this is an implementation detail). Armin Rigo indicated that, even if this is theoretically not a bug, a proposed patch with this motiviation would be welcome. .. _RFC 2396: http://www.faqs.org/rfcs/rfc2396.html [TAM] Contributing thread: - `bug in urlparse <http://mail.python.org/pipermail/python-dev/2005- September/056144.html>`__ ----------------------------------------------- Using an iterator instead of a tuple for \*args ----------------------------------------------- Nick Coghlan suggested that in Python 3.0, the \*args extended function call syntax should produce an iterator instead of a tuple as it currently does. That would mean that code like:: output(*some_long_iterator) would not load the entire iterator into a memory before processing it. I pointed him to a previous discussion Raymond Hettinger and I had about the subject that indicated that for \*args, sequences were preferable to iterators in a number of situations. Guido agreed, indicating that \*args will continue to be sequences in Python 3.0. [SJB] Contributing thread: - `iterators and extended function call syntax (WAS: Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/ 2005-September/056109.html>`__ ---------------------------------------- Constructing traceback objects in Python ---------------------------------------- Contributing thread: - `Asynchronous use of Traceback objects <http://mail.python.org/ pipermail/python-dev/2005-September/056091.html>`__ ------------------------------- No dedent() methods for strings ------------------------------- Contributing thread: - `str.dedent <http://mail.python.org/pipermail/python-dev/2005- September/056412.html>`__ ------------------------ Arguments vs. parameters ------------------------ - `Term unification <http://mail.python.org/pipermail/python-dev/2005- September/056409.html>`__ ----------------------------------------------------------------------- Removing sequence support from the return value of stat() in Python 3.0 ----------------------------------------------------------------------- Terry J. Reedy proposed that, in Python 3.0, instead of os.stat() returning a sequence (where the order of the items is only of historical significance), a proper stat object be returned. This was met with general support, and so seems likely to occur. Skip Montanaro also proposed that the st_ prefixes in the attribute names be removed, since there are no namespace issues to be concerned with, which met with some approval, but concern from Guido that the forms with the prefixes would be more familiar to users, and make Googling or grepping simpler. [TAM] Contributing thread: - `stat() return value (was: Re: Proof of the pudding: str.partition ()) <http://mail.python.org/pipermail/python-dev/2005-September/ 055931.html>`__ -------------------------------------------------- Making code in the Tools directory more accessible -------------------------------------------------- Installation of Python typically doesn't include the Tools directory; combined with the lack of mention of these scripts in the documentation, this means that knowledge of these generally useful scripts is fairly limited. Tim Peters noted that historically a Tools directory was only added to the Windows installer if it was specifically requested; as such, the audiopy, bgen, compiler, faqwiz, framer, modulator, msi, unicode, and world Tools directories are not currently included in the Windows installer. Nick Coghlan added that Tools/README.txt isn't included in the Windows installer, so Windows users don't get a synopsis of the tools that are included; he also suggested that adding this readme to the "undocumented modules" section of the standard library would be a simple improvement. Non- windows users typically don't get the Tools directory at all with an install. Remaining questions included how the directory should be documented (e.g. man pages for the scripts, a documentation page for them), where to install them on non-Windows installations (e.g. /usr/share/ python, /usr/lib/pythonX.Y/Tools), and whether the Windows installer should include all of the directories. [TAM] Contributing thread: - `Tools directory (Was RE: Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/2005-September/ 056318.html>`__ ---------------------------------- Responsiveness of IDLE development ---------------------------------- Noam Raphael posted a request for help getting a large patch to IDLE committed to CVS. He was concerned that there hasn't been any IDLE development recently, and that patches are not being considered. He indicated that his group was considering offering a fork of IDLE with the improvements, but that they would much prefer integrating the improvements into the core distribution. It was pointed out that a fork might be the best solution, for various reasons (e.g. the improvements may not be of general interest, the release time would be much quicker), and that this was how the current version of IDLE was developed. The dicussion died out, so it seems likely that a fork will be the resulting solution. [TAM] Contributing thread: - `IDLE development <http://mail.python.org/pipermail/python-dev/2005- September/056357.html>`__ ----------------------------- Speeding up list append calls ----------------------------- A `comp.lang.python message from Tim Peters`_ prompted Neal Norwitz to investigate how the code that Tim posted could be sped up. He hacked the code to replace var.append() with the LIST_APPEND opcode, and achieved a roughly 200% speed increase. Although this doesn't work in general, Neal wondered if it could be used as a peephole optimization when a variable is known to be a list. Martin v. Lˆwis suggested that the code could simply check whether it was a list; Phillip J. Eby and Fredrik Lundh pointed out that this is similar to what various math operators do (e.g. speeding up int + int calls). .. _comp.lang.python message from Tim Peters: http:// groups.google.com/group/comp.lang.python/msg/9075a3bc59c334c9 [TAM] Contributing thread: - `speeding up list append calls <http://mail.python.org/pipermail/ python-dev/2005-September/056396.html>`__ ------------------------------------ Allowing str.strip to remove "words" ------------------------------------ Jonny Reichwald proposed an enhancement to str.strip(). In addition to its current form, where it takes a string of characters to strip, to take any iterable containing either character lists or string lists, so that is is possible to remove entire words from the stripped string. For example:: #A char list gives the same result as the standard strip >>> my_strip("abcdeed", "de") 'abc' #A list of strings instead >>> my_strip("abcdeed", ("ed",)) 'abcde' #The char order in the strings to be stripped are of importance >>> my_strip("abcdeed", ("ad", "eb")) 'abcdeed' Raymond Hettinger queried whether there was actual demand for such a change, and whether such demand was sufficient to justify the added complexity; Josiah Carlson also pointed out that implementing this only requires a four-line function. Judging from the lack of responses, it seems likely that there isn't enough demand. Contributing thread: - `str.strip() enhancement <http://mail.python.org/pipermail/python- dev/2005-September/056119.html>`__ ================ Deferred Threads ================ - `C coding experiment <http://mail.python.org/pipermail/python-dev/ 2005-September/055965.html>`__ - `os.path.diff(path1, path2) <http://mail.python.org/pipermail/ python-dev/2005-September/056391.html>`__ =============== Skipped Threads =============== - `import exceptions <http://mail.python.org/pipermail/python-dev/ 2005-September/055926.html>`__ - `[Python-checkins] python/dist/src/Lib/test test_re.py, 1.45.6.3, 1.45.6.4 <http://mail.python.org/pipermail/python-dev/2005-September/ 055927.html>`__ - `setdefault's second argument <http://mail.python.org/pipermail/ python-dev/2005-September/055929.html>`__ - `Alternative imports (Re: Python 3 design principles) <http:// mail.python.org/pipermail/python-dev/2005-September/055945.html>`__ - `python/dist/src/Lib/test test_re.py, 1.45.6.3, 1.45.6.4 <http:// mail.python.org/pipermail/python-dev/2005-September/055963.html>`__ - `Status of PEP 328 <http://mail.python.org/pipermail/python-dev/ 2005-September/055969.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/ python-dev/2005-September/055978.html>`__ - `itertools.chain should take an iterable ? <http://mail.python.org/ pipermail/python-dev/2005-September/055981.html>`__ - `partition() (was: Remove str.find in 3.0?) <http://mail.python.org/ pipermail/python-dev/2005-September/055983.html>`__ - `gdbinit problem <http://mail.python.org/pipermail/python-dev/2005- September/056178.html>`__ - `Exception Reorg PEP checked in <http://mail.python.org/pipermail/ python-dev/2005-September/056296.html>`__ - `international python <http://mail.python.org/pipermail/python-dev/ 2005-September/056326.html>`__ - `SIGPIPE => SIG_IGN? <http://mail.python.org/pipermail/python- dev/2005-September/056341.html>`__ - `[draft] python-dev Summary for 2005-08-16 through 2005-08-31 <http://mail.python.org/pipermail/python-dev/2005-September/ 056348.html>`__ - `[Python-checkins] python/dist/src/Lib urllib.py, 1.169, 1.170 <http://mail.python.org/pipermail/python-dev/2005-September/ 056349.html>`__ - `Wanting to learn <http://mail.python.org/pipermail/python-dev/2005- September/056350.html>`__ - `Python code.interact() and UTF-8 locale <http://mail.python.org/ pipermail/python-dev/2005-September/056361.html>`__ - `pygettext() without newlines (Was: Re: Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/2005- September/056368.html>`__ - `Python 3 executable name (was: Re: PEP 3000 and iterators) <http:// mail.python.org/pipermail/python-dev/2005-September/056369.html>`__ - `Python 3 executable name <http://mail.python.org/pipermail/python- dev/2005-September/056371.html>`__ - `Skiping searching throw dictionaries of mro() members. <http:// mail.python.org/pipermail/python-dev/2005-September/056403.html>`__ - `Fwd: [Python-checkins] python/dist/src/Misc NEWS, 1.1193.2.94, 1.1193.2.95 <http://mail.python.org/pipermail/python-dev/2005- September/056405.html>`__ - `[Python-checkins] python/dist/src/Lib/test regrtest.py, 1.171, 1.172 test_ioctl.py, 1.2, 1.3 <http://mail.python.org/pipermail/ python-dev/2005-September/056406.html>`__ - `python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2 <http:// mail.python.org/pipermail/python-dev/2005-September/056419.html>`__ - `Variant of removing GIL. <http://mail.python.org/pipermail/python- dev/2005-September/056423.html>`__ - `Compatibility between Python 2.3.x and Python 2.4.x <http:// mail.python.org/pipermail/python-dev/2005-September/056431.html>`__ - `Example for "property" violates "Python is not a one pass compiler" <http://mail.python.org/pipermail/python-dev/2005-September/ 056190.html>`__ - `python optimization <http://mail.python.org/pipermail/python-dev/ 2005-September/056425.html>`__

3 2

LXR site for Python CVS
by Hye-Shik Chang Oct. 22, 2005

Oct. 22, 2005

Hi, I just set up a LXR instance for Python CVS for my personal use: http://pxr.openlook.org/pxr/ If you find it useful, feel free to use the site. :) The source files will be updated twice a day. Hye-Shik

1 0

PEP 267 -- is the semantics change OK?
by Jim Jewett Oct. 21, 2005

Oct. 21, 2005

(In http://mail.python.org/pipermail/python-dev/2005-October/057501.html) Neil Schemenauer suggested PEP 267 as an example of something that might be easier with the AST compiler. As written, PEP 267 does propose a slight semantics change -- but it might be an improvement, if it is acceptable. Today, after from othermod import val1 import othermod val2 = othermod.val2 othermod.val3 # Just making sure it was referenced early othermod.val1 = "new1" othermod.val2 = "new2" othermod.val3 = "new3" print val1, val2, othermod.val3 The print statement will see the updated val3, but will still have the original values for val1 and val2. Under PEP267, all three variables would be compiled to a slot access in othermod, and would see the updated objects. In many cases, this would be a *good* thing. It might allow reload to be rewritten to do what people expect. On the other hand, it would be a change. Would it be an acceptable change? -jJ

2 1