Mailman 3 November 2003 - Python-Dev

RE: [Python-Dev] Patch to distutils.msvccompiler, 2.3 branch
by Delaney, Timothy C (Timothy) 27 Nov '03

27 Nov '03

> From: Martin v. Löwis > > Thomas Heller <theller(a)python.net> writes: > > > It would be great if > > someone else would try it out and report if it works > correctly - IMO it > > should be commited to the 2.3 maintanance branch before > 2.3.3 goes out. > > (Suggestions for better wording would be accepted ;-) > > I'm willing to trust you that you get this right. > > Most of us probably aren't even aware that VS6 has different registry > settings depending on whether it was ever invoked after being > installed. This is something I come across all the time with Microsoft product - in particular, we have a product which is a plugin to Microsoft Visio. Our installer currently has to detect that Visio is installed, but hasn't been run, and tell them to run it. I intend to rewrite the installer soon (from WISE to NSIS) and hopefully I'll be able to improve this behaviour ... Tim Delaney

1 0

Re: [Python-Dev] less quick patch for better debugging.
by Phillip J. Eby 27 Nov '03

27 Nov '03

At 09:41 AM 11/27/03 -0800, Guido van Rossum wrote: >Probably not worth it. (I should mention that I have a possible use >case for messing with the lnotab to contain line numbers in a >different file than the Python source code. :-) DTML, perhaps? ;-) Yes, if the format is changed to add columns, it would be nice to make it be capable of having the code in one code block actually come from more than one file, or from non-contiguous lines in one file. Tools that use Python as an output format, or that preprocess Python (e.g. the dozen or so templating libraries out there), could really use something like a #line directive.

1 0

python-dev Summary for 10-16-2003 through 11-15-2003 [draft]
by Brett C. 27 Nov '03

27 Nov '03

Thanks to school I didn't get to the latter half of October summary until I needed to start worrying about the first summary for November. So I just combined them. I am hoping to send this summary out Wednesday or Thursday so as to not worry about it beyond Thanksgiving morning. So please try to get your corrections and comments in by then. Thanks. ------------------------------- python-dev Summary for 2003-10-16 through 2003-11-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from October 16, 2003 through November 15, 2003. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list(a)python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the twenty-eighth and twenty-ninth summaries written by Brett Cannon (does anyone even read this?). All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the original text file. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on something mentioned here. PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. contents:: .. _last summary: http://www.python.org/dev/summary/2003-09-01_2003-09-15.html ===================== Summary Announcements ===================== Thanks to midterms and projects my time got eaten up by school. That postponed when I could work on the twenty-eighth summary so much that the twenty-ninth was need of being written. So they are combined in into one to just get the stuff out the door. The second half of October had some major discussions happen. Guido and Alex Martelli talking equals pain for me. =) There was a large discussion on scoping and accessing specific namespaces. Jeremy Hylton is working on a PEP on the subject so I am not going to stress myself over summarizing the topic. A big discussion on the first half of November was about weakrefs and shutdown. Tim Peters figured out the problem (had to do with weakrefs referencing things already gc'ed and thus throwing a fit when trying to gc them later or keeping an object alive because of the weakref). It was long and complicated, but the problem was solved. If you have ever wanted to see linked lists used in Python in a rather elegant way, take a look at Guido's implementation of itertools.tee at http://mail.python.org/pipermail/python-dev/2003-October/039593.html . Europython is going to be held from June 7-9, 2004 in Sweden. See http://mail.python.org/pipermail/europython/2003-November/003634.html for more details. PyCon is slowly moving along. The registration site is being put through QA and the paper submission system is being worked on. The Call for Proposals (CFP) is still on-going; details at http://www.python.org/pycon/dc2004/cfp.html . Keep an eye out for when we announce when the registration and paper submission systems go live. ========= Summaries ========= ------------------------------------------ How to help with the development of Python ------------------------------------------ In an attempt to make it easy as possible for people to find out how they can help contribute to Python's development, I wrote an essay on the topic (mentioned last month, but some revisions have been done). It covers how Python is developed and how **anyone** can contribute to the development process. The latest version can be found at http://mail.python.org/pipermail/python-dev/2003-October/039473.html . Any comments on the essay are appreciated. Contributing threads: - `Draft of an essay on Python development <http://mail.python.org/pipermail/python-dev/2003-October/038677.html>`__ - `2nd draft of "How Py is Developed" essay <http://mail.python.org/pipermail/python-dev/2003-October/039473.html>`__ ------------------------------------------------ Generator Expressions: list comp's older brother ------------------------------------------------ If you ever wanted to have the power of list comprehensions but without the overhead of generating the entire list you have Peter Norvig initially and then what seems like the rest of the world for generator expressions. `PEP 289`_ covers all the details, but here is a quick intro. You can think of generator expressions as list comprehensions that return an iterator for each item instead a list items. The syntax is practically the same as list comprehensions as well; just substitute parentheses for square brackets (most of the time; generator expressions just need parentheses around them, so being the only argument to a method takes care of the parentheses requirement). A quick example is:: (x for x in range(10) if x%2) returns an iterator that returns the odd numbers from 0 to 10. This make list comprehensions just syntactic sugar for passing a generator expression to list() (note how extra parentheses are not needed):: list(x for x in range(10) is x%2) Having list comprehensions defined this way also takes away the dangling item variable for the 'for' loop. Using that dangling variable is now discouraged and will be made illegal at some point. For complete details, read the PEP. .. _PEP 289: http://www.python.org/peps/pep-0289.html Contributing threads: - `decorate-sort-undecorate <http://mail.python.org/pipermail/python-dev/2003-October/038652.html>`__ - `accumulator display syntax <http://mail.python.org/pipermail/python-dev/2003-October/038804.html>`__ - `listcomps vs. for loops <http://mail.python.org/pipermail/python-dev/2003-October/039081.html>`__ - `PEP 289: Generator Expressions (second draft) <http://mail.python.org/pipermail/python-dev/2003-October/039356.html>`__ --------------------- list.sorted() is born --------------------- After the addition of the 'key' argument to list.sort(), people began to clamor for list.sort() to return self. Guido refused to do give in, so a compromise was reached. 'list' now has a class method named 'sorted'. Pass it a list and it will return a *copy* of that list sorted. Contributing threads: - `decorate-sort-undecorate <http://mail.python.org/pipermail/python-dev/2003-October/038811.html>`__ - `inline sort option <http://mail.python.org/pipermail/python-dev/2003-October/038825.html>`__ - `sort() return value <http://mail.python.org/pipermail/python-dev/2003-October/038855.html>`__ - `copysort patch <http://mail.python.org/pipermail/python-dev/2003-October/038947.html>`__ ------------------------------------ Recursion limit in re is now history ------------------------------------ Thanks to Gustavo Niemeyer the recursion limit in the re module has now be removed! Contributing threads: - `SRE recursion <http://mail.python.org/pipermail/python-dev/2003-October/038839.html>`__ - `SRE recursion removed <http://mail.python.org/pipermail/python-dev/2003-October/038962.html>`__ ----------------------------------- Copying iterators one day at a time ----------------------------------- Reiteration for iterators came up as part of the immense discussion on generator expressions. The difficulty of doing it generally came up. This lead to Alex Martelli proposing magic method support for __copy__ in iterators that have want to allow making a copy of itself. This was written down as `PEP 323`_. As an interim solution, itertools grew a new function: tee. It takes in an iterable and returns two iterators which independently iterate over the iterable. .. _PEP 323: http://www.python.org/peps/pep-0323.html Contributing threads: - `Reiterability <http://mail.python.org/pipermail/python-dev/2003-October/038969.html>`__ - `cloning iterators again <http://mail.python.org/pipermail/python-dev/2003-October/039593.html>`__ - `... python/nondist/peps pep-0323.txt, NONE ... <http://mail.python.org/pipermail/python-dev/2003-October/039656.html>`__ - `Guido's Magic Code <http://mail.python.org/pipermail/python-dev/2003-October/039819.html>`__ ------------------------------------------------------ Returning Py_(None, True, False) now easier than ever! ------------------------------------------------------ Py_RETURN_NONE, Py_RETURN_TRUE, and Py_RETURN_FALSE have been added to Python 2.4. They are macros for returning the singleton mentioned in the name. Documentation has yet to be written (my fault). Contributing threads: - `How to spell Py_return_None and friends <http://mail.python.org/pipermail/python-dev/2003-October/039000.html>`__ - `python/dist/src/Include object.h, 2.121, ... <http://mail.python.org/pipermail/python-dev/2003-October/039026.html>`__ ------------------------------------------------------------------------- 'String substitutions'/'dict interpolation'/'replace %(blah)s with $blah' ------------------------------------------------------------------------- The idea of introducing string substitutions using '$' came up. Guido said that if this was made a built-in feature it would have to wait until Python 3. He was receptive to moving the functionality to a module, though. Barry Warsaw pasted code into http://mail.python.org/pipermail/python-dev/2003-October/039369.html that handles string substitutions. Contributing threads: - `Can we please have a better dict interpolation syntax? <http://mail.python.org/pipermail/python-dev/2003-October/039324.html>`__ ------------------------------------------ "reduce() just doesn't get enough mileage" ------------------------------------------ That quote comes from Guido during the discussion over whether 'product' should be added as an accumulator function built-in like 'sum'. The idea was shot down and conversation quickly turned to whether 'reduce' should stay in the language (the consensus was "no" since the function does not read well and its functionality can easily be done with a 'for' loop). A larger discussion on what built-ins should eventually disappear will be covered in the next Summary. Contributing threads: - `product() <http://mail.python.org/pipermail/python-dev/2003-October/039326.html>`__ ----------- PyPy update ----------- The PyPy_ development group sent an update on their happenings to the list. Turns out they are trying to get funding from the European Union. They are also fairly close to getting a working version (albeit with some bootstrapping from CPython, but it will still be damn cool what they have pulled off even with this caveat). They also announced a sprint they are holding in Amsterdam from Dec. 14-21. More info can be found at http://codespeak.net/moin/pypy/moin.cgi/AmsterdamSprint . .. _PyPy: http://codespeak.net/pypy/ Contributing threads: - `PyPy: sprint and news <http://mail.python.org/pipermail/python-dev/2003-October/039579.html>`__ ---------------------------- Never say Python is finished ---------------------------- I asked python-dev for masters thesis ideas. I great number of possibilities were put out. If anyone out there is curious to see what some people would like to see done for Python in terms of a large project check the thread out. Contributing threads: - `Looking for master thesis ideas involving Python <http://mail.python.org/pipermail/python-dev/2003-October/039763.html>`__ --------------------------------- Rough draft of Decimal object PEP --------------------------------- Facundo Batista has posted a rough draft of a PEP for a decimal object that is being worked on in the sandbox. Comment on it on `comp.lang.python`_ if this interests you. Contributing threads: - `prePEP: Decimal data type <http://mail.python.org/pipermail/python-dev/2003-October/039870.html>`__ ---------------------------------------------------------- Relations of basestring and bye-bye operator.isMappingType ---------------------------------------------------------- The idea of introducing relatives of basestring for numbers came from Alex Martelli. That idea was shot down for not being needed once the merger of int and long occurs. The point that operator.isMappingType is kind of broken came up. Both Alex and Raymond Hettinger would not mind seeing it disappear. No one objected. It is still in CVS at the moment, but I would not count on it necessarily sticking around. Contributed threads: - `reflections on basestring -- and other abstract basetypes <http://mail.python.org/pipermail/python-dev/2003-November/039885.html>`__ - `operator.isMappingType <http://mail.python.org/pipermail/python-dev/2003-November/040122.html>`__ --------------------------------------------------------- Why one checks into the trunk before a maintenance branch --------------------------------------------------------- The question of whether checking a change into a maintenance branch before applying it to the main trunk was acceptable came up. The short answer is "no". Basically the trunk gets more testing than the maintenance branches and thus the patch should have to prove its stability first. Only then should it go into a maintenance branch. The same goes for changes to code that will eventually disappear in the trunk. Someone might be planning on removing some code, but if that person falls off the face of the earth the code will still be there. That means applying the patch to the code that is scheduled to disappear is still a good idea. Contributing threads: - `check-in policy, trunk vs maintenance branch <http://mail.python.org/pipermail/python-dev/2003-November/039903.html>`__ ----------------------- New reversed() built-in ----------------------- There was a new built-in named reversed(), and all rejoiced. Straight from the function's doc string: "reverse iterator over values of the sequence". `PEP 322`_ has the relevant details on this toy. .. _PEP 322: http://www.python.org/peps/pep-0322.html Contributing threads: - `PEP 322: Reverse Iteration <http://mail.python.org/pipermail/python-dev/2003-November/039924.html>`__ --------------------------- Cleaning the built-in house --------------------------- Guido asked what built-ins should be considered for deprecation. Instantly intern, coerce, and apply came up. apply already had a PendingDeprecationWarning and that will stay for the next release or two. intern and coerce, though, did not have any major champions (intern had some fans, but just for the functionality). Guido did state that none of these built-in will be removed any time soon. If they do get deprecated it does not lead to immediate removal. Python 3, though, takes the gloves off and that can see them just completely disappear. Contributing threads: - `Deprecating obsolete builtins <http://mail.python.org/pipermail/python-dev/2003-November/039994.html>`__ ---------------------------------------- Passing arguments to str.(encode|decode) ---------------------------------------- The idea of allowing keyword arguments be passed to any specified encoder/decoder was brought up by Raymond Hettinger. It seemed like an idea that was supported. The idea of specifying the encoder or decoder based on the actual object instead of the current way of specifying a string that is passed to the registered codec search functions was suggested. Nothing has been finalized on this idea as of now. Contributing threads: - `Optional arguments for str.encode /.decode <http://mail.python.org/pipermail/python-dev/2003-November/040055.html>`__ ------------------------------------------------------ Where, oh where, to move the good stuff out of string? ------------------------------------------------------ It looks like ascii_* and possibly maketrans from the string module will be tacked on to the str type so that the string module can finally be removed from the language. It has not been pronounced upon, but it looks like that is what the BDFL is leaning towards. Issues of using the methods of str as unbound methods did come up. As it stands you cannot pass a unicode object to str.upper and thus there is no one uppercasing function as there is in the string module. This issue brought up the problem of Unicode and locale ties and collation (how to sort things). Contributing threads: - `other "magic strings" issues <http://mail.python.org/pipermail/python-dev/2003-November/040067.html>`__ ----------------------------------------- Supported versions of Sleepycat for bsddb ----------------------------------------- The basic answer is 3.2 - 4.2 should work when you compile from source. Contributing threads: - `which sleepycat versions do we support in 2.3.* ? <http://mail.python.org/pipermail/python-dev/2003-November/040196.html>`__ ----------------------------- Sets now at blazing C speeds! ----------------------------- Raymond Hettinger implemented the sets API in C! The new built-ins are set (which replaces sets.Set) and frozenset (which replaces sets.ImmutableSet). The APIs are the same as the sets module sans the name change from ImmutableSet to frozenset. Contributing threads: - `set() and frozenset() <http://mail.python.org/pipermail/python-dev/2003-November/040253.html>`__

2 2

RE: [Python-Dev] Tail recursion
by Devin 27 Nov '03

27 Nov '03

On Thu, 27 Nov 2003, Andrew Koenig wrote: > --snip-- > Moreover, I don't know how to write an interative version that is as > easy to understand as the recursive version. ::Lurk mode off:: import math def numdigits(n): assert (n >= 0) and ((n % 1) == 0) if n < 10: return 1 return int(math.log10(n)) + 1 (not iterative, but it'll do :) ::Lurk mode on:: -- Devin devin(a)whitebread.org http://www.whitebread.org/

2 1

Tutorial: Brief Introduction to the Standard Libary
by Arthur 27 Nov '03

27 Nov '03

>I'm interested to know what your experiences have been >with teaching.python. How about one's experience in learning Python? It is clear to me - in retrospect - that the absence of copy() as a _built-in__ worked negatively. Learning isn't a linear process, and I can't make a simple linear argument as to why this is so. But it has more to do with getting a handle on assignment, than the direct use or lack of use of copy() itself. I tried to open up discussion of this issue on edu-sig, and was asked by Guido to take a hike. I had apparently chosen an inappropriate forum. I understand that a move of copy() to built-ins is not in the cards. Number #1 on a list of library modules in a tutorial may well be a better solution. I strongly encourage you to stick with your instincts and intuition here. But by all means including Guido's koan about the overuse of copy by novices as part of that presentation. Art

1 0

Java final vs Py __del__
by Kepes Krisztian 27 Nov '03

27 Nov '03

Hi ! I very wonder, when I get exp. in java with GC. I'm Delphi programmer, so I get used to destructorin objects. In Java the final method is not same, but is like to destructor (I has been think...). And then I try with some examples, I see, that the Java GC is sometimes not call this method of objects, only exit from program. So: the java programs sometimes end before the GC is use the final methods on objects. This mean that in Java the critical operations MUST do correctly by the programmmers, or some data losing happened. If it is open a file, then must write the critical modifications, and must use the flush, and close to be sure to the datas are saved. In the Py the __del__ is same java's final, or it is to be called in every way by GC ? I build this method as safe method: if the programmer don't do any closing/freeing thing, I do that ? simple example: class a: def __init__(self,filename): self.__filename=filename self.__data=[] self.__file=None def open(self): self.__file=open(self.__filename,"w") def write(self,data): self.__data.append(data) def close(self): self.__file.writelines(self.__data) self.__file.close() self.__file=None def __del__(self): if self.__file<>None: self.close() # like destructor: we do the things are forgotten by programmer Thanx for infos: KK

2 1

list and string - method wishlist
by Kepes Krisztian 27 Nov '03

27 Nov '03

Hi ! A.) The string object have a method named "index", and have a method named "find". It is good, because many times we need to find anything, and it is very long to write this: try: i=s.index('a') except: i=-1 if i<>-1: pass and not this: if (s.find('a')<>-1): pass Why don't exists same method in the list object ? It is very ugly thing (sorry, but I must say that). I must write in every times: l=[1,2,3,4] try: i=l.index(5) except: i=-1 if i<>-1: pass and not this: if (l.find(5)<>-1): pass B.) Same thing is the deleting. I think, this method is missing from strings, and lists. Example: I must write this: s='abcdef' l=[1,2,5,3,4,5] print s s=s[:2]+s[3:] print s print l l[2]=None l.remove(None) print l and not this: s='abcdef' l=[1,2,5,3,4,5] s=s.delete(2) l.delete(2) and delete more: s.delete() # s='' l.delete() # l=[] s.delete(2,2) # s='abef' l.delete(2,2) # l=[1,2,4,5] So: some functions/methods are neeeded to Python-like programming (less write, more effectivity). KK

2 1

Re: [Python-checkins] python/dist/src/Doc/whatsnew whatsnew24.tex, 1.13, 1.14
by Fred L. Drake, Jr. 26 Nov '03

26 Nov '03

rhettinger(a)users.sourceforge.net writes: > Nits from a review of the documentation update. These too have been quietly pushed to the website. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

1 0

IRC Channels
by Michael Hudson 26 Nov '03

26 Nov '03

Given that PEP 101 mentions the #python-dev IRC channel by name, I thought it might be prudent to register it on freenode. If anyone wants privileges, email me your nick. Also, wasn't someone rewriting the release PEPs to talk about roles instead of names? Cheers, mwh -- : exploding like a turd Never had that happen to me, I have to admit. They do that often in your world? -- Eric The Read & Dave Brown, asr

2 3

Ripping out Macintosh support
by Jack Jansen 25 Nov '03

25 Nov '03

As you may have noticed if you follow the checkins mailing list I've enthusiastically started ripping out 90% of the work I did on Python the last 10 years (and quite a bit of really old code by Guido too:-): everything related to support for pre-Mac OS X macintoshes. Over the last year I've asked various times whether anyone was willing to even consider doing support for MacOS9 for 2.4, and I got absolutely no replies, not even the usual "I'd love to have it but I can't help":-). So out it goes! I'm trying to be careful that I don't break anything, and I make sure the selftests pass every time, but there's always the chance that I do get something wrong. So if things suddenly break inexplicably you're all free to blame me, initially, until I can point out that I have nothing whatsoever to do with the breakage:-) -- Jack Jansen <Jack.Jansen(a)cwi.nl> http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

4 7