Mailman 3 August 2004 - Python-Dev

python-dev Summary for 2004-08-01 through 2004-08-15 [draft]
by Brett C. Aug. 22, 2004

Aug. 22, 2004

Well, after reading 1,289 emails for this summary I finally finished it. As you will notice in the Summary Announcements I have my yearly stats on the list since this summary marks the end of year two for me doing this. As I did last year, the position is available to anyone who wants it and can do a comparable job. Also notice that in the Summary Announcements I am asking for people to vote on one of two ways I am going to cut back on the amount of time the Summaries take up of my time. If you actually read the summaries then do let me know since votes from regular python-dev'ers will count for more than from the general Python community. I don't plan to send this summary out any sooner than Sunday night so you have at least until then to send me corrections. I am burned out enough at the moment that I doubt I will hit that date, though. Also, I doubt I covered anything new in my decorators summary, but if I did let me know and I will make sure to plug it into the PEP or wiki if needed. --------- ===================== Summary Announcements ===================== Well, I have now been doing the summaries for two years. As has become a yearly tradition, I am offering to pass on the writing of the summaries to someone else. My only requirement is you do a comparable job. You do learn *tons* about Python's internals when you have to research a topic to be able to summarize it. I know it greatly accelerated my understanding of both Python as a language and of its implementation. With that said, it is also time for stats on the list to scare away anyone considering taking over this job =) . According to my probably buggy script that I wrote last year, I have read 10,190 emails over the past year (this month has already been the busiest month with 1,289 emails and it is only half over; could set the record for busiest month ever). The people with over 300 emails posted over the year are: 9. Michael Hudson (303) 8. Martin v. Lowis (307) 7. Barry Warsaw (341) 6. Phillip J. Eby (341) # not a typo; same number as Barry 5. Greg Ewing (354) 4. Raymond Hettinger (372) 3. Skip Montanaro (399) 2. Tim Peters (629) 1. Guido van Rossum (1031) These 9 people make up over 40% of all the emails from the past year. Longest threads were: 1. decorate-sort-undecorate (694 emails) 2. Call for defense of @decorators (195 emails) 3. PEP 318: Decorators last before colon (181 emails) 4. redefining is (162 emails) 5. Christmas Wishlist (162 emails) These stats along with the insane amount of email has showed me something; the Summaries have detracted from my participation on python-dev this past year. I have a bigger mouth and more opinions than the number of emails I sent to the list show. This means something has to change, and it isn't going to be my mouth. The Summaries need to change in one of two ways. Option one is that I focus in on certain areas of interest and skip other ones. I have labeled all of the summaries below with what their type is right under the titles. Please email me your top ares of interest. I realize that this month may not be typical but pretty much all areas are covered at least once so at least there is a good taste for the different areas. So, choose from: 1. improvement stuff Pretty much anything that is not a major change to the language/stdlib. Usually something you find out from the Misc/NEWS or the "What's New" doc. 2. how python-dev works Stuff like how python-dev handles things such as the PEP process, coding style, etc. 3. nuggets of info Cool tricks and ideas that come up on the list that the greater world probably does not know. 4. minor language change Stuff that deals with the language changing, but is not significant; such as discussions of existing PEPs. Language evolution stuff (such as decorators) will always be covered so you don't need to vote on that. If people like this first option then I will make sure I cover the area with most votes and everything else is just considered icing. Option two out of all of this is people just say, "summarize what you want, Brett." Then I just cover what I find interesting and just don't worry about covering a specific area. I obviously prefer this option but if people really care about a specific area I want to make sure to cover it. What will most likely happen is I will still cover almost everything but the thoroughness will be lower. I will go more off of memory for example. But something will change. Being on the sidelines for the decorators discussion because I dreaded having to start reading all of those emails in terms of summarizing is not acceptable (and no, I can't just ignore some of them since that is just not how I work). Having to read 1,289 emails for just the first two weeks of this month finally caused me to lose my sanity. ======== Summary ======== -------------------------------------------------------------------------------- Multiple interpreters at a time in a C program kind of broken -------------------------------------------------------------------------------- 3. nuggets of info Philip Eby thought he might have a fix for a known limitation of running multiple interpeters at once (using PyInterpreter_New() ) and having imports not being clearly separated between interpreters. But Martin v. Löwis popped Philip's bubble somewhat by saying that he and some other people viewed multiple interpreter support as inherently broken. Contributing threads: - `Safe to change a thread's interpreter? <http://mail.python.org/pipermail/python-dev/2004-August/046593.html>`__ -------------------------------------------- Another sucker becomes an official developer -------------------------------------------- 2. how python-dev works Sean Reifschneider took the bait to become another one of Guido's minions. Sean has been maintaining the RPM spec files for quite a while. Contributing threads: - `New developer <http://mail.python.org/pipermail/python-dev/2004-August/046595.html>`__ ---------------------------------------- Discovering leaks with a regrtest wrench ---------------------------------------- 1. minor language change Michael Hudson, who found and fixed a bunch of refcount leaks shortly after 2.3 was released, used his magical regrtest patch (which has subsequently been checked in) to hunt down leaks for 2.4 . A bunch of tests were cleaned up to make them not raise false-positives along with fixing some true leaks. Contributing threads: - `refleak hunting season <http://mail.python.org/pipermail/python-dev/2004-August/046611.html>`__ --------------------------------- Another Bug Day has come and gone --------------------------------- 2. how python-dev works The Bug Day held on August 7 led to 19 bugs and 12 patches being closed. You can see the results at http://www.python.org/cgi-bin/moinmoin/PythonBugDayStatus . Feel guilty for not being able to make it? Still want to help? Go to that page to see bugs that could use some squashing that shouldn't be too difficult to deal with. Contributing threads: - `Bug day coming up this Saturday <http://mail.python.org/pipermail/python-dev/2004-August/046645.html>`__ -------------------------------------------------- How to shut a compiler up about an unused variable -------------------------------------------------- 3. nuggets of info Tim Peters had come up with some optimizations for list.pop() that avoided unneeded test+branches. The problem is that it led to a variable possibly being unused. C compilers tend to complain about that and so an initial solution was used. Unfortunately gcc complained about it, and so yours truly came up with one. But that solution was labeled as "perverse" (and it was; total hack solution), so another solution was found thanks to Sjoerd Mullender by just taking the variable and casting it to void. Contributing threads: - `RE: [Python-checkins] python/dist/src/Objects listobject.c, ... <http://mail.python.org/pipermail/python-dev/2004-August/046678.html>`__ ------------------------------------------------------ Variable sequence unpacking assignment shot down again ------------------------------------------------------ language evolution David Cole suggested adding the ability to have sequence unpacking assignment just like *args for parameters; ``a, b, *c = (0, 1, 2, 3, 4, 5) # a == 0, b == 2, c == (3, 4, 5)``. This idea got a -1 from Guido as not really needed. That reaction makes Guido consistent; the idea was originally shot down back in Nov. 2002; http://www.python.org/dev/summary/2002-11-16_2002-11-30.html#half-baked-pro… . If you really like that idea the previous summary contains a function that helps you do this in a way. Contributing threads: - `Tuple/list assignment question <http://mail.python.org/pipermail/python-dev/2004-August/046684.html>`__ ------------------------------------------------------------------------------------- Changing the Big-O complexity for something in the language is now a language feature ------------------------------------------------------------------------------------- language evolution Armin Rigo came up with a way to have string concatenation in a loop (think ``for thing in iter_of_strings: concat_str += thing``) not be a quadratic algorithm thanks to some trickery for ``a = a + b`` and ``a += b`` conditions for strings. The hope was to remove the (commonly considered) wart of having ``"".join(iter_of_strings)`` be the suggested way to concatenate a bunch of strings. But Guido didn't like the patch. His reasoning was that changing something that led to a change in the Big-O complexity of certain algorithms would inherently hurt other implementations of Python when people would start to code specifically for that performance gain. For instance, having Jython be able to pull this trick off is, I believe, near impossible. So, in order to make sure changes like this are considered before applying them, Guido instated a new rule that "implementation features that affect not just the running speed but the O() rate for certain algorithms should be considered language features, because any implementation will be required to implement them in order to ensure code portability" between implementations of Python. In the end, though, this went in with a warning that the speed performance is not portable. It is not to be used in the stdlib ever. Contributing threads: - `Optimized string concatenation <http://mail.python.org/pipermail/python-dev/2004-August/046686.html>`__ - `PEP 0008 confusion - here it is, but don't use it? <http://mail.python.org/pipermail/python-dev/2004-August/047194.html>`__ ------------------------------------------------------------------------------- Bet you didn't think about string interning and how that affects .pyc, did you? ------------------------------------------------------------------------------- 1. minor language change Luckily Martin v. Löwis did. A patch was originally applied to not intern strings representing filenames. Problem is that every code object stores that string, so it increases .pyc files since it has to store multiple copies of that string instead of just one. Contributing threads: - `Re: [Python-checkins] python/dist/src/Python compile.c ... <http://mail.python.org/pipermail/python-dev/2004-August/046703.html>`__ ------------------------------------------------------------------------------ `PEP 324`_ (process - New POSIX process module) != process.py from ActiveState ------------------------------------------------------------------------------ 1. minor language change Guido asked if the APIs between the module proposed in `PEP 324`_ and the process.py module by Trent Mick of ActiveState were compatible. Turns out they are not. Then the discussion went into select(), broken pipes, and other stuff not relevant to the OP. =) .. _PEP 324: http://www.python.org/peps/pep-0324.html Contributing threads: - `PEP 324 (process module) <http://mail.python.org/pipermail/python-dev/2004-August/046707.html>`__ -------------------------------------------------------------------------------------------------------------------------------------------------- Getting it so string literals accept those nutty non-ASCII characters more easily (and getting files to be more upfront about their Unicode-ness) -------------------------------------------------------------------------------------------------------------------------------------------------- language evolution François Pinard asked what people thought about two things related to Unicode. First, he thought having a __coding__ attribute for files that contained the encoding of the text would be nice. Martin v. Löwis said it would be possible. MA Lemburg added his vote of support. It has not been implemented to my knowledge yet, though. The second idea was to have a directive of some sort on a per-module basis so that all string literals could be considered in something other than ASCII. Once again Martin said it was doable with MA saying he liked the idea. But it was pointed out that you might as well just use the 'u' in front of strings now. This led to a slight discussion on good i18n practices. Both Martin and MA seemed to suggest that if you are going to be doing most of your work in a single encoding then just use that and declare everything Unicode. ANd if you are going to support a lot of different languages, use gettext and such. Martin also stated it is best to get text into Unicode ASAP and then only convert to the final encoding at the last moment. Contributing threads: - `Python in Unicode context <http://mail.python.org/pipermail/python-dev/2004-August/046727.html>`__ ---------------------------------------------------------------------- An exception is an exception, unless it doesn't inherit from Exception ---------------------------------------------------------------------- language evolution Coming up in a discussion on Unicode of all things, a discussion on moving exceptions over to new-style classes came up. Guido pointed out that moving over to new-style classes would seem to suddenly require that anything passed to 'raise' be a new-style class and that goes against the current acceptance. But in comes Paul Prescod with his argument that exceptions are inherently organized based on inheritance and thus requiring things being passed to 'raise' subclass Exception somewhere is not that big of a thing. Guido really liked that point. So if it goes this way and you don't like it blame Paul (who is a nice guy, so go easy on him =). And then along come Holger Krekel bringing up the point that using exceptions to do non-standard flow control is handy. But the question was asked as to why he couldn't still just subclass Exception? Was it that big of a deal? He admitted it wasn't and said when the name Raisable was suggested that would make it easier. Michael Hudson then came in and wrote up a hacked-up patch to turn exceptions into new-style classes. Most stuff seemed to still work. Python 3 was already going to switch to new-style classes for exceptions and string exceptions have already been deprecated. Now add to the mix the possible requirement that anything passed to 'raise' require a common base class. Contributing threads (note that the thread starts part way in a thread on Unicode and end before the end of the full thread): - `Python in Unicode context <http://mail.python.org/pipermail/python-dev/2004-August/046757.html>`__ ------------------------- Python 2.4a2 out the door ------------------------- language evolution Python 2.4a2 has been released. As usual, please download it and test it with your code along with the regression test suite. Contributing threads: - `trunk frozen for 2.4a2 <http://mail.python.org/pipermail/python-dev/2004-August/046822.html>`__ - `RELEASED Python 2.4, alpha 2 <http://mail.python.org/pipermail/python-dev/2004-August/046864.html>`__ ------------------------------------------------------- Amendment to how to compile with the free .NET compiler ------------------------------------------------------- 3. nuggets of info Nick Coghlan expanded upon my summary on how to compile with the free .NET compiler under Windows at http://www.python.org/dev/summary/2004-07-16_2004-07-31.html#how-to-get-pyt… . See his email at http://mail.python.org/pipermail/python-dev/2004-August/047215.html on the extra steps. Or just move to another OS. Contributing threads: - `python-dev Summary for 2004-07-16 through 2004-07-31 [draft] <http://mail.python.org/pipermail/python-dev/2004-August/047215.html>`__ -------------------------------------- Darned Solaris, g++, and _XOPEN_SOURCE -------------------------------------- 1. improvement stuff Skip Montanaro discovered that building under Solaris with g++ raised a warning about redefining _XOPEN_SOURCE. pyconfig.h defines it, but apparently so does g++ in order for Solaris' toolchain to expose some code that is only available if it is defined. Martin v. Löwis came up with a couple of suggestions on how to handle this. Skip ended up going with the idea of setting _XOPEN_SOURCE to the same value as it is defined by g++. Contributing threads: - `use of #pragma GCC system_header to suppress _XOPEN_SOURCE warnings <http://mail.python.org/pipermail/python-dev/2004-August/046955.html>`__ ------------------------------------------------------------------------------------- pre-PEP on a function for re that "captures matches for groups that match repeatedly" ------------------------------------------------------------------------------------- 1. minor language change Mike Coleman presented a pre-PEP on adding a function to re that would create a tree (in the form of a list) containing all group matches in a string. It got a little support, but the discussion quickly moved over to dreamings of a full-on scanner or parser package for the stdlib. But if the idea of the PEP works for you then speak up on c.l.py . Contributing threads: - `pre-PEP: Complete, Structured Regular Expression Group Matching <http://mail.python.org/pipermail/python-dev/2004-August/047042.html>`__ --------------------------------------- Making ourselves follow the PEP process --------------------------------------- 2. how python-dev works It was noticed early on that the PEP process had broken down for `PEP 318`__ (decorators). What should happen is a PEP gets written (and the author becomes its champion), there is a public discussion, the PEP is updated, that's repeated until it is deemed done, gets get BDFL pronouncement, if Guido okays it the code goes in. Unfortunately the part about updating the PEP didn't really happen. This led to two major things being stated and generally agreed upon. One is that PEPs should not be checked in if the PEP has not been updated. While a minor nit is not a reason to hold back code, not updating after a major public debate is not acceptable. This directly segued into the other point of a PEP needs to have a champion, period. Since the developers on python-dev do not have the time to keep PEPs updated it is up to the PEP champion to make sure it is kept current. If it isn't it is take to mean the champion no longer cares, which means python-dev no longer cares, which means the PEP gets rejected outright. This will also make sure that there is a focus to the design of what the PEP wants and does not lead to a design-by-committee problem. .. _PEP 318: http://www.python.org/peps/pep-0318.html Contributing threads: - `PEP 318, and the PEP process <http://mail.python.org/pipermail/python-dev/2004-August/047020.html>`__ ---------------------------------------------------------------- How to tell Windows from Linux without lifting up anyone's skirt ---------------------------------------------------------------- 3. nuggets of info The question came up on what the best way was to tell what platform you are running on. The answer came down to why you were cared. If it was whether or not you had a specific functionality (or lack thereof), then just test for the functionality. If you had other needs, though, using sys.platform seemed to be the most reliable way (at least for Windows since all of them use 'win32'). Contributing threads: - `Asyncore .set_reuse_addr() on Windows <http://mail.python.org/pipermail/python-dev/2004-August/047269.html>`__ ----------------------------------------- func_name can now have an identity crisis ----------------------------------------- 1. improvement stuff Thanks to the rampant decorator discussion, Skip Montanaro came up with the idea of wanting func_name to be writable. This would allow decorators to wrap a function with another function and yet reset func_name to its original value, thus not having the wrapper function become the prevailing name. Guido liked and Michael Hudson subsequently wrote up `patch #1004703`_. .. _patch #1004703: http://www.python.org/sf/1004703 Contributing threads: - `PEP 318 - writing to func_name attribute <http://mail.python.org/pipermail/python-dev/2004-August/047097.html>`__ ----------------------------------------- statistics.py ain't goin' into the stdlib ----------------------------------------- 1. improvement stuff Raymond Hettinger (at the last Python Bug Day) made the statement that he didn't think 'statistic's should be taken out of the sandbox in CVS and put into the stdlib. He felt that most of the important algorithms were available elsewhere (such as nsmallest and nlargest in the heapq module) and the remaining functions that were not found anywhere were not that critical. He did say, though, he would like to do a calculator module where those remaining functions could go. Contributing threads: - `status of statistics.py? <http://mail.python.org/pipermail/python-dev/2004-August/047129.html>`__ ------------------------------------ Making re.split care about emptiness ------------------------------------ 1. improvement stuff Mike Coleman wrote up a patch for re.split() that AM Kuchling presented to the list. It adds an argument to the function to allow an empty string to be put into the resulting list when a match occurs, even if the match consumes no characters. No decision on the exact semantics of the function, how to handle turning on the new functionality (some say an extra argument, some say adding another bit flag like traditional re arguments), or even if it will be accepted. Contributing threads: - `re.split on empty patterns <http://mail.python.org/pipermail/python-dev/2004-August/047272.html>`__ ---------------------------------------- Pickler's 'bin' argument on its last leg ---------------------------------------- 1. improvement stuff As per `PEP 307`_ (Extensions to the pickle protocol), the 'bin' argument is being upgraded from PendingDeprecationWarning to DeprecationWarning; so it's gone plaid and the only way to stop it is with some emergency change. Contributing threads: - `Pickler()'s bin argument <http://mail.python.org/pipermail/python-dev/2004-August/047274.html>`__ --------------------------------- Some modules are getting the boot --------------------------------- 1. improvement stuff TERMIOS, mpz, statcache, xreadlines and rotor are all being removed. mimify, MimeWriter, and whrandom will raise a DeprecationWarning. rfc822 and mimetools will not be raising DeprecationWarning as specified by `PEP 4`_ since some code in the stdlib still uses it. .. _PEP 4: http://www.python.org/peps/pep-0004.html Contributing threads: - `Removing stuff from 2.4 <http://mail.python.org/pipermail/python-dev/2004-August/047308.html>`__ ------------------------------------------------- Should decimal.Context.copy() be deep or shallow? ------------------------------------------------- 1. improvement stuff Raymond Hettinger brought up the question of whether decimal.Context.copy() should be a deep or shallow copy. While tradition dictates it be shallow based on name, it seems like the functionality should be deep. No one wants context to be shared between number naturally since numbers tend to be viewed as unique things. Staring in 2.4a3 it will be deep unless people come up with reasons to switch it to shallow. Contributing threads: - `decimal.Context.copy() shallow or deep? <http://mail.python.org/pipermail/python-dev/2004-August/047416.html>`__ ---------------------------------------------------------- The dark corners of Python allow you to skip return values ---------------------------------------------------------- 3. nuggets of info Christian Tismer discovered that you can actually stop a return statement from returning if you encase it in a 'finally' block and tweak it slightly (see the OP to get what I mean by this). Turns out this is a reliable feature of Python if you really want to use it. Contributing threads: - `capturing RETURN_VALUE <http://mail.python.org/pipermail/python-dev/2004-August/047360.html>`__ -------------------------------------- Is an int/long combined type worth it? -------------------------------------- language evolution Dmitry Vasiliev pointed out that `PEP 237`_ (Unifying Long Integers and Integers) mentioned that a a new type named 'integer' might be introduced that subclassed both int and long. The discussion waivered between whether it was at all needed, and if it was if it should be a true type or just a tuple containing both types for use with isinstance() . No conclusion was reached in the end. .. _PEP 237: http://www.python.org/peps/pep-0237.html Contributing threads: - `Unifying Long Integers and Integers: baseint <http://mail.python.org/pipermail/python-dev/2004-August/047404.html>`__ -------------------------------------- Should byte arrays be a built-in type? -------------------------------------- language evolution Through the discussion bout having a common type combining int and long a discussion on whether a byte array type should be introduced. The initial suggestion was for it to be practically synonymous with str since str itself stores everything as an array of 8-bit values. The use cases would be for streams and such that just want a stream of bytes with no care for any encoding. Syntactically, having a 'b' and 'B' cookie before literals was suggested. The issue with this, though, is that byte arrays should be mutable, which would make literals that can be mutated, and that is frowned upon by Guido. Semantically, aliasing bytes to the str type was suggested. That was not loved since that could create confusion. Returning an object from 'array' was suggested and seemed okay. In general it seemed this could be useful and could go in 2.5, but nothing for 2.4 . Contributing threads: - `Unifying Long Integers and Integers: baseint <http://mail.python.org/pipermail/python-dev/2004-August/047665.html>`__ ----------------------------- Thar the Windows stack blows! ----------------------------- 1. minor language change Running the new test_compiler test (if you run it with ``-uall`` for regrtest it will recompile the entire stdlib) was leading to an odd failure: the "process on Windows "just vanishes" without a trace, and without an error message of any kind, but with an exit code of 128". After a lot of work put in by a bunch of people (led by Tim Peters) the problem was tracked down to a blown C stack. Turned out that the stack-checking code was not being called frequently enough to pick up the error. The problem with this was that it was leading to odd errors that should have been MemoryError but were manifesting themselves as KeyError. This was because PyDict_GetItem() was failing and return NULL which is the same as signaling the key doesn't exist in the dict. Trick was trying to come up with a good way to deal with this. Adding more calls would be very expensive (reliable way of catching it was sticking a check in pymalloc code) and so that was ruled out. PyDict_GetItem() couldn't change its return value since that would break more code than could be imagined. So, in the end, the stack was increased to 2 MB on Windows. Contributing threads: - `Another test_compiler mystery <http://mail.python.org/pipermail/python-dev/2004-August/047468.html>`__ ------------------------------------------ Someone else falls for the dangling carrot ------------------------------------------ 2. how python-dev works Johannes Gijsbers now has checkin rights. May he close many bugs. Contributing threads: - `New Developer <http://mail.python.org/pipermail/python-dev/2004-August/047815.html>`__ ---------------------------------------------------------- Lying about being in __builtin__ is not always a bad thing ---------------------------------------------------------- 1. improvement stuff James Knight noticed that some objects (mostly C types such as iterators for the built-in types and such) claim in their __module__ attribute that they come from __builtin__ which is not technically correct since you can't access them from there. The desire to fix this came from allowing for proper introspection. The leading idea is to put these types in __builtin__ properly so that they are no longer lying about where they come from. Contributing threads: - `Classes that claim to be defined in __builtin__ but aren't <http://mail.python.org/pipermail/python-dev/2004-August/047477.html>`__ --------------------------------------------------------- Bringing order to the order of application for decorators --------------------------------------------------------- 1. minor language change Turns out that the order of application for decorators was implemented in the reverse order of what it was supposed to be in 2.4a2 . Luckily James Knight spotted this and let the list know. It has been fixed, though, in CVS and now follows `PEP 318`_ to apply in bottom-up order:: @first @second def blah(): pass is equivalent to:: blah = first(second(blah)) The arguments for this ordering beyond it just making more sense to Guido and others is that people will typically put decorators such as staticmethod and classmethod first. Going with the original order would have led to errors in most situations if people were not expecting to be receiving a class or static method to be passed to the other decorators. There was a short discussion on the order of instantiation for the decorators, but in the end the order chosen was the order listed; first would be first() instantiated followed by second(). Contributing threads: - `Decorator order implemented backwards? <http://mail.python.org/pipermail/python-dev/2004-August/047512.html>`__ ----------------------------------------------------------------------------------- PEP 292 (Simpler String Substitutions) getting gussied up for the Python 2.4a3 ball ----------------------------------------------------------------------------------- 1. minor language change `PEP 292`_'s implementation got fixed up. The names of the class names were changed to Template and SafeTemplate, the whole process was made lazy, and just cleaned up in general (solution is small, simple, and rather cool; all subclassable and works with Unicode to boot). But then questions over the merits of $-based string interpolation popped up. People wondered if going from ``%(blah)s`` to ``${blah}`` was worth it. The answer is "yes". And that is just worst case; when you just want ``$blah`` you get an even bigger win. The other question was over whether the string module should become a package. The original idea was to stick the original string module in as a submodule of the package and the Template code in another module. This would allow easy removal of the 'string' module code that has been deprecated for eons. Barry Warsaw (author of the PEP) asked Guido to make the call on this, but he hasn't had the time yet to get to this. .. _PEP 292: http://www.python.org./peps/pep-0292.html Contributing threads: - `PEP 292 <http://mail.python.org/pipermail/python-dev/2004-August/047580.html>`__ -------------------------------- Multi-line imports get clarified -------------------------------- 1. minor language change Multi-line imports will only accept parentheses around what is being explicitly imported and only if there is more than one item being imported. Trailing commas are also to be accepted. Contributing threads: - `Multi-line import implementation (first part) <http://mail.python.org/pipermail/python-dev/2004-August/047393.html>`__ - `Multi-line import implementation (second part) <http://mail.python.org/pipermail/python-dev/2004-August/047614.html>`__ - `Naming nit <http://mail.python.org/pipermail/python-dev/2004-August/047641.html>`__ ------------------------------------------------ For those of you who need Python to run on Win64 ------------------------------------------------ 3. nuggets of info Nick Bastin asked if anyone has gotten Python 2.3 to work under Win64. Martin v. Löwis said "yes" for Python 2.4, but not for 2.3 . He suggested to Nick that he run vsextcomp_ to generate the targets on the 2.4 VC 7 build files and then move that over to 2.3 . .. _vsextcomp: http://www.sf.net/projects/vsextcomp Contributing threads: - `2.3.4 on Win64? <http://mail.python.org/pipermail/python-dev/2004-August/047631.html>`__ ---------------------------------------------- Sometimes concealing the truth is a good thing ---------------------------------------------- 1. improvement stuff Nick Coghlan discovered that some of the function in the 'commands' module did actually work under Windows and he wanted to make sure it was okay to fix another module to work under Windows and to document the fact. But the whole idea was shot down by both Tim Peters and Guido in order to keep the module simple. Keeping the whole thing UNIX-only is much easier than having an API that is only partly compatible with Windows (and with only certain versions of Windows at that). Guido also said that the module would not even be accepted today since it doesn't add enough functionality. Contributing threads: - `'commands' module on Win32 <http://mail.python.org/pipermail/python-dev/2004-August/047774.html>`__ ---------------------------------------------- atexit module, good; sys.exitfunc, not so good ---------------------------------------------- 1. improvement stuff Raymond Hettinger pointed out that the docs for the atexit module state that sys.exitfunc was to be deprecated. Well, atexit has been in the stdlib since 2.0 so the deprecation is long overdue. Looks like it will get its deprecation finally. Contributing threads: - `Deprecate sys.exitfunc? <http://mail.python.org/pipermail/python-dev/2004-August/047842.html>`__ ---------------------------------------------------------------------------------------------- My Personal Hell: decorators and the people who suggest new syntax for them... next, on Oprah ---------------------------------------------------------------------------------------------- language evolution What led to a record-setting flurry of emails to python-dev was set up when Guido gave the green light to checking in code to implement decorators using the '@' syntax (now known at the pie syntax thanks to its checkin coming very shortly after the OSCON Pie-thon competition and '@' sort of looking like a pie). People didn't like it. People were screaming that there had to be a better syntax than just settling for the least offensive one. Others started to question whether decorators were really needed. Others wanted to extend them even more and what their role truly was. Either way this was all coming a little late. But then Guido decided to make my life difficult by saying that if the community could come up with an agreed-upon alternative syntax to propose to him he would consider ripping out the '@' syntax; decorators have always been experimental and '@' was checked in so people had *something* to play with. This meant everyone and their mother started to propose both new and old syntaxes for decorators. This led to a record amount of email on python-dev (at least compared to what we have archives for; back to April 1999). In order of my own personal sanity I am not going to cover any specific syntax. There are just too many and I actually like the '@' syntax (just *try* using it; it grows on you quickly). Instead this summary will cover any important design considerations for decorators (it should all be in the PEP but so much happened there is no way it all got in there) along with any other important considerations about them. I will discuss anything specific to the '@' syntax since it is the currently winning syntax. With that said, `PEP 318`_ and the PythonDecorators_ wiki page are the de-facto place for info on this whole situation. I am probably going to be more biased than normal in this summary just out of time restraints to get this done by not over-analyzing people's suggestions and just assuming what I summarize here is not covered elsewhere; checking if it is would take too long. First off, going with a syntax just so you could add backward-compatible support was not considered worth it. It's a new feature so there is no need to hobble it at the get-go just so people who don't want to upgrade can still use it. Plus the implementations to make this even possible were playing some tricks with the interpreter and not considered a good thing. Besides you can, always will be able to, still use the way to do it in 2.2 and beyond. Another design point that needed to be taken into consideration was ambiguity. There could not be a question about what is a decorator and what isn't (list-before-def is an example of a syntax that can be ambiguous). Syntactic support that allowed for possible future compiler optimizations was also considered important. The on-going hope is to eventually get a JIT compiler for Python and if the decorators are not placed before the def somehow you make it much harder to optimize since you learn about the decorators after the fact of the function starting to be defined. An argument against '@' was that people thought it got rather unwieldy quickly (and I am sure the new decision that each decorator must be on its own line is not making these objectors happy). But one thing that must be remembered is that chances are most functions will not need more than one decorator if the even need one. Looking through the stdlib sans the test suite you will notice there are not a lot of uses for any of the built-in decorators. Yes, usage will probably grow with syntactic support for decorators, but not exponentially in terms of applying multiple decorators to a single function. Allowing decorators to take arguments is a requirement. Not being able to pass arguments to a decorator at instantiation time would severely cripple their usefulness. Being prefix instead of postfix was considered important. Knowing about what is coming up was something Guido thought is better than finding out about some special tweak to the use of a function based on a decorator listed after the definition line. And in the method body had been completely ruled out. In terms of implementation details, decorators can only be functions directly (and not lambda). This means no ``@a or b`` tricks and such. It also means ``(a)foo().bar()`` is not allowed. This is all gut feeling from Guido for why the restriction should be there. It could change in the future since it is easier to loosen restrictions that make something more strict. A problem with '@' in terms of portability is that Leo_ and IPython_ both use '@' for special syntax. The authors of both tools seem willing to change their tools (not necessarily overly joyous, though =) . Guido wanted a syntax "that ... [is] easy to remember once explained". It did not need to be miraculously obvious what it did just by looking at the first time. Some people didn't like '@' because they keep wanting to say "at" when they saw it. To that, I give you Tim Peters' fix for this: "Pick the keyword you'd like. Then whenever you see "@", pronounce that word instead <wink>". A single decorator that applied to multiple code blocks is completely out. Guido gave a couple of reasons why, but one that he had mentioned multiple times is indenting the code block again just for the decorator is out. Some people suggested that things be kept simple by just throwing out the entire idea of syntactic support. Could happen if everyone agreed to that, but I wouldn't count on it. A supposed knock against '@' was that it wasn't Pythonic. Well, it is Pythonic if Guido says it is so not really a valid argument. OK, tirade time. If you don't want to listen to me get up on my soapbox, then just skip the rest of this... "In the old days, Guido would Pronounce, and we'd all bite our tongues (although not necessarily each his own). The less time Guido can make for Python, the more important becomes graceful capitulation." Tim said this and it makes me wish for the old days. People had *months* to comment on decorators and no one spoke up until something went into the language. Procrastination is not a virtue when it comes to major language evolution discussions. What was worse was when the emails started repeating themselves (which was pretty much from the get-go when this exploded). Seemed like people decided to start talking without doing some research. Granted the PEP was outdated and the wiki page was not up yet, but this stuff was covered in the Summaries before and you could have just Googled for the previous threads. Personally, if I was Guido, I would have said that the community had their chance to speak up and they just didn't take it. But Guido is a nicer guy than that so people are getting a second chance with this. Personally this came off a great case of the tyranny of the majority in my eyes. There is a reason why Python is a dictatorship. At this point people should be hashing out which syntax alternative they want to present to Guido on comp.lang.python_. No more talking on python-dev, no more syntax proposals. The community should set a goal date (Sept. 1 seems good) and just choose a bloody alternative. Then when Guido makes his choice people accept it or just go to another language. No one had better voice their disappoint once Guido chooses his syntax or I will personally come beat you over with a stick for being a whiner. OK, that's out of my system. I feel better now. .. _PEP 318: http://www.python.org./peps/pep-0318.html .. _PythonDecorators: http://www.python.org/cgi-bin/moinmoin/PythonDecorators .. _Leo: http://leo.sourceforge.net/ .. _IPython: http://ipython.scipy.org/ Contributing threads (sans emails that were warnocked): - `2.4a2, and @decorators <http://mail.python.org/pipermail/python-dev/2004-August/046599.html>`__ - `Plea for simpler decorator syntax, in addition to pie-shaped syntax <http://mail.python.org/pipermail/python-dev/2004-August/046798.html>`__ - `Call for defense of @decorators <http://mail.python.org/pipermail/python-dev/2004-August/046878.html>`__ - `@decorators, the PEP and the "options" out there? <http://mail.python.org/pipermail/python-dev/2004-August/046905.html>`__ - `About pep 318--Intro <http://mail.python.org/pipermail/python-dev/2004-August/046918.html>`__ - `Questions about '@' in pep 318 <http://mail.python.org/pipermail/python-dev/2004-August/046934.html>`__ - `A usability argument for list-after-def <http://mail.python.org/pipermail/python-dev/2004-August/046935.html>`__ - `The impact of '@' on Leo <http://mail.python.org/pipermail/python-dev/2004-August/046937.html>`__ - `Similar syntax <http://mail.python.org/pipermail/python-dev/2004-August/046969.html>`__ - `def fn (args) [dec,dec]: <http://mail.python.org/pipermail/python-dev/2004-August/047112.html>`__ - `pep 318, Decorators for Functions, Methods and Classes <http://mail.python.org/pipermail/python-dev/2004-August/047132.html>`__ - `Density of pie-decorator syntax <http://mail.python.org/pipermail/python-dev/2004-August/047154.html>`__ - `elements of decorator syntax suggestions <http://mail.python.org/pipermail/python-dev/2004-August/047185.html>`__ - `318: Annotation background <http://mail.python.org/pipermail/python-dev/2004-August/047218.html>`__ - `IPython, @, and option E from the wiki <http://mail.python.org/pipermail/python-dev/2004-August/047223.html>`__ - `Decorators: vertical bar syntax <http://mail.python.org/pipermail/python-dev/2004-August/047231.html>`__ - `Suggesting '.' decorators (PEP318) <http://mail.python.org/pipermail/python-dev/2004-August/047234.html>`__ - `Attribute strings? <http://mail.python.org/pipermail/python-dev/2004-August/047362.html>`__ - `request: add keywords for static and class methods only <http://mail.python.org/pipermail/python-dev/2004-August/047498.html>`__ - `@decorator syntax is sugar, but for what exactly? <http://mail.python.org/pipermail/python-dev/2004-August/047500.html>`__ - `Semantics of decorators? <http://mail.python.org/pipermail/python-dev/2004-August/047623.html>`__ - `A decorator syntax not yet mentioned (I think!) <http://mail.python.org/pipermail/python-dev/2004-August/047625.html>`__ - `Another approach to decorators. <http://mail.python.org/pipermail/python-dev/2004-August/047647.html>`__ - `Decorators after 'def' should be reconsidered <http://mail.python.org/pipermail/python-dev/2004-August/047637.html>`__ - `def ... decorate <http://mail.python.org/pipermail/python-dev/2004-August/047781.html>`__ - `Decorator syntax J2 (decorate..def) <http://mail.python.org/pipermail/python-dev/2004-August/047807.html>`__ - `Decorators and docstrings <http://mail.python.org/pipermail/python-dev/2004-August/047827.html>`__ - `block-based decorators and other block issues <http://mail.python.org/pipermail/python-dev/2004-August/047839.html>`__ - `More concerns about decorators <http://mail.python.org/pipermail/python-dev/2004-August/047863.html>`__

3 2

re.split on empty patterns
by A.M. Kuchling Aug. 22, 2004

Aug. 22, 2004

The re.split() method ignores zero-length pattern matches. Patch #988761 adds an emptyok flag to split that causes zero-length matches to trigger a split. For example: >>> re.split(r'\b', 'this is a sentence')# does nothing; \b is always length 0 ['this is a sentence'] >>> re.split(r'\b', 'this is a sentence', emptyok=True) ['', 'this', ' ', 'is', ' ', 'a', ' ', 'sentence', ''] Without the patch, the various zero-length assertions are pretty useless; with it, they can serve a purpose with split(): >>> re.split(r'(?m)$', 'line1\nline2\n', emptyok=True) ['line1', '\nline2', '\n', ''] >>> # Split file into sections >>> re.split("(?m)(?=^[[])", """[section1] foo=bar [section2] coyote=wiley """, emptyok=True) ['', '[section1]\nfoo=bar\n\n', '[section2]\ncoyote=wiley\n'] Zero-length matches often result in a '' at the beginning or end, or between characters, but I think users can handle that. IMHO this feature is clearly useful, and would be happy to commit the patch as-is. Question: do we want to make this option the new default? Existing patterns that can produce zero-length matches would change their meanings: >>> re.split('x*', 'abxxxcdefxxx') ['ab', 'cdef', ''] >>> re.split('x*', 'abxxxcdefxxx', emptyok=True) ['', 'a', 'b', '', 'c', 'd', 'e', 'f', '', ''] (I think the result of the second match points up a bug in the patch; the empty strings in the middle seem wrong to me. Assume that gets fixed.) Anyway, we therefore can't just make this the default in 2.4. We could trigger a warning when emptyok is not supplied and a split pattern results in a zero-length match; users could supply emptyok=False to avoid the warning. Patterns that never have a zero-length match would never get the warning. 2.5 could then set emptyok to True. Note: raising the warning might cause a serious performance hit for patterns that get zero-length matches a lot, which would make 2.4 slower in certain cases. Thoughts? Does this need a PEP? --amk

7 9

RE: [Python-Dev] PEP 318: Can't we all just get along?
by Delaney, Timothy C (Timothy) Aug. 22, 2004

Aug. 22, 2004

Guido van Rossum wrote: >>> If the community can *agree* on >>> something they can support, I will listen. >> >> Even if it's []-after-args? > > If most people favor that over prefix @deco, sure, I'll give it > another look. (It better come with an implementation though.) Wasn't this the first implementation? Tim Delaney

1 0

Weekly Python Bug/Patch Summary
by Kurt B. Kaiser Aug. 21, 2004

Aug. 21, 2004

Patch / Bug Summary ___________________ Patches : 264 open (-20) / 2556 closed (+42) / 2820 total (+22) Bugs : 745 open ( +1) / 4384 closed (+23) / 5129 total (+24) RFE : 149 open ( +0) / 130 closed ( +0) / 279 total ( +0) New / Reopened Patches ______________________ baseinteger: abstract superclass for int and long (2004-08-11) http://python.org/sf/1007068 opened by Dmitry Vasiliev Return new string for single item joins (Bug #1001011) (2004-08-11) http://python.org/sf/1007087 opened by Nick Coghlan Multi-line imports implementation (2004-08-11) http://python.org/sf/1007189 opened by Dima Dorfman make inspect.getsource show @decorators (2004-08-09) http://python.org/sf/1006219 reopened by percivall Fix for bug #992078 (2004-08-11) CLOSED http://python.org/sf/1007539 opened by Mitchell Surface @decorators, including classes (2004-08-12) http://python.org/sf/1007991 opened by Jack Diederich patch for 767150 (2004-08-12) http://python.org/sf/1008086 opened by Mats Wichmann Let test__locale save locale (bug #992078) (2004-08-13) CLOSED http://python.org/sf/1008588 opened by Johannes Gijsbers (bug 952953) execve empty 2nd arg fix (2004-08-14) http://python.org/sf/1009075 opened by Dave Watson (bug 1005936) textunderscore python.sty fix (2004-08-14) http://python.org/sf/1009373 opened by Dave Watson Docstring fix in Modules/_csv.c (2004-08-15) CLOSED http://python.org/sf/1009384 opened by Cherniavsky Beni Non-ascii in non-unicode __credits__ in Lib/pydoc.py (2004-08-15) http://python.org/sf/1009389 opened by Cherniavsky Beni bottom-to-top decorator application order (2004-08-14) CLOSED http://python.org/sf/1009444 opened by Brett Cannon Fix @decorator evaluation order (2004-08-15) CLOSED http://python.org/sf/1009560 opened by Mark Russell Add missing types to __builtin__ (2004-08-16) http://python.org/sf/1009811 opened by James Y Knight PyErr_Clear() vs. AsynchronousException (2004-08-16) http://python.org/sf/1009929 opened by Armin Rigo thread Module Breaks PyGILState_Ensure() (2004-08-17) http://python.org/sf/1010677 opened by Phil Thompson Bad URL encoding in SimpleHTTPServer directory listing (2004-08-18) http://python.org/sf/1011123 opened by Niels Diepeveen regex nit in encoding declarations (2004-08-18) CLOSED http://python.org/sf/1011144 opened by George Yoshida SystemError generated by struct.pack('P', 'notanumber') (2004-08-18) http://python.org/sf/1011240 opened by Dima Dorfman Improve error reporting when Python opens source code (2004-08-18) http://python.org/sf/1011822 opened by Danny Yoo fix inspect.getsource breaking with line-continuation & more (2004-08-19) http://python.org/sf/1011890 opened by Simon Percivall Patches Closed ______________ Fix for bug #992078 (2004-08-11) http://python.org/sf/1007539 closed by jlgijsbers Match Solaris def'n of _XOPEN_SOURCE (2004-08-10) http://python.org/sf/1006629 closed by montanaro Remove ODBC library references from Windows build (2004-08-11) http://python.org/sf/1006916 closed by loewis support --with-tsc on PPC (2004-08-09) http://python.org/sf/1005891 closed by mwh Disambiguate "min() or max()" exception string (2004-08-08) http://python.org/sf/1005468 closed by loewis Make func_name writable (2004-08-06) http://python.org/sf/1004703 closed by mwh Patch to allow building of paper-*/dist.pdf (2004-08-09) http://python.org/sf/1005913 closed by nnorwitz Avoid seg fault if list object is modified during list.index (2004-08-09) http://python.org/sf/1005778 closed by nnorwitz Let test__locale save locale (bug #992078) (2004-08-13) http://python.org/sf/1008588 closed by jlgijsbers cgi.py and rfc822.py unquote fixes (2002-06-24) http://python.org/sf/573197 closed by jlgijsbers Adds cookie support to urllib2.py (2002-04-24) http://python.org/sf/548197 closed by jlgijsbers shutil.copyfile destroys hard links (Bug [ 851123 ]) (2003-12-05) http://python.org/sf/854853 closed by jlgijsbers realpath: resolve symlinks before normalizing (bug #990669) (2004-07-23) http://python.org/sf/996627 closed by jlgijsbers normpath symlinks doc warning (bug #990669) (2004-07-23) http://python.org/sf/996626 closed by jlgijsbers Docstring fix in Modules/_csv.c (2004-08-15) http://python.org/sf/1009384 closed by jlgijsbers bottom-to-top decorator application order (2004-08-14) http://python.org/sf/1009444 closed by bcannon Fixes for 'commands' module on win32 (2003-04-01) http://python.org/sf/713428 closed by jlgijsbers Make `commands' module work on Windows (2004-02-03) http://python.org/sf/889949 closed by jlgijsbers make commands.getstatusoutput work on windows (2002-12-31) http://python.org/sf/660505 closed by jlgijsbers Make commands.getstatusoutput work on Windows (2003-07-16) http://python.org/sf/772029 closed by jlgijsbers help() with readline support (2003-04-23) http://python.org/sf/726204 closed by jlgijsbers Fix @decorator evaluation order (2004-08-15) http://python.org/sf/1009560 closed by mwh extending readline functionality (2003-01-27) http://python.org/sf/675551 closed by montanaro fix inspect.getargs() crash on def foo((bar)) (bug #891637) (2004-08-08) http://python.org/sf/1005466 closed by doko email/Message.py: del_param fails when specifying a header (2004-01-08) http://python.org/sf/873418 closed by bwarsaw regex nit in encoding declarations (2004-08-18) http://python.org/sf/1011144 closed by loewis Fix for tkFont.Font(name=...) (2003-07-01) http://python.org/sf/764217 closed by loewis poor performance in xmlrpc response (2002-02-14) http://python.org/sf/517256 closed by loewis warn on assignment to None, True, False (2002-04-26) http://python.org/sf/549213 closed by loewis Oren Tirosh's fastnames patch (2002-08-20) http://python.org/sf/597907 closed by loewis PEP 269 Implementation (2002-08-23) http://python.org/sf/599331 closed by loewis factor out SMTPHandler.emit date handling (2003-08-20) http://python.org/sf/791776 closed by loewis add HTTPResponse.getheaders() (2003-09-04) http://python.org/sf/800236 closed by loewis Suggested change in how ntpath.expanduser works (2003-09-08) http://python.org/sf/802159 closed by loewis Lib/email/Encoders.py iso-2022 is 7bit (2003-09-12) http://python.org/sf/804885 closed by loewis socketmodule.c: fix for platforms w/o IPV6 (i.e.Solaris 5.7) (2003-11-19) http://python.org/sf/845306 closed by loewis inspect.getsource show @decorators (2004-08-09) http://python.org/sf/1006219 closed by jlgijsbers use just built python interp. to build the docs. (2003-10-15) http://python.org/sf/823775 closed by doko Missing INCREF in PyType_Ready (2004-06-26) http://python.org/sf/980082 closed by loewis Fix readline for utf-8 locales (2004-03-11) http://python.org/sf/914291 closed by loewis tarfile.py fix for bug #949052 (2004-07-21) http://python.org/sf/995126 closed by loewis fix for title case bug: #995422 (2004-07-22) http://python.org/sf/995740 closed by loewis New / Reopened Bugs ___________________ os.startfile() doesn't accept Unicode filenames (2004-08-11) http://python.org/sf/1007046 opened by Matthias Huening SGI (IRIX6.5.24) Problems building nismodule.c (2004-08-11) http://python.org/sf/1007223 opened by Maik Hertha SGI (IRIX 6.5.24) Error building _codecs_iso2022.c (2004-08-11) http://python.org/sf/1007249 opened by Maik Hertha os.getstatusoutput on win32 (2004-08-12) CLOSED http://python.org/sf/1008275 opened by Chmouel Boudjnah logging.getLevelName returns a number (2004-08-12) http://python.org/sf/1008295 opened by Paulo Eduardo Neves os.major() os.minor() example and description change (2004-08-12) http://python.org/sf/1008310 opened by Steven Incorrect <link rel="index"> href in Tutorial. (2004-08-13) CLOSED http://python.org/sf/1008690 opened by Johannes Gijsbers vertical bar typeset horizontal in docs (2004-08-13) http://python.org/sf/1008998 opened by Alan non-ascii readline input crashes python (2004-08-14) http://python.org/sf/1009263 opened by paul rubin Cannot doctest a SyntaxError (2004-08-15) CLOSED http://python.org/sf/1009729 opened by Raymond Hettinger xmlrpclib, PEP291, "yield" (2004-08-16) http://python.org/sf/1009803 opened by Anthony Baxter CPU usage shoots up with asyncore (2004-08-16) http://python.org/sf/1010098 opened by Thomas smtpd.py docstring says wrong default class (2004-08-16) http://python.org/sf/1010102 opened by Chris Green xml.dom documentation omits hasAttribute, hasAttributeNS (2004-08-16) http://python.org/sf/1010196 opened by Mike Brown sys.ps1 not protected in EditorWindow.py (2004-08-16) http://python.org/sf/1010370 opened by Dave Florek bsddb3 testsuite failure when running more than one time (2004-08-17) http://python.org/sf/1010645 opened by Matthias Klose test_queue fails occasionally (2004-08-17) http://python.org/sf/1010777 opened by Michael Hudson running test_codecmaps_* takes too much effort (2004-08-17) http://python.org/sf/1010952 opened by Ronald Oussoren distutils install with -b / --build-base (2004-08-18) http://python.org/sf/1011113 opened by daishi harada Make GIL acquire/release functions idempotent if PyEval_Init (2004-08-18) http://python.org/sf/1011380 opened by Gustavo J. A. M. Carneiro 2.4 asyncore breaks Zope (2004-08-18) http://python.org/sf/1011606 opened by Tim Peters distutils install with -b / --build-base (2004-08-18) CLOSED http://python.org/sf/1011687 opened by daishi harada GC assertion failure (2004-08-18) CLOSED http://python.org/sf/1011790 opened by Stephane Thiell Cannot import PKZIP 2.50 created ZIP file (2004-08-19) http://python.org/sf/1011893 opened by Dennis Chuah PyDoc does not support ZIP (2004-08-19) http://python.org/sf/1011894 opened by Dennis Chuah Bugs Closed ___________ IDLE and encodings (2003-09-18) http://python.org/sf/808719 closed by loewis Possible memory leak in output console (2004-08-10) http://python.org/sf/1006740 closed by akuchling FutureWarning when running regression tests (2004-08-09) http://python.org/sf/1006001 closed by akuchling _XOPEN_SOURCE issue on IRIX 5.3 (2004-08-08) http://python.org/sf/1005308 closed by loewis test_format fails 2.4a1 (2004-07-16) http://python.org/sf/992078 closed by jlgijsbers _SC_PAGE_SIZE unknown on IRIX 5.3 (2004-08-08) http://python.org/sf/1005568 closed by loewis HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin (2004-07-04) http://python.org/sf/985154 closed by nnorwitz new.code() not cleanly checking its arguments (2004-08-07) http://python.org/sf/1005248 closed by mwh os.getstatusoutput on win32 (2004-08-12) http://python.org/sf/1008275 closed by jlgijsbers Incorrect <link rel="index"> href in Tutorial. (2004-08-13) http://python.org/sf/1008690 closed by fdrake pdb doesn't find some source files (2003-05-15) http://python.org/sf/738154 closed by jlgijsbers inspect.getmodule symlink-related failur (2002-06-17) http://python.org/sf/570300 closed by bcannon inconsistent acceptance of floats for range() (2004-08-07) http://python.org/sf/1005325 closed by bcannon shutil.copy destroys hard links (2003-11-29) http://python.org/sf/851123 closed by jlgijsbers os.path.realpath() does not handle symlinks correctly (2004-07-14) http://python.org/sf/990669 closed by jlgijsbers misinforming help messages in pdb.py (2004-07-12) http://python.org/sf/989672 closed by jlgijsbers Carbon.CF.CFMutableArray hangs interpreter (2004-07-30) http://python.org/sf/1000914 closed by ronaldoussoren pydoc crashes on a class property (2004-02-06) http://python.org/sf/891637 closed by doko Cannot doctest a SyntaxError (2004-08-15) http://python.org/sf/1009729 closed by tim_one super instances don't support item assignment (2003-09-12) http://python.org/sf/805304 closed by rhettinger New module: doc versus action (2004-05-10) http://python.org/sf/951482 closed by rhettinger winzip cannot extrat tarfile created tars (2004-05-06) http://python.org/sf/949052 closed by loewis distutils install with -b / --build-base (2004-08-18) http://python.org/sf/1011687 closed by daishiharada GC assertion failure (2004-08-18) http://python.org/sf/1011790 closed by mbuna New / Reopened RFE __________________ translate Windows cr-lf when installing scripts on Linux (2004-08-06) http://python.org/sf/1004696 reopened by timcera RFE Closed __________ translate Windows cr-lf when installing scripts on Linux (2004-08-06) http://python.org/sf/1004696 closed by kbk

4 3

Reserved Characters
by Jim J Jewett Aug. 20, 2004

Aug. 20, 2004

Python does not currently reserve any characters for user extensions. One of the objections to @decorators is that it will cause problems for applications that used '@', simply because of it was one of only three characters that *might* be available. Newer String interpolation will also use up '$', which leaves only '?'. Is it time to reserve a character to the user, or at least to reserve some in certain contexts? Examples: """Python will not use '!' except as part of '!=' """, or """The '?' character is reserved for the user.""" -jJ _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

3 2

RE: [Python-Dev] Re: Update PEP 292
by Robert Brewer Aug. 20, 2004

Aug. 20, 2004

Tim Peters wrote: > I don't care. The minority of Americans who want to use $ in a > minority of templated strings in a minority of apps can learn to type > $$, or use the ironically named SafeTemplate instead (as suggested > earlier). > > > Template("Dear ${donor}, send $100.00 to the PSF template fund.") > > Which would trigger an exception, after which they type one character > to repair it: > > Template("Dear ${donor}, send $$100.00 to the PSF template fund.") Yep. Just like they (I mean "I") have to remember to write: td width="10%%" FuManChu

1 0

RE: [Python-Dev] decimal module portability to 2.3?
by Batista, Facundo Aug. 20, 2004

Aug. 20, 2004

[Skip Montanaro] #- Is it intended to remain 2.3-compatible for the forseeable #- future? It's not #- mentioned in PEP 291, nor is there any discussion of #- portability to 2.3 in #- PEP 327. I don't have plans to do some effort to keep it "2.3-runnable" when Py2.4 hits the street. Don't know if Raymond or somebody will preocupate about this. Could decimal be backported to 2.3 and be included in some 2.3.5? Don't know if this behaviour is common to Python. #- I ask because we're at 2.3.4 at work, but could use it #- today. I'd hate to #- have to track it to backport fixes though. It would be #- ideal if I could #- simply copy the 2.4 version as it matures. I have a similar issue. I copied the decimal.py code and included it on the SiGeFi package (http://sourceforge.net/projects/sigefi), so when somebody downloads the 0.2 version could use it with Py2.3 (it's the version required). My plan (right now) is to wait Py2.4, then remove decimal.py from the package and require Py2.4 (this is justified because SiGeFi will reach "user usage" next year). . Facundo

6 9

PEP 318 has ReST errors
by Guido van Rossum Aug. 20, 2004

Aug. 20, 2004

The cronjob on my home machine that formats the PEPs 4x daily complains about syntax errors in PEP 318. Last time that happened I fixed them all, but today I don't have time. Can somebody with checkin perms and ReST foo please fix these? pep-0318.txt:330: (ERROR/3) Unexpected indentation. pep-0318.txt:336: (ERROR/3) Unexpected indentation. pep-0318.txt:351: (WARNING/2) Inline substitution_reference start-string without end-string. pep-0318.txt:106: (ERROR/3) Unknown target name: "java-style". pep-0318.txt:132: (ERROR/3) Unknown target name: "gof book". pep-0318.txt:169: (ERROR/3) Unknown target name: "in your face". pep-0318.txt:218: (ERROR/3) Unknown target name: "a large number". pep-0318.txt:218: (ERROR/3) Unknown target name: "each possible syntax". pep-0318.txt:288: (ERROR/3) Unknown target name: "summarised the arguments". pep-0318.txt:507: (ERROR/3) Unknown target name: "annotations". --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

decimal module portability to 2.3?
by Skip Montanaro Aug. 19, 2004

Aug. 19, 2004

The docstring for the decimal module says in part: This is a Py2.3 implementation of decimal floating point arithmetic based on the General Decimal Arithmetic Specification: Is it intended to remain 2.3-compatible for the forseeable future? It's not mentioned in PEP 291, nor is there any discussion of portability to 2.3 in PEP 327. I ask because we're at 2.3.4 at work, but could use it today. I'd hate to have to track it to backport fixes though. It would be ideal if I could simply copy the 2.4 version as it matures. Thx, Skip

2 1

[Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320
by Guido van Rossum Aug. 19, 2004

Aug. 19, 2004

> Move the bytecode optimizer upstream so that its results are saved > in pyc files and not re-optimized upon import. Saves a bit of > startup time while still remaining decoupled from the rest of the > compiler. Hm, shouldn't the bytecode optimizer only be used when -O is used, and hence pyo files are being written? --Guido van Rossum (home page: http://www.python.org/~guido/)

6 7