Mailman 3 November 2002 - Python-Dev

Re: [Python-Dev] dict() enhancement idea?
by Just van Rossum 21 Nov '02

21 Nov '02

Just van Rossum wrote: > I could try to make a patch if people think this is a good idea. Hm, that took a full 15 minutes ;-) See attached. Patching the docs is probably more work, as usual... Of course, I'll upload it to sf, but I'd like to get some feedback here, first. Just

1 0

bsddb broken on Windows
by Tim Peters 21 Nov '02

21 Nov '02

Rev 1.38 of bsddbmodule.c changed the name of the module init function from initbsddb to initbsddb185 I imagine that's what causes >>> import bsddb Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: dynamic module does not define init function (initbsddb) >>> on Windows. Who understands what was intended here?

3 4

Dictionary Foolishness?
by Raymond Hettinger 21 Nov '02

21 Nov '02

Have dictionaries support the repetition. Use the replication factor to provide a hint as to how large the dictionary is expected to be. [0] * n # allocate an n-length list {} * n # allocate an n-element dictionary If the a list already has k elements, the result is already n*k long; however, for a dictionary, since the keys are unique, the result says at n*1. Hence, the dictionary contents are unaffected by repetition. But the n-factor is useful for eliminating all but one of the re-size operations when growing a large dictionary, element by element. If k > n, then the hint is disregarded since the number of elements already exceeds the hint. Raymond Hettinger

3 2

Licensing question
by David Abrahams 19 Nov '02

19 Nov '02

Hi, Recently we've been trying to shore up copyrights in Bost code; some of our source files have no copyright notice at all. Boost.Python includes a modified version of Python.h to work around some C++ interoperability bugs in Python 2.2.1's header. Lawyers in companies that use Boost would feel a lot more comfortable if the file included a copyright notice. My usual practice is to write: // Copyright David Abrahams 2002. Permission to copy, use, // modify, sell and distribute this software is granted provided this // copyright notice appears in all copies. This software is provided // "as is" without express or implied warranty, and with no claim as // to its suitability for any purpose. At the top of every C++ source file. Is there any reason not to do that with our modified Python.h? If so, what should I put there? Thanks, Dave -- David Abrahams dave(a)boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution

2 4

Plea: can modulefinder.py move to the library?
by Just van Rossum 19 Nov '02

19 Nov '02

Is there any reason not to move freeze's modulefinder.py to the library? It's a very useful module, and it's a shame it's not available in non-source distributions. It seems odd that utilities that use it (like py2exe) must ship it themselves, since some otherwise work perfectly with a binary distribution. I'm currently working on a py2exe-like tool for MacOSX and it would've been nice if I could have just done "import modulefinder"... Just

3 5

Re: [Python-checkins] python/dist/src/Lib nntplib.py,1.30,1.31
by Just van Rossum 17 Nov '02

17 Nov '02

Just van Rossum wrote: > esr(a)users.sourceforge.net wrote: > > > + # If no login/password was specified, try to get them from ~/.netrc > > + # Presume that if .netc has an entry, NNRP authentication is > required. > > + if not user: > > + import netrc > > + credentials = netrc.netrc() > > + auth = credentials.authenticators(host) > > + if auth: > > + user = auth[0] > > + password = auth[2] > > + # Perform NNRP authentication if needed. > > Erm, doesn't this make anonymous nntp access fail if there's no $HOME or no > ..netrc file in $HOME? Ok, since I didn't get a reply (I posted the above to python-checkins), I tried it, and yes it does break: [python:~] just% python2.3 Python 2.3a0 (#2, Nov 17 2002, 18:16:38) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from nntplib import NNTP >>> s = NNTP('news') Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.3/nntplib.py", line 140, in __init__ credentials = netrc.netrc() File "/usr/local/lib/python2.3/netrc.py", line 29, in __init__ fp = open(file) IOError: [Errno 2] No such file or directory: '/Users/just/.netrc' >>> Just

2 1

Weekly Python Bug/Patch Summary
by Skip Montanaro 17 Nov '02

17 Nov '02

Bug/Patch Summary ----------------- 305 open / 3051 total bugs (-6) 101 open / 1784 total patches (+2) New Bugs -------- --with-dl-dld section of the readme (2002-11-10) http://python.org/sf/636313 ftplib bails out on empty responses (2002-11-11) http://python.org/sf/636685 print to unicode stream should __unicode (2002-11-12) http://python.org/sf/637094 inspect.getargspec: None instead of () (2002-11-12) http://python.org/sf/637217 "u#" doesn't check object type (2002-11-12) http://python.org/sf/637547 logging package undocumented (2002-11-13) http://python.org/sf/637847 __getstate__() documentation is vague (2002-11-13) http://python.org/sf/637941 Move bdist_wininst source code into PC (2002-11-14) http://python.org/sf/638595 Instantiation init-less class with param (2002-11-14) http://python.org/sf/638610 optparse module undocumented (2002-11-14) http://python.org/sf/638703 Install script goes into infinite loop (2002-11-15) http://python.org/sf/639022 archiver should use zipfile before zip (2002-11-15) http://python.org/sf/639118 Tkinter sliently discards all Tcl errors (2002-11-15) http://python.org/sf/639266 urllib.basejoin() mishandles '' (2002-11-16) http://python.org/sf/639311 crash (SEGV) in Py_EndInterpreter() (2002-11-17) http://python.org/sf/639611 New Patches ----------- Fix for major rexec bugs (2002-11-11) http://python.org/sf/636769 Modulefinder doesn't handle PyXML (2002-11-13) http://python.org/sf/637835 Allow any file-like object on dis module (2002-11-13) http://python.org/sf/637906 SimpleSets (2002-11-13) http://python.org/sf/638095 LaTeX documentation for logging package (2002-11-14) http://python.org/sf/638299 Added Proxyauth command to imaplib (2002-11-14) http://python.org/sf/638673 Logging 0.4.7 & patches thereto (2002-11-15) http://python.org/sf/638825 _strptime fixes for None locale and tz (2002-11-15) http://python.org/sf/639112 Remove type-check from urllib2 (2002-11-15) http://python.org/sf/639139 new string method -- format (2002-11-16) http://python.org/sf/639307 Removal of FreeBSD 5.0 specific test (2002-11-16) http://python.org/sf/639371 New icon for .py files (2002-11-17) http://python.org/sf/639635 Closed Bugs ----------- PyImport_ExecCodeModule not correct (2001-05-14) http://python.org/sf/424106 list.sort crasher (2001-08-20) http://python.org/sf/453523 freeze doesn't like DOS files on Linux (2001-09-24) http://python.org/sf/464405 Upgrade TCL for windows installer (2001-11-22) http://python.org/sf/484715 Support for page & shortcut icons (2001-11-27) http://python.org/sf/486360 socket module fails to build on HPUX10 (2002-01-18) http://python.org/sf/505427 Version number handling (2002-04-29) http://python.org/sf/550364 ext module generation problem (2002-08-23) http://python.org/sf/599248 time.struct_time undocumented (2002-09-03) http://python.org/sf/604128 Use C3 MRO algorithm (2002-10-04) http://python.org/sf/618704 HTMLParser:endtag events in comments (2002-10-08) http://python.org/sf/620243 distutils mixed stdin/stdout output (2002-10-08) http://python.org/sf/620630 Broken link in local documentation. (2002-10-16) http://python.org/sf/624024 strptime() always returns 0 in dst field (2002-10-21) http://python.org/sf/626570 int("123123123123123123") doesn't work (2002-10-28) http://python.org/sf/629989 https via httplib trips over IIS defect (2002-10-31) http://python.org/sf/631683 cgi.py drops commandline arguments (2002-11-04) http://python.org/sf/633504 Don't define _XOPEN_SOURCE on OpenBSD (2002-11-07) http://python.org/sf/635034 Misleading description of \w in regexs (2002-11-08) http://python.org/sf/635595 2.2.2 build on Solaris (2002-11-09) http://python.org/sf/635929 No error "not all arguments converted" (2002-11-09) http://python.org/sf/635969 Closed Patches -------------- Fast-path for interned string compares (2001-11-08) http://python.org/sf/479615 hasattr catches only AttributeError (2002-01-16) http://python.org/sf/504714 PEP 282 Implementation (2002-07-07) http://python.org/sf/578494 py2texi.el update (2002-08-02) http://python.org/sf/590352 Bugfix: content-type header parsing (2002-09-23) http://python.org/sf/613605 C3 MRO algorithm implementation (2002-10-06) http://python.org/sf/619475 Bytecode copy bug in freeze (2002-10-24) http://python.org/sf/627900 Add a sample selection method to random.py (2002-10-27) http://python.org/sf/629637 os.tempnam behavior in Windows (2002-11-08) http://python.org/sf/635656 Typo in PEP249 (2002-11-10) http://python.org/sf/636159

1 0

Sigh...
by David Ascher 17 Nov '02

17 Nov '02

I accidentally deleted a mail folder which includes all of the "important, unprocessed" emails. If there's something that you sent me that needs my attention or that includes important schedule or other information, please resend it. I'll be looking for a backup, but I'm not 100% sure that I'll find one. --david

1 0

Summary for 2002-11-01 through 2002-11-15
by Brett Cannon 16 Nov '02

16 Nov '02

Yes, it's that time of the month folks! I am back in case you didn't notice and thus so is the Summary as penned by me. As usual I am giving the list 24 hours or so to find out how bad of a reporter I am and correct me in all manners and ways. ========================================== This is a summary of traffic on the `python-dev mailing list`_ between November 1, 2002 and November 15, 2002 (inclusive). It is intended to inform the wider Python community of on-going developments on the list that might interest the wider Python community. To comment on anything mentioned here, just post to python-list(a)python.org or comp.lang.python in the usual way; give your posting a meaningful subject line, and if it's about a PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep iteration). 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 fifth summary written by Brett Cannon (after a relaxing two week hiatus; thanks to Raymond Hettinger for doing the Summary while I was gone). All summaries are now archived at http://www.python.org/dev/summary/ (thanks to A.M. Kuchling for setting that up). 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_; you can safely ignore it (although I suggest learning reST; its simple and is accepted for PEP markup). Also, because of the wonders of reformatting thanks to whatever program you are using to read this, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is. If you want to do that, get an original copy of the text file. .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html ====================== Summary Announcements ====================== Not much to say for this summary. The only thread skipped that someone out there might care about was one on getting the PEPs to display properly for IE 6 when the PEP was written in reST_. Thanks goes to Raymond Hettinger for covering the Summary while I was away on vacation. Thanks also goes out to Laura Creighton and Guido for suggesting graduate schools that are Python-friendly. ================================= `Getting python-bz2 into 2.3`__ ================================= __ http://mail.python.org/pipermail/python-dev/2002-November/029830.html continuation: http://mail.python.org/pipermail/python-dev/2002-October/029829.html Gustavo Niemeyer asked how he should go about getting his python-bz2_ module into the standard library. He was basically told to submit a patch complete with the module, docs, regression tests, etc.; everything a healthy module needs. It was also suggested that he provide a MSVC project file. The didn't work for Gustavo (who now has CVS write priveleges; congrats) since he doesn't use Windows. This was a slight problem because if the extension file doesn't build under Windows it can't be included in the PythonLabs Windows distro. So keep in mind that if your module won't directly compile for 6 different versions of Windows it won't be included in the Windows distro. .. _python-bz2: http://python-bz2.sourceforge.net/ =================================== `Becoming a python contributor`__ =================================== __ http://mail.python.org/pipermail/python-dev/2002-November/029831.html continuation: http://mail.python.org/pipermail/python-dev/2002-October/029828.html Gustavo Niemeyer asked about how he could help contribute to Python. He made the observation that "Guido and others [have been] bothered a few times because of the lack of man power" which has led to a "small core of very busy developers working on core/essential/hard stuff *and* in code reviewing as well" (and I can attest to this fact that this is very true; I am amazed the guys at PythonLabs have any form of a life outside of work with the amount of time they put in). Gustavo felt "that the Python development is currently overly centralized". Martin v. Loewis responded first. He said that "the most important aspect I'd like to hand off is the review of patches; to Tim, it is the analysis of bug reports". Martin then listed various points on how to be able to review a patch and how to handle bug reports; the email is at http://mail.python.org/pipermail/python-dev/2002-November/029831.html . I *highly* recommend reading the email because Martin's points are all good and more patch reviewers would be rather nice. M.A. Lemburg commented next, saying that he "wouldn't mind if other developers with some time at hand jump in on already assigned patches and bug reports to help out". Just because a patch has been assigned to someone doesn't mean the patch or the assignee couldn't use more help. Having the patch assigned to someone just means that they take responsibility to apply the patch if it is worthy of being accepted or to reject it. It should not stop other people from making comments or helping out so that the assignee can have a little bit of time saved for other things... like another patch to assign to themselves. MAL also suggested that we have more maintainers that are in charge of chunks of code, e.g. Martin handles all locale code. Martin disagreed with this idea, though. Jack Jansen agreed with Martin. He thought that if something came up that was not within the realm of a specific person that it "either get[s] ignored, or passed on to Guido, or picked up by yourself or Michael [Hudson] or one of the very few other people who do general firefighting". Martin commented later that he would hope that the stewardship of specific code does not get anymore formal. Martin then stated how one goes about getting commit priveleges for Python on SF: "just step forward and say that you want. In the past, Guido has set a policy that people who's commit privilege is fresh will still have to use SF, but can perform the checkin themselves". Tradition has stated that "fresh" is your first two or three SF patches. But please only step forward if you are known to python-dev or PythonLabs since commit priveleges won't be given to people who just wander in off the proverbial street and ask for it. Martin basically states this in a later email by saying that "people should not produce a burst of patches just to get commit privileges. Instead, they should contribute patches steadily (and should have done so in the past), and then get CVS write access as a simplification for the rest of the maintainers". Neal Norwitz pointed out that if a bug ends up with a fix it is best to submit a separate patch instead of attaching it to the bug report. That way there is a bigger chance of the patch being seen and dealth with. But please make sure to mention that it fixes a bug so that the bug can be closed! Martin even suggested mentioning this fact in the title of the patch submission. ==================== `RoundUp status`__ ==================== __ http://mail.python.org/pipermail/python-dev/2002-November/029879.html This is a splinter thread of the 'Becoming a python contributor' thread in which Micheal Hudson asked how using Roundup_ for replacing SF_ was coming along. Guido said things had come up that was holding it up. One was that the test server running at http://www.python.org:8080 had died when the box was restarted (which is now back up). There were also some changes to Roundup that needed to be dealt with in order to get everything over from SF on to Roundup. Guido also just ran out of time to review it more, although he did like what he had reviewed so far. Guido asked for a volunteer. It was asked what was needed. Guido said that Roundup had moved over to Zope-style templating so all the old templates that Gordon (I assuming this is Gordon McMillan) wrote needed to be changed. There were also some bugs that needed to be dealt with that are being tracked at Roundup hosted at http://www.python.org:8080 . And there also will need to be preparations for the day that development is moved over from SF to the Roundup setup; that will require transferring everything over from SF, shutting down SF, and handling any bugs that crop up from the heavy use that the new setup is going to get. So if you have any dislike for SF, then please contribute to Roundup and help get Python off of there! .. _Roundup: http://roundup.sourceforge.net/ .. _SF: http://www.sf.net/ ======================================= `Contributing...current bug status`__ ======================================= __ http://mail.python.org/pipermail/python-dev/2002-November/029846.html Neal Norwitz went through the SF_ bug tracker and counted 325 bugs and generated a very easy to read page listing all the bugs with their relevant info. You can find the HTML version at http://www.metaslash.com/py/sf.data.html . If you find a bug there you think you can help out on, then go to SF and do so! ======================= `Low hanging fruit`__ ======================= __ http://mail.python.org/pipermail/python-dev/2002-November/029850.html Neal Norwitz generated a list of what he thought were easily fixable bugs and put them in this thread (it's the first email so just go to the link for this thread). So if you have a little bit of free time and want to help out why don't you try to tackle one of these bugs? =============== `Snake farm`__ =============== __ http://mail.python.org/pipermail/python-dev/2002-November/029853.html The only reason I am mentioning this thread here is to help get the word out about the `Snake Farm`_ ; hosted by Lysator_ and sponsored by the `Python Business Forum`_ . It is a compile farm that downloads from cvs, compiles, and runs the test suite of Python daily. It has caught a bunch of bugs and has been a great help. The majority of the thread was spent trying to get FreeBSD 4.4 -current to compile Python and trying to work out a possible bug in pymalloc. .. _Snake Farm: http://www.lysator.liu.se/~sfarmer/ .. _Lysator: http://www.lysator.liu.se/ .. _Python Business Forum: http://www.python-in-business.org ==================================== `David Goodger joins PEP editor`__ ==================================== __ http://mail.python.org/pipermail/python-dev/2002-November/029866.html David Goodger has somehow gotten suckered into becoming a PEP editor (I suspect Barry Warsaw had something to do with this since he used to do all of the PEP editing). So you can all welcome David to his new responsibility by flooding him with all of those PEPs you have lying around and were not sure were good enough to submit. =) ======================== `metaclass insanity`__ ======================== __ http://mail.python.org/pipermail/python-dev/2002-November/029872.html continuation: http://mail.python.org/pipermail/python-dev/2002-October/029795.html Michael Hudson posted the question as to how to get writing ``__bases__`` for new-style classes to do the "right thing" since the mro does not seem to be updated. Kevin Jacob gave it a go but ran into a bug. Guido said that currently there is no way to touch the mro from Python code. All of that info is stored in the tp_mro slot in the object's C representation and is stored as a tuple whose members are expected to be either types or classic classes. Guido said he would accept a patch for assigning to the mro if a check was included to make sure the previously mentioned constraint was maintained. He also said he would probably accept a patch that allowed for assignable ``__bases__`` and writing ``__name__`` . Michael Hudson commented about the difficulty of all of these patches. One thing that came up was the connection between ``__bases__`` and ``__base__`` and how assignment to ``__base__`` should not be taken lightly; Guido commented that "the old and new base must be layout compatible, exactly like for assignment to __class__". Guido later pointed out that ``__base__`` becomes the built-in type that you derive from; whether it be object, list, dict, etc. It was agreed that ``__base__`` shouldn't be writable. The point was made that nestable classes are not pickable since only thing at the top level of a module can be pickled. Guido said he considered this a flaw although he couldn't think of why someone would want to embed a class within a class or a function. This spawned comments on how to deal with this. It seemed the best solution was to change ``__name__`` for the inner class to a fully dotted name (e.g. ``X.Y.__name__ = "X.Y"``) and then make a simple change to either ``pickle`` or ``getattr()``. It was eventually agreed upon that setting ``__name__`` to the full dotted name of the class was the best solution and it was filed as `bug #633930`_ . As part of trying to give Guido good examples of why nested classes are good (the best attempt was Walter Dorwald in an email at http://mail.python.org/pipermail/python-dev/2002-November/029906.html that elicited a "that's cool" comment from Guido), the idea of having ``__iter__`` contain a class definition that returned an instance of that class came up. That was shot down because of the performance hit of dealing with the class definition on every call to ``__iter__``. But the idea of defining ``__iter__`` as a generator was pointed out by Just van Rossum. Doing that simplifies the code usually a good amount since the generator handles all ``.next()`` calls and you just need to have the generator stop when you want your iterator to stop. Apparently this is not a widely used idiom, so I am mentioning it hear since it is a great idea that I can personally attest to as being a rather nice way to handle iterators. .. _bug #633930: http://www.python.org/sf/633930 ============================ `[#527371] sre bug/patch`__ ============================ __ http://mail.python.org/pipermail/python-dev/2002-November/029936.html I am mentioning this thread not because the bug is that big of a deal, but because of the PEP that was brought up when dealing with the bug; `PEP 291`_ . This informational PEP, among other things, lists modules that must be kept compatible with certain versions of Python; in this case sre has to be kept compatible with Python 1.5.2. Except for sre, they are all packages that have made their way into the library. You might want to have a look at the list if you are hacking on any packages in the stdlib. .. _PEP 291: http://www.python.org/peps/pep-0291.html ====================================================================== `Re: [snake-farm] test test_slice failed -- [9, 7, 5, 3, 1] == [0]`__ ====================================================================== __ http://mail.python.org/pipermail/python-dev/2002-November/029941.html Once again this is not to meant to mention directly what as discussed in the thread but a point made. The bug that was discovered was an issue with 64-bit machines and the 32-bit limitation of lists and slicing. The 32-bit limit currently is hard-coded into the C code. Obviously some people would like to see this changed. Neal Norwitz laid down a rough outline on how one could go about changing this at http://mail.python.org/pipermail/python-dev/2002-November/029953.html . Guido then made a pronouncement later stating that he is willing to break binary compatibility once for Python 2.3 or 2.4 to get this done. He also mentioned some other things to make sure to do. As of this writing no one has stepped forward to take this on. ============================== `Reindenting unicodedata.c`__ ============================== __ http://mail.python.org/pipermail/python-dev/2002-November/029997.html While doing some work on `Modules/unicodedata.c`_ , Martin v. Loewis noticed that the indentation style didn't follow `PEP 7`_ and he wondered if it would be okay to re-indent the file. This brought up two points. One was that PEP 7 was not stringently followed. The PEP says to "Use single-tab indents, where a tab is worth 8 spaces". Now that goes against Python coding style where you are supposed to use 4-space indents. So the question of whether one should still use the tab style in new C code came up. Guido said he wished new C code would, but for files he doesn't touch very often he doesn't feel he can enforce it. Barry and Martin came up with a style of notation at the top of any file that uses a non-PEP style which can be found at http://mail.python.org/pipermail/python-dev/2002-November/030067.html . But following the PEP is still the "officially" supported style. But you should try to follow PEP 7 for all new C code and PEP 8 for Python code. The other point was when to re-indent. It was agreed upon to only do that when a major change in the code was occuring. And when you do re-indent, do it as a separate check-in for CVS. .. _Modules/unicodedata.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modul… .. _PEP 7: http://www.python.org/peps/pep-0007.html ============================= `Printing and __unicode__`__ ============================= __ http://mail.python.org/pipermail/python-dev/2002-November/030098.html Martin v. Loewis brought up a point made by Henry Thompson on c.l.py asking why printing ignores ``__unicode__``. Martin thought it shouldn't and listed a bunch of options on how to make printing work with ``__unicode__``. The winner was to have "A file indicates "unicode-awareness" somehow. For a Unicode-aware file, it tries ``__unicode__``, ``__str__``, and ``__repr__``, in order". The agreed solution was to add an ``.encoding`` attribute. This attribute can be set to None when the stream is in Unicode and never converts to a byte-stream. But then M.A. Lemburg chimed in. He was fine with the addition of the ``.encoding``; "this attribute is already available on stream objects created with codecs.open()". What he didn't like was having ``.encoding`` set to None mean the stream would accept Unicode. Martin asked then if ``StringIO`` should have ``.encoding``. MAL replied that "``StringIO`` should be considered a non-Unicode aware stream, so it should not implement .encoding". He thought that if someone wanted ``StringIO`` to be Unicode-aware they could use "the tools in codecs.py [since they] can be used for this (basically by doing the same kind of wrapping as ``codecs.open()`` does)". But then Martin pointed out that StringIO is already Unicode-aware. This debate continued between MAL, Martin, and Guido. But then Guido just said he gave up since the current behavior was relied upon too much. =================== `Adopting Optik`__ =================== __ http://mail.python.org/pipermail/python-dev/2002-November/030108.html Splinter threads: - `Re: [getopt-sig] Adopting Optik <http://mail.python.org/pipermail/python-dev/2002-November/030154.html>`__ - `Re: Adopting Optik <http://mail.python.org/pipermail/python-dev/2002-November/030189.html>`__ - `Fw: [Python-Dev] Adopting Optik <http://mail.python.org/pipermail/python-dev/2002-November/030165.html>`__ - `[getopt-sig] Re: [Python-Dev] Adopting Optik <http://mail.python.org/pipermail/python-dev/2002-November/030179.html>`__ Guido sent an email saying that he would like to get Python 2.3a out the door by X-mas. This means trying to come up with a new name for Optik_ , Greg Ward's command-line options parser. The complaint about the current name is that it's too cute. Guido started it by suggesting the name ``options``. Peter Funk brought up two things. One was that Docutils already used the module under its Optik name. To this Guido responded that they could just change the name in the code. Peter also said that Greg liked ``OptionsParser``. There was also the point that module names are preferred to be short and lowercase. Ka-Ping Yee and myself brought up the point that ``options`` is very generic. Guido agreed with this point while also mentioning that many people already have their own modules name options.py. He then suggested ``optlib`` since "It's short, un-cute, and follows the \*lib pattern used all over the Python stdlib". Greg Ward liked this suggestion. I personally suggested ``ArgParser``, trying to get a tie-in for sys.argv. Greg Ewing built off of this and suggested ``argvparse``, similar to ``urlparse``. David Ascher preferred ``argparse`` since "The v is archaic and so silent it fades away =)". David Abrahams disagreed, stating how the "v" deals with any ambiguity. David Abrahams also said he would vote for ``argvparse`` to break a tie. Ka-Ping Yee suggested ``cmdline`` and ``cmdopts``. David Abrahams liked both. Steve Holden built off of Guido's ``optlib`` and pushed for ``optionlib``. But then Guido asked for a call to votes between ``optlib`` and ``argvparse``. I tallied the votes at one point with it kind of split between them. Then Guido announced that ``optparse`` won (and no, that is not a typo). .. _Optik: http://optik.sf.net/ =========================== `Killing off bdist_dumb`__ =========================== __ http://mail.python.org/pipermail/python-dev/2002-November/030139.html Splinter threads: - `RE: [Distutils] Killing off bdist_dumb <http://mail.python.org/pipermail/python-dev/2002-November/030153.html>`__ - `E: [Distutils] Killing off bdist_dumb <http://mail.python.org/pipermail/python-dev/2002-November/030219.html>`__ A.M. Kuchling asked if anyone would mind if bdist_dumb was removed from distutils (the conversation also happened with `distutils-sig`_ ). Apparently it is rather broken in terms of the paths of the files because it makes them all relative. M.A. Lemburg, though, spoke up stating that he uses bdist_dumb. It still wasn't fully resolved as of this writing. The point of being able to build bdist_wininst on non-Windows platforms came up during this discussion as well. It was decided to move the binary files needed for bdist_wininst into CVS (now filed as `bug #638595`_ ). .. _distutils-sig: http://www.python.org/sigs/distutils-sig/ .. _bug #638595: http://www.python.org/sf/638595 =============================================== `Python interface to attribute descriptors`__ =============================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030118.html Splinter threads: - `Python interface to attribute descriptors <http://mail.python.org/pipermail/python-dev/2002-November/030213.html>`__ Paul Dubois decided to cause himself some grief and attempt to comprehend the miracle that is descriptors (more info can be found in the `2.2.2 What's New`_ doc and in `PEP 252`_). He was wondering if their was more documentation than the signatures of the functions for the C API. He also wanted to know if there was a way to play with them in the Python world since all of his attempts fell short of them being "first-class citizen from Python". Guido admitted that the docs were lacking. He then asked for some help in writing the docs. He responded to Paul's second question by saying that he thought it should work as long as you avoided classic classes. Thanks to Guido saying that is should work, Paul realized that he misread the PEP. To be nice he emailed out an example of how a descriptor could know where it came from at http://mail.python.org/pipermail/python-dev/2002-November/030141.html . Phillip Ebey also chimed in on how to write a metaclass that said the name of the descriptor at http://mail.python.org/pipermail/python-dev/2002-November/030213.html . .. _2.2.2 What's New: http://www.python.org/doc/2.2.2/whatsnew/sect-rellinks.html#SECTION00032000… .. _PEP 252: http://www.python.org/peps/pep-0252.html ============================== `IDLE local scope cleanup`__ ============================== __ http://mail.python.org/pipermail/python-dev/2002-November/030124.html Patrick O'Brien (author of PyCrust_ ) wondered how IDLE managed to keep its local scope so clean once it finished launching. Guido said that IDLE (or at least the GRPC version) runs the shell in a subprocess that is careful not to pollute the namespace. Patrick thanked Guido and then presented his real question: how to handle not polluting the namespace with a way getting around a pickling issue. He "used to just pass a regular dictionary to code.InteractiveInterpreter, which worked well enough", but there was an issue with pickling. So then he tried passing ``sys.modules['__main__'].__dict__``, which worked but cluttered the namespace. Guido's response: "Remove the clutter". Guido said that this would most likely require a minimalistic main program that bootstrapped using ``__import__('run').main()`` which would run the code without adding to the namespace. .. _PyCrust: http://www.orbtech.com/wiki/PyCrust

1 0

Re: [Python-Dev] [maintenance doc updates]
by Patrick K. O'Brien 16 Nov '02

16 Nov '02

On Friday 15 November 2002 06:59 pm, Fred L. Drake wrote: > The maintenance version of the documentation has been updated: > > http://www.python.org/dev/doc/maint22/ > > Small updates. > Add embarrassing note about sneaky feeping creaturism: > The "chars" argument to str.strip(), .lstrip(), and .rstrip(), as > well as the str.zfill() method, were all added in Python 2.2.2! > Woe to over-eager backporters! The string module docstrings for lstrip and rstrip need updating as well then. It looks like only strip has been updated so far. And it would be good if this argument was called the same thing in the string type as in the string module. The one calls it `sep` and the other `chars`. In fact, the docstring for string.strip mixes the two: def strip(s, chars=None): """strip(s [,chars]) -> string Return a copy of the string s with leading and trailing whitespace removed. If chars is given and not None, remove characters in sep instead. If chars is unicode, S will be converted to unicode before stripping. """ return s.strip(chars) The docstring for the type still calls it `sep`, as does lstrip and rstrip: PyDoc_STRVAR(strip__doc__, "S.strip([sep]) -> string or unicode\n\ \n\ Return a copy of the string S with leading and trailing\n\ whitespace removed.\n\ If sep is given and not None, remove characters in sep instead.\n\ If sep is unicode, S will be converted to unicode before stripping"); It looks like the documentation is consistent in calling it `chars`, but the implementation is lagging behind. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------

1 0