Mailman 3 June 2002 - Python-Dev

pymemcompat.h & PyMem_New and friends
by Michael Hudson 10 Jun '02

10 Jun '02

Michael Hudson <mwh(a)python.net> writes: > /* There are three "families" of memory API: the "raw memory", "object > memory" and "object" families. (This is ignoring the matter of the > cycle collector, about which more is said below). Of course this is an over-simplification. There is at least one other family in fairly widespread use in the Python core; the "typed memory allocator", PyMem_New, PyMem_Resize and PyMem_Del. Should this family be listed in pyemcompat.h or subtly discouraged? (I don't think there are any other options). I think it should be subtly discouraged, for a couple of reasons: a) three is a smaller number than four. b) there is a non-analogy: PyMem_Malloc ---> PyMem_New PyObject_Malloc ---> PyObject_New They do rather different things. c) I don't think omitting a cast and a sizeof is that much of a win. I'm not proposing actually taking these interfaces away. (as a special bonus I won't even mention the fact that we have PyMem_Resize, PyObject_GC_Resize (only used in listobject.c) but not PyObject_Resize...) Cheers, M. -- If a train station is a place where a train stops, what's a workstation? -- unknown (to me, at least)

2 1

Subclassing threading.Thread
by Bernard Yue 09 Jun '02

09 Jun '02

Attached files test1.py and test2.py produce different result. Is it a bug? Bernie #!/usr/bin/env python import socket import threading class server: def __init__(self): self._addr_local = ('127.0.0.1', 25339) self._s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self._s.bind(self._addr_local) def test(): for i in range(10): a = threading.Thread( target=server) a.start() a.run() a.join() if __name__ == '__main__': test() #!/usr/bin/env python import socket import threading class server(threading.Thread): def __init__(self): threading.Thread.__init__(self) self.__addr_local = ('127.0.0.1', 25339) self.__s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.__s.bind(self.__addr_local) def test(): for i in range(10): a = server() a.start() a.run() a.join() if __name__ == '__main__': test()

2 1

Changing ob_size to [s]size_t
by Perry Greenfield 08 Jun '02

08 Jun '02

Guido writes: > I'm not very concerned about strings or lists with more than 2GB > items, but I am concerned about other memory buffers. Those in the Numeric/numarray community, for one, would also be concerned. Although there aren't many data arrays these days that are larger than 2GB there are some beginning to appear. I have no doubt that within a few years there will be many more. I'm not sure I understand all the implications of the discussion here, but it sounds like an important issue. Currently strings are frequently used as a common "medium" to pass binary data from one module to another (e.g., from Numeric to PIL); limiting strings to 2GB may prove a problem in this area (though frankly, I suspect few will want to use them as temporary buffers for objects that size until memories have grown a bit more :-). Perry Greenfield

5 9

Bizarre new test failure
by Tim Peters 07 Jun '02

07 Jun '02

Guido noticed this on Linux late this afternoon. I've seen it on Win2K and Win98SE since. test_gc fails if you run the whole test suite from the start: test test_gc failed -- test_list: actual 10, expected 1 This seems impossible (look at the test). It doesn't fail in isolation. It fails in both debug and release builds. Not *all* tests before test_gc need to be run in order to provoke a failure, but I can detect no sense in which do need to be run (not just one or two, but lots of them). Here are the files that changed between a Python that does work (yesterday) and now: P python/configure P python/configure.in P python/pyconfig.h.in P python/Doc/lib/libgetopt.tex P python/Doc/lib/libsocket.tex P python/Lib/copy.py P python/Lib/fileinput.py P python/Lib/getopt.py P python/Lib/posixpath.py P python/Lib/shutil.py P python/Lib/socket.py P python/Lib/compiler/pyassem.py P python/Lib/compiler/pycodegen.py P python/Lib/compiler/transformer.py P python/Lib/distutils/command/clean.py P python/Lib/test/test_b1.py P python/Lib/test/test_commands.py P python/Lib/test/test_descr.py P python/Lib/test/test_getopt.py P python/Lib/test/test_socket.py U python/Lib/test/test_timeout.py P python/Misc/ACKS P python/Misc/NEWS P python/Modules/gcmodule.c P python/Modules/socketmodule.c P python/Modules/socketmodule.h P python/Objects/abstract.c P python/Objects/complexobject.c P python/Objects/rangeobject.c P python/Tools/webchecker/webchecker.py While Jeremy did fiddle gcmodule.c, that isn't the cause. I changed the test like so: def test_list(): import sys l = [] l.append(l) gc.collect() del l gc.set_debug(gc.DEBUG_SAVEALL) n = gc.collect() print >> sys.stderr, '*' * 30, n, gc.garbage expect(n, 1, "list") Here's the list of garbage objects it found: [<class 'test_descr.mysuper'>, {'__dict__': <attribute '__dict__' of 'mysuper' objects>, '__module__': 'test_descr', '__weakref__': <member '__weakref__' of 'mysuper' objects>, '__doc__': None, '__init__': <function __init__ at 0x00CC00D8>}, (<class 'test_descr.mysuper'>, <type 'super'>, <type 'object'>), (<type 'super'>,), [[...]], <attribute '__dict__' of 'mysuper' objects>, <member '__weakref__' of 'mysuper' objects>, <function __init__ at 0x00CC00D8>, (<cell at 0x00CB4DB0: type object at 0x00768420>,), <cell at 0x00CB4DB0: type object at 0x00768420>] The recursive list: [[...]] is the only one expected here. Your turn <wink>.

8 21

d.get_key(key) -> key?
by Daniel 'eikeon' Krech 07 Jun '02

07 Jun '02

While attempting to "intern" the nodes in our rdflib's triple store I have come across the following question. Is there or could there be an efficient way to get an existing key from a dictionary given a key that is == but whose id is not. For example: given a==b and id(a)!=id(b) and d[a] = 1 what is the best way to: d.get_key(b) -> a --eikeon, http://eikeon.com/ PS: Here is the code where I am trying to get rid of multiple instances of equivalent nodes: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/redfoot/rdflib-1.0/rdflib/st… and a not so efficient first attempt: # (could use a s.get(e2)->e1 as well given e1==e2 and id(e1)!=id(e2)) class Set(object): def __init__(self): self.__set = [] def add(self, obj): e = self.get(obj) if e: # already have equivalent element, so return the one we have return e else: self.__set.append(obj) return obj def get(self, obj): if obj in self.__set: for e in self.__set: if e==obj: return e return None class Intern(object): def __init__(self): super(Intern, self).__init__() self.__nodes = Set() def add(self, subject, predicate, object): subject = self.__nodes.add(subject) predicate = self.__nodes.add(predicate) object = self.__nodes.add(object) super(Intern, self).add(subject, predicate, object)

7 29

Changing ob_size to [s]size_t
by loewis＠informatik.hu-berlin.de 07 Jun '02

07 Jun '02

What terrible things would happen if ob_size would be changed from int to size_t? The question recently came up on comp.lang.python, where the poster noticed that you cannot mmap large files on a 64-bit system where int is 32 bits; there is a 2Gib limit on the length of objects on his specific system. About the only problem I can see is that you could not store negative numbers anymore. Is ssize_t universally available, or could be used on systems where it is available? Regards, Martin

7 17

Making doc strings optional
by loewis＠informatik.hu-berlin.de 07 Jun '02

07 Jun '02

I'm ready to apply patch #505375. Any objections? Martin

1 0

Proto-PEP for maintaining backward compatibility
by Neal Norwitz 07 Jun '02

07 Jun '02

Since the subject has come up several times recently, and some one (Walter?) suggested a PEP be written....here goes. Attached is a draft PEP. Comments? Neal PEP: XXX Title: Backward Compatibility for Standard Library Version: $Revision:$ Last-Modified: $Date:$ Author: neal(a)metaslash.com (Neal Norwitz) Status: Draft Type: Informational Created: 06-Jun-2002 Post-History: Python-Version: 2.3 Abstract This PEP describes the packages and modules in the standard library which should remain backward compatible with previous versions of Python. Rationale Authors have various reasons why packages and modules should continue to work with previous versions of Python. In order to maintain backward compatibility for these modules while moving the rest of the standard library forward, it is necessary to know which modules can be modified and which should use old and possibly deprecated features. Generally, authors should attempt to keep changes backward compatible with the previous released version of Python in order to make bug fixes easier to backport. Backward Compatible Packages & Modules Package/Module Maintainer(s) Python Version -------------- ------------- -------------- distutils Andrew Kuchling 1.5.2 email Barry Warsaw 2.1 sre Fredrik Lundh 1.5.2 xml (PyXML) Martin v. Loewis 2.0 Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End:

6 20

OT: Performance vs. Clarity vs. Convention
by Patrick K. O'Brien 07 Jun '02

07 Jun '02

Forgive me if this is slightly off-topic for this list, but since we've been talking about migration guides and coding idioms and tweaking performance and such, I've got a few questions I'd like to ask. I'll start with an actual code sample. This is a very simple class that's part of an xhtml toolkit I'm writing. class Comment: def __init__(self, content=''): self.content = content def __call__(self, content=''): o = self.__class__(content) return str(o) def __str__(self): return '' % self.content def __repr__(self): return repr(self.__str__()) When I look at this, I see certain decisions I've made and I'm wondering if I've made the best decisions. I'm wondering how to balance performance against clarity and proper coding conventions. 1. In the __call__ I save a reference to the object. Instead, I could simply: return str(self.__class__(content)) Is there much of a performance impact by explicitly naming intermediate references? (I need some of Tim Peter's performance testing scripts.) 2. I chose the slightly indirect str(o) instead of o.__str__(). Is this slower? Is one style preferred over the other and why? 3. I used a format string, '' % self.content, where I could just as easily have concatenated '' instead. Is one faster than the other? 4. Is there any documentation that covers these kinds of issues where there is more than one way to do something? I'd like to have some foundation for making these decisions. As you can probably guess, I usually hate having more than one way to do anything. ;-) --- Patrick K. O'Brien Orbtech

4 8

Where to put wrap_text()?
by Greg Ward 07 Jun '02

07 Jun '02

Hidden away in distutils.fancy_getopt is an exceedingly handy function called wrap_text(). It does just what you might expect from the name: def wrap_text (text, width): """wrap_text(text : string, width : int) -> [string] Split 'text' into multiple lines of no more than 'width' characters each, and return the list of strings that results. """ Surprise surprise, Optik uses this. I've never been terribly happy about importing it from distutils.fancy_getopt, and putting Optik into the standard library as OptionParser is a great opportunity for putting wrap_text somewhere more sensible. I happen to think that wrap_text() is useful for more than just auto-formatting --help messages, so hiding it away in OptionParser.py doesn't seem right. Also, Perl has a Text::Wrap module that's been part of the standard library for not-quite-forever -- so shouln't Python have one too? Proposal: a new standard library module, wrap_text, which combines the best of distutils.fancy_getopt.wrap_text() and Text::Wrap. Right now, I'm thinking of an interface something like this: wrap(text : string, width : int) -> [string] Split 'text' into multiple lines of no more than 'width' characters each, and return the list of strings that results. Tabs in 'text' are expanded with string.expandtabs(), and all other whitespace characters (including newline) are converted to space. [This is identical to distutils.fancy_getopt.wrap_text(), but the docstring is more complete.] wrap_nomunge(text : string, width : int) -> [string] Same as wrap(), without munging whitespace. [Not sure if this is really useful to expose publicly. Opinions?] fill(text : string, width : int, initial_tab : string = "", subsequent_tab : string = "") -> string Reformat the paragraph in 'text' to fit in lines of no more than 'width' columns. The first line is prefixed with 'initial_tab', and subsequent lines are prefixed with 'subsequent_tab'; the lengths of the tab strings are accounted for when wrapping lines to fit in 'width' columns. [This is just a glorified "\n".join(wrap(...)); the idea to add initial_tab and subsequent_tab was stolen from Perl's Text::Wrap.] I'll go whip up some code and submit a patch to SF. If people like it, I'll even write some tests and documentation too. Greg -- Greg Ward - Unix nerd gward(a)python.net http://starship.python.net/~gward/ Support bacteria -- it's the only culture some people have!

13 28

Re: [Python-Dev] trace.py and the obscurity of Tools/scripts/ (was: Unittest list)
by Michael Hudson 06 Jun '02

06 Jun '02

Zooko <zooko(a)zooko.com> writes: > Since even python-dev'ers find ancient copies of trace.py on ftp > sites before they find the one in the Tools/scripts/ directory, and > since the debian package of Python 2.2 comes without a > Tools/scripts/ directory at all, I conclude that the Tools/scripts/ > directory it isn't doing its job very well. I suggest it either be > killed or fixed. I'm not sure how to do the latter -- link to it > from the doc pages? Kill it and I'll be after you with an axe. Admittedly there's a lot of cruft that should be removed, rewritten or reorganised, but there's some mighty useful stuff there too (eg. logmerge.py). I don't see why I should suffer just because other people don't know where to look... Cheers, M. -- Darned confusing, unless you have that magic ingredient coffee, of which I can pay you Tuesday for a couple pounds of extra-special grind today. -- John Mitchell, 11 Jan 1999

9 16

Re: [Python-checkins] python/dist/src/Lib getopt.py,1.17,1.18
by loewis＠informatik.hu-berlin.de 06 Jun '02

06 Jun '02

Neal Norwitz <neal(a)metaslash.com> writes: > For additions to the stdlib, should we try to make sure new features > are used? In the above code, type(longopts) ... -> > isinstance(longopts, str) (or basestring?) and all_options_first > could be a bool. Done. It really should be ,str), since Unicode in command line options is not yet support (although they should be, since, on Windows, command line options are "natively" Unicode). Regards, Martin

1 0

"max recursion limit exceeded" canned response?
by Skip Montanaro 05 Jun '02

05 Jun '02

How would we go about adding a canned response to the commonly submitted "max recursion limit exceeded" bug report? I think Tim's discussion of re design patterns to use in http://python.org/sf/493252 (or something like it) probably belongs in the re module docs since this is such a common stumbling block for people used to using ".*?". I'll work something up for the Examples section and Jake's hockey game this morning. Skip

4 5

Socket timeout patch
by Michael Gilfix 05 Jun '02

05 Jun '02

The socket timeout patch is finally available with doc updates n' unit test as patch #555085 in the SF tracker. This implementation provides timeout functionality at the C level. A patch to socket.py also fixes the problem of losing data while an exception is thrown to the underlying socket. -- Mike -- Michael Gilfix mgilfix(a)eecs.tufts.edu For my gpg public key: http://www.eecs.tufts.edu/~mgilfix/contact.html

3 10

Patch #473512
by Martin v. Loewis 05 Jun '02

05 Jun '02

I'm ready to apply patch 473512 : getopt with GNU style scanning, which adds getopt.gnu_getopt. Any objections? Regards, Martin

5 7

SF sending content-free emails
by Guido van Rossum 05 Jun '02

05 Jun '02

You may have noticed that the SF tracker is sending email that doesn't contain any content, when an item is updated. I've filed a bug report with SF. http://sourceforge.net/tracker/index.php?func=detail&aid=565001&group_id=1&… Gordon, how's the roundup project coming along? :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

'compile' error message
by Thomas Heller 05 Jun '02

05 Jun '02

Consider: Python 2.3a0 (#29, Jun 5 2002, 13:09:10) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> compile("1+*3", "myfile.py", "exec") Traceback (most recent call last): File "<stdin>", line 1, in ? File "<string>", line 1 1+*3 ^ SyntaxError: invalid syntax >>> Shouldn't it print "myfile.py" instead of "<string>"? Thomas

4 4

xrange identity crisis
by Oren Tirosh 05 Jun '02

05 Jun '02

It seems that the xrange object in the current CVS can't make up its mind whether it's an iterator or an iterable: >>> iterables = ["", (), [], {}, file('/dev/null'), xrange(10)] >>> iterators = [iter(x) for x in iterables] >>> for x in iterables + iterators: ... print hasattr(x, 'next'), x is iter(x), type(x) ... False False <type 'str'> False False <type 'tuple'> False False <type 'list'> False False <type 'dict'> False False <type 'file'> True False <type 'xrange'> True True <type 'iterator'> True True <type 'iterator'> True True <type 'listiterator'> True True <type 'dictionary-iterator'> True True <type 'xreadlines.xreadlines'> True False <type 'xrange'> Generally, iterables don't have a next() method and return a new object each time they are iter()ed. Iterators do have a next() method and return themselves on iter(). xrange is a strange hybrid. In Python 2.2.0/1 xrange behaved just like the other iterables: >>> iterables = ["", (), [], {}, file('/dev/null'), xrange(10)] >>> iterators = [iter(x) for x in iterables] >>> for x in iterables + iterators: ... print hasattr(x, 'next'), x is iter(x), type(x) ... 0 0 <type 'str'> 0 0 <type 'tuple'> 0 0 <type 'list'> 0 0 <type 'dict'> 0 0 <type 'file'> 0 0 <type 'xrange'> 1 1 <type 'iterator'> 1 1 <type 'iterator'> 1 1 <type 'iterator'> 1 1 <type 'dictionary-iterator'> 1 1 <type 'xreadlines.xreadlines'> 1 1 <type 'iterator'> What's the rationale behind this change? Oren

6 16

Changes to PEP 8 & 42
by Neal Norwitz 04 Jun '02

04 Jun '02

I've also got a change to PEP 8 (for basestring). Is the wording ok? Should I check it in or should Barry/Guido? Also, it seems that PEP 42 is a bit out of date. I think the stat/statvfs changes may be done (at least started), the std library uses 4 space indents, math.radians/degrees were added. Probably others too. Neal -- Index: pep-0008.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0008.txt,v retrieving revision 1.13 diff -C1 -r1.13 pep-0008.txt *** pep-0008.txt 29 May 2002 16:07:27 -0000 1.13 --- pep-0008.txt 3 Jun 2002 20:25:54 -0000 *************** *** 542,548 **** When checking if an object is a string, keep in mind that it ! might be a unicode string too! In Python 2.2, the types module ! has the StringTypes type defined for that purpose, e.g.: ! from types import StringTypes: ! if isinstance(strorunicodeobj, StringTypes): --- 542,547 ---- When checking if an object is a string, keep in mind that it ! might be a unicode string too! In Python 2.3, str and unicode ! have a common base class, basestring, so you can do: ! if isinstance(strorunicodeobj, basestring):

3 2

Python 2.3 release schedule
by Guido van Rossum 04 Jun '02

04 Jun '02

The Python 2.3 release schedule as laid out in PEP 283 is unrealistic. It has May 22 (yesterday) as the release date for 2.3a1, and then promises successive releases at approximately 4-week intervals. I think we're nowhere near doing the first alpha release. PythonLabs has been consumed by high priority Zope projects. There's a little less pressure now, and we can go back to thinking about Python releases, but we've lost a lot of time. We haven't even appointed a release manager! (Or the appointment was never recorded in the PEP.) In the discussion about release stability, it was brought up that the release schedule should be driven by feature completeness, not by the calendar. I basically agree, although I believe that when it takes the responsible party for a particular feature forever to implement it, it's better to move the feature to future release than to hold up the release forever. So let's discuss features for 2.3. PEP 283 mentions these: > PEP 266 Optimizing Global Variable/Attribute Access Montanaro > PEP 267 Optimized Access to Module Namespaces Hylton > PEP 280 Optimizing access to globals van Rossum (These are basically three friendly competing proposals.) Jeremy has made a little progress with a new compiler, but it's going slow and the compiler is only the first step. Maybe we'll be able to refactor the compiler in this release. I'm tempted to say we won't hold our breath for this one. > PEP 269 Pgen Module for Python Riehl I haven't heard from Jon Riehl, so I consider dropping this idea. > PEP 273 Import Modules from Zip Archives Ahlstrom I think this is close -- maybe it's already checked in and I don't know about it! > PEP 282 A Logging System Mick Vinay Sajip has been making steady progress on an implementation, and despite a recent near-flamewar (which I haven't followed) I expect that his code will be incorporated in the near future. That's it as far as what PEP 283 mentions (there's also a bunch of things already implemented, like bool, PyMalloc, universal newlines). Here are some ideas of my own for things I expect to see in 2.3a1: - Provide alternatives for common uses of the types module; essentially Skip's proto-PEP. - Extended slice notation for all built-in sequences. Wasn't Raymond Hettinger working on this? - Fix the buffer object??? http://mail.python.org/pipermail/python-dev/2002-May/023896.html - Lazily tracking tuples? Neil, how's that coming? http://mail.python.org/pipermail/python-dev/2002-May/023926.html - Timeoutsocket. Work in progress. http://mail.python.org/pipermail/python-dev/2002-May/024077.html - Making None a keyword. Can't be done right away, but a warning would be a first step. http://mail.python.org/pipermail/python-dev/2002-April/023600.html - Stage 2 of the int/long integration (PEP 237). This mostly means warning about situations where hex, oct or shift of an int returns a different value than for the same value as a long. (I think the PEP misses this step, but it's necessary -- we can't just change the semantics silently without warning first.) - I think Andrew Kuchling has a bunch of distutils features planned; how's that coming? - PEP 286??? (MvL: Enhanced argument tuples.) I haven't had the time to review this thoroughly. It seems a deep optimization hack (also makes better correctness guarantees though). - A standard datetime type. An implementation effort is under way: http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage Effbot and MAL have a proposal for a basic interface that all datetime types should implement, but there are some problems with UTC. A decision needs to be made. Anything else? --Guido van Rossum (home page: http://www.python.org/~guido/)

10 22

Draft Guide for code migration and modernation
by Raymond Hettinger 04 Jun '02

04 Jun '02

Here is my cut at the migration and modernization guide. Comments are welcome. Walter and Neal, would you like to add the somewhat more involved steps for eliminating the types and strings modules. Raymond Hettinger ----------------------------------------------- Code Modernization and Migration Guide Pattern: if d.has_key(k): --> if k in d: Idea: For testing dictionary membership, use the 'in' keyword instead of the 'has_key()' method. Version: 2.2 or greater Benefits: The result is shorter and more readable. The style becomes consistent with tests for membership in lists. The result is slightly faster because has_key requires an attribute search. Locating: grep has_key Contra-indications: 1. if dictlike.has_key(k) ## objects like shelve do not define __contains__() Pattern: for k in d.keys() --> for k in d for k in d.items() --> for k in d.iteritems() for k in d.values() --> for k in d.itervalues() Idea: Use the new iter methods for looping over dictionaries Version: 2.2 or greater Benefits: The iter methods are faster because the do not have to create a new list object with a complete copy of all of the keys, values, or items. Selecting only keys, items, or values as needed saves the time for creating unused object references and, in the case of items, saves a second hash look-up of the key. Contra-indications: 1. def getids(): return d.keys() ## do not change the return type 2. for k in dictlike.keys() ## objects like shelve do not define itermethods 3. k = d.keys(); j = k[:] ## iterators do not support slicing, sorting or other operations 4. for k in d.keys(): del[k] ## dict iterators prohibit modifying the dictionary Pattern: if v == None --> if v is None: Idea: Since there is only one None object, it can be tested with identity. Version: Any Benefits: Identity tests are slightly faster than equality tests. Also, some object types may overload comparison to be much slower (or even break). Locating: grep '== None' or grep '!= None' Pattern: os.stat("foo")[stat.ST_MTIME] --> os.stat("foo").st_mtime os.stat("foo")[stat.ST_MTIME] --> os.path.getmtime("foo") Idea: Replace stat contants or indices with new stat methods Version: 2.2 or greater Benefits: The methods are not order dependent and do not require an import of the stat module Locating: grep os.stat Pattern: import whrandom --> import random Idea: Replace deprecated module Version: 2.1 or greater Benefits: All random methods collected in one place Locating: grep whrandom

7 13

Adding Optik to the standard library
by Greg Ward 04 Jun '02

04 Jun '02

I think it's time to declare the work of the getopt-sig finished: several competing proposals were put forward, but Optik appears to be the only really complete, documented, field-tested (by someone other than its author) library. Not everyone on the getopt-sig will agree, but I think that's the broad consensus. Take this with a grain of salt, though -- I'm biased. ;-) Anyways, I think further consensus is needed on how precisely to add Optik to the standard library. The only constraint I've heard from Guido is to give it a less-cutesy name, which is fine by me. First, background: Optik consists of three modules: optik.option, optik.option_parser, and optik.errors, but that detail is hidden from users -- Optik applications normally just do this: from optik import OptionParser although there are a handful of other names that are occasionally useful to import from the 'optik' package: Option, SUPPRESS_HELP, OptionValueError, etc. Optik's __init__.py file is here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/optik/optik/lib/_… It's only about 1100 lines, including docs and comments and blanks, so they could easily be merged into one module if people think that's preferable. So the main issues are 1) where those names should be imported from (interface), and 2) how the standard library should be rearranged to make this interface unobtrusive and efficient (implementation). I'm going to toss out ideas at random until I get bored. Please provide feedback and/or extra ideas on getopt-sig(a)python.org. IDEA #1: interface: from getopt import OptionParser # and the other Optik names implementation: * turn the getopt module into a package * put the current getopt.py into, say, getopt/classic_getopt.py * make getopt/__init__.py import everything from classic_getopt.py and Optik's three modules, so that either interface is there for the asking pros: * dead simple cons: * applications using just the classic getopt interface suddenly find themselves importing lots more code than they used to IDEA #2: interface: from getopt.option_parser import OptionParser, ... implementation: * as before, getopt.py becomes getopt/classic_getopt.py * getopt/__init__.py consists solely of "from classic_getopt import *" * Optik's three modules are copied into getopt, with the right imports added to getopt/option_parser.py so that applications don't have to worry about where Optik's other names come from pros: * only slightly more burden on apps now using classic getopt cons: * interface is a tad clunkier IDEA #3: interface: from getopt.option_parser import OptionParser, SUPPRESS_HELP, ... from getopt.option import Option from getopt.errors import OptionValueError implementation: * classic getopt handled the same as #2 * just dump Optik's three modules into getopt/ and be done with it pros: * dead simple cons: * clunky interface -- imports expose a lot of implementation detail IDEA #4: interface: same as #1 implementation: * same as #1, except use some funky import-time magic to ensure that the Optik code is only imported if someone actually needs it. Barry Warsaw provided a patch to do this: http://sourceforge.net/tracker/index.php?func=detail&aid=544175&group_id=38… pros: * more efficient for apps using classic getopt cons: * more complicated; apparently Guido expressed distaste for the import-time magic. I'm a little leery of it myself, although I have not carefully read the code. Preferences? Other ideas? Surely the right solution is out there somewhere, just beyond my reach... Greg -- Greg Ward - Unix geek gward(a)python.net http://starship.python.net/~gward/ "Passionate hatred can give meaning and purpose to an empty life." -- Eric Hoffer

12 36

RE: [Python-checkins] python/dist/src/Objects object.c,2.175,2.176
by Tim Peters 04 Jun '02

04 Jun '02

[Guido] > Modified Files: > object.c > Log Message: > Implement the intention of SF patch 472523 (but coded differently). > > In the past, an object's tp_compare could return any value. In 2.2 > the docs were tightened to require it to return -1, 0 or 1; and -1 for > an error. > > We now issue a warning if the value is not in this range. > ... > > I haven't decided yet whether to backport this to 2.2.x. The patch > applies fine. But is it fair to start warning in 2.2.2 about code > that worked flawlessly in 2.2.1? If 2.2.x is the Python-in-a-Tie line, I say "no way". People wearing ties don't care whether a thing is right or wrong, so long as "it works" they simply don't want to hear about it at all. Converting old extensions to avoid new warnings is a 2.3 task for them.

3 4

subclass a module?
by barry＠zope.com 04 Jun '02

04 Jun '02

Am I freaking out, did I missing something, or was the `root' in my root beer float tonight something other than sarsaparilla? -------------------- snip snip -------------------- Python 2.2.1 (#1, May 31 2002, 18:34:35) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> class allmodcons(string): pass ... >>> string <module 'string' from '/usr/local/lib/python2.2/string.pyc'> >>> allmodcons <module '?' (built-in)> -------------------- snip snip -------------------- Can I now subclass from modules? And if so, what good does that do me? -------------------- snip snip -------------------- >>> dir(allmodcons) [] >>> allmodcons.whitespace Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'whitespace' >>> string.whitespace '\t\n\x0b\x0c\r \xa0' >>> -------------------- snip snip -------------------- stickin'-to-herbal-tea-and-dr.-pepper-ly y'rs, -Barry

4 5

zap _Py prefix?
by Skip Montanaro 04 Jun '02

04 Jun '02

The issue of Michael's static PyTimeout_Err symbol reminded me about a question I had about _Py-prefixed symbols. I realize they are all "internal", but I also recall Tim saying a couple of times that the ANSI C standard reserves all symbols which begin with underscores for use by compiler writers. Should the _Py-prefixed symbols be renamed, for example, from _PyUnicode_IsDecimalDigit to Py__Unicode_IsDecimalDigit ? If so, we would then declare that all external symbols which begin with "Py__" were part of the private API. We would of course add macro definitions during the deprecation period: #define _PyUnicode_IsDecimalDigit Py__Unicode_IsDecimalDigit (It would also be nice to #warn when the macros are used. Is that possible with the C preprocessor?) Skip

6 6