Mailman 3 February 2000 - Python-Dev

TomC
by David Ascher Feb. 18, 2000

Feb. 18, 2000

Seen on perl5-porters: >...and thus providing a rationale for C<exists $foo[5]>, as opposed to >C<defined $foo[5]> which is merely checking for an array element >containing a perfectly valid scalar value... Exacerbating the number of ways you can count the disparate but indistinguishable sets of angels dancing on the head of a pin serves no legitimate purpose save to further elevate the priesthood of the triviamasters above neophyte and acolyte alike by needlessly … [View More]

1 0

Unicode Implementation Snapshot 2000-02-18
by M.-A. Lemburg Feb. 17, 2000

Feb. 17, 2000

Hi everybody, I've just uploaded a new snapshot to the secret URL. New in this snapshot is a generic character mapping codec which can decode and encode a large number of code pages used on PCs and Macs. I used a Unicode mapping file parser to automatically generate the codecs from the mapping files available at http://www.unicode.org/ and then included all those files which use less than 10k for the Python source code (with comments). These codecs are thus available and need some serious … [View More]testing: cp855.py iso_8859_6.py cp856.py iso_8859_7.py ascii.py cp857.py iso_8859_8.py charmap.py cp860.py iso_8859_9.py cp1006.py cp861.py koi8_r.py cp1250.py cp862.py latin_1.py cp1251.py cp863.py mac_cyrillic.py cp1252.py cp864.py mac_greek.py cp1253.py cp865.py mac_iceland.py cp1254.py cp866.py mac_latin2.py cp1255.py cp869.py mac_roman.py cp1256.py cp874.py mac_turkish.py cp1257.py iso_8859_10.py raw_unicode_escape.py cp1258.py iso_8859_13.py unicode_escape.py cp424.py iso_8859_14.py unicode_internal.py cp437.py iso_8859_15.py utf_16.py cp737.py iso_8859_2.py utf_16_be.py cp775.py iso_8859_3.py utf_16_le.py cp850.py iso_8859_4.py utf_8.py cp852.py iso_8859_5.py All these codecs are stored in the encodings package of the standard lib and directly useable via the unicode(input, encoding) and u"abc".encode(encoding) APIs. I would like some feedback on which of these code pages are really in common use... we could make all not so common ones available as separate package then. Also, I'm curious if we should rename the cpXXX.py files to cp_XXX.py or not (or whether to just add aliases to the encodings/aliases.py file for them). The naming scheme usually defines letters-numbers-etc. but for code pages the above names are quite common. Another feature of the patch is that it has some optimizations for short Unicode strings. Unfortunately, the implementation still has some bugs, so it is currently disabled. To reenable it, edit the file Objects/unicodeobject.c and set e.g. #define STAYALIVE_SIZE_LIMIT 5 This will cause to the Unicode objects on the free list having a size below or equal to this limit to stay alive even when on the free list. Note that this is the final patch for the next week. I'll be offline until 2000-02-28 and then hope to make some serious progress on documenting the different parts (most docs are still buried in the C and header files and the unicode proposal which is included in the file Misc/unicode.txt). Now it's up to you to give the code the final swirl... :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ [View Less]

1 0

non-integer slice indices?
by Skip Montanaro Feb. 17, 2000

Feb. 17, 2000

Viorel Preoteasa asked on python-help today about supporting slices with non-integer indexes, e.g.: foo['a':'abc'] = some_sequence Currently the Python interpreter (in the slice_index function of ceval.c) enforces integer slice indices. I won't pretend to provide motivation for non-integral slice indices. Instead, I've CC'd Viorel and will let him chime in if he feels the need. It does seem to me that if the __setslice__ programmer is willing to do the type checking and provide the … [View More]

6 9

RFC: malloc cleanup
by Vladimir Marangozov Feb. 17, 2000

Feb. 17, 2000

Since nobody has had a spontaneous comment on the malloc problem I was referring to in my previous message, here is a concrete proposal. BTW, I was thinking on how to deal with *all* malloc problems and solve them definitively starting from <as soon as possible -- 1.6/7> by staying backwards compatible on top of that! Please comment on it, so that I could proceed on working on a patch (which involves lots of files in the distribution, so it'll take me some time verifying the files once … [View More]again, and document the changes). --------------- I'll start with the public malloc interfaces, exported by libpython.a (and Python.h) for third party development. As a second step, I'll attack the "core". The "core" for me are the files in Parser/*, Python/* and Objects/*. I'm considering the files in Modules/* as extensions to the core. (although as long as they are in the standard distribution, one may want to see them as part of the core, but this is a secondary issue). -------------------------------------------------------------------------- Public Malloc (Object) Interface ================================ Functions: 1) PyMem_Malloc / Realloc / Free -- existing wrappers around the Python core malloc - don't call anything on failure. 2) Py_Malloc / Realloc / Free -- existing wrappers around the Python core malloc, calling PyErr_NoMemory on failure 3) _PyObject_New -- object creation, uses Python's core malloc Macros: 4) PyMem_NEW / PyMem_RESIZE -- the existing type-oriented macros *but* implemented in terms of 1). (PyMem_Malloc & PyMem_Realloc) 5) PyObject_NEW -- existing, implemented in terms of 3) 6) PyMem_DEL/XDEL -- existing, *but* pointing to PyMem_Free. PyMem_XDEL is deprecated, but is left for backwards compatibility. Note: everything is implemented on top of 1), the PyMem_Malloc wrappers. This will ensure that compiled C extensions can be used "as is" by new versions of the core (even if the latter has another malloc) ==> no need to recompile them. Questions: a) What about PyMem_DEL? Should it really be deprecated as a "handy alias" for PyMem_Free? Strictly speaking, I'd probably keep it so that PyMem_NEW/DEL form a pair. b) What about introducing PyObject_DEL as the buddy of PyObject_NEW? (also an alias for PyMem_Free). This is really an interface issue, so please adopt an "end-user" point of view. Personally, I'd feel more comfortable writing code like this one, voluntarily made to use the different interfaces (checks omitted). Object initialization: o = PyObject_NEW(spam_struct, &spam_type); /* new spam object */ o->foo = 1; o->bar = PyMem_Malloc(10); /* requesting Python memory */ o->my_buff = malloc(20); /* for personal needs */ Finalization: free(o->my_buff); /* release private mem */ PyMem_Free(o->bar); /* release Python mem */ PyObject_DEL(o); /* release the object */ That is, as a programmer, I don't really want to know what's behind the macros, as long as they come in pairs. I want things to be easier for me as much as possible. Note that as long as I allocate/release my objects with PyObject_NEW/DEL, I can use _any_ malloc I want for private purposes. --------------------------------------------------------------------------- Given the above, the malloc interfaces used by the core (the private ones) should be easier to understand. Basically, we'll have the the same macros (with the same questions a) & b) but everything here is implemented on top of PyMem_MALLOC and friends: Private/Core Malloc (Object) Interface ======================================= 1) PyMem_MALLOC / REALLOC / FREE - raw memory interface, core malloc. 2) _PyObject_New - uses 1) 3) PyMem_NEW / RESIZE / DEL(?) - use 1) PyMem_XDEL is out here. 4) PyObject_NEW / DEL (?) - use 2) & 1) -------------------------------------------------------------------------- The thing is: the public interfaces are always redirected through the wrappers, while the private ones are used (are visible) only by the core, and are based on a raw malloc. This is, IMO, the right approach for avoiding all troubles (past & future) Implementation issue ==================== Solution 1) If the exported and the core malloc interfaces preserve the same (macro) names, we need to introduce some preprocessor magic such that the same macros have different definitions depending on the type of the interface they belong to (public or core). Solution 2) The alternative is to avoid the name clashes by renaming the macros of the _core_ interface (the exported one cannot be changed for backwards compatibility reasons). That is, rename 3) and 4). (Note: 1) is new, 2) is a function) Question: which one is better? (assuming that both of them require the same amount of work ;-) ------------------------------------------------------------------------ That's it. Don't hesitate to ask me for clarifications. All undecided (not approved) parts of the proposal have been marked as such --> Questions. If we manage to agree on the differents questions, I believe that the implementation of this proposal would solve the issue permanently. Thanks for your patience! I'm sick either <0.5 wink> -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 [View Less]

1 0

new httplib?
by Greg Stein Feb. 17, 2000

Feb. 17, 2000

Hi all, I've been using my HTTP/1.1 httplib for quite a while now. It seems quite stable in everything that I've tried. I need to port over the recent changes for SSL stuff, but it is ready to go. The library contains a deprecated, backwards-compat class (HTTP), and its replacement: HTTPConnection. Responses are now handled through HTTPResponse class. Doc for the new class will also be needed, but (of course) the old doc still applies. Any comments on the module and/or its inclusion into 1.… [View More]

4 9

win32 specific exception in the core?
by Mark Hammond Feb. 17, 2000

Feb. 17, 2000

As part of the registry work, Im toying with the idea of a standard "win32 exception" error in the Python core. The reasons why I think a standard exception would be useful are: * Single body of code that knows how to raise these exceptions. Eg, whenever an extension module needs to report that a Win32 API function failed, they can use the core routines to create the exception object - just like they can with OSError. This ensures consistency, and saves each extension module author from … [View More]

10 27

* and ? in fnmatch
by Greg Ward Feb. 17, 2000

Feb. 17, 2000

Hi all -- I have recently been playing with the fnmatch module, and learned that * and ? as considered by 'fnmatch.translate()' match *all* characters, including slashes, colons, backslashes -- in short, whatever happens to be "special" characters for pathnames on the current platform. In other words, "foo?bar.py" matches both "foo_bar.py" and "foo/bar.py". This is not the way any Unix shells that I know of work, nor is it how the wildcard-expanding MS-DOS system calls that I dimly remember … [View More]from a decade or so back worked. I dunno how wildcard expansion is done under Windows nowadays, but I wouldn't expect * and ? to match colons or backslashes there any more than I expect them to match slash under a Unix shell. So is this a bug or a feature? Seems to me that a good fix would be to extend 'fnmatch.translate()' to have some (maybe all?) of the flags that the standard Unix library 'fnmatch()' supports. The flag in question here is FNM_PATHNAME, which is described in the Solaris manual as FNM_PATHNAME If set, a slash (/) character in string will be explicitly matched by a slash in pattern; it will not be matched by either the asterisk (*) or question-mark (?) special characters, nor by a bracket ([]) expression. If not set, the slash charac- ter is treated as an ordinary character. and in the GNU/Linux manual as FNM_PATHNAME If this flag is set, match a slash in string only with a slash in pattern and not, for example, with a [] - sequence containing a slash. To adapt this to Python's 'fnmatch.translate()', I think "slash" would have to be generalized to "special character", which is platform dependent: Unix / DOS/Windows : \ (and maybe / too?) Mac : I propose changing the signature of 'fnmatch.translate()' from def translate(pat) to at least def translate(pat,pathname=0) and possibly to def translate(pat, pathname=0, noescape=0, period=0, leading_dir=0, casefold=0) which follows the lead of GNU 'fnmatch()'. (Solaris 'fnmatch()' only supports the PATHNAME, NOESCAPE, and PERIOD flags; the GNU man page says LEADING_DIR and CASEFOLD are GNU extensions. I like GNU extensions.) Similar optional parameters would be added to 'fnmatch()' and 'fnmatchcase()', possibly dropping the 'casefold' argument since it's covered by which function you're calling. I have yet to fully grok the meaning of those other four flags, though, so I'm not sure how easy it would be to hack them into 'fnmatch.translate()'. Opinions? Greg [View Less]

3 2

tp_flags (was: __contains__ hook, done right)
by Greg Stein Feb. 16, 2000

Feb. 16, 2000

On Wed, 16 Feb 2000, Guido van Rossum wrote: >... > > > > /* PyBufferProcs contains bf_getcharbuffer */ > > #define Py_TPFLAGS_HAVE_GETCHARBUFFER (1L<<0) > > + #define Py_TPFLAGS_HAVE_SEQUENCE_IN (1L<<1) If this flag is going to be defined, then it needs a comment about it. The above code seems to imply that HAVE_SEQUENCE_IN is related to the PyBufferProces. > > > > #define Py_TPFLAGS_DEFAULT (Py_TPFLAGS_HAVE_GETCHARBUFFER) &… [View More]

2 1

Python on 64-bit AIX
by M.-A. Lemburg Feb. 16, 2000

Feb. 16, 2000

Hi everybody, I've noted some discussion about Python on 64-bit platforms on this mailing list lately. The reason I'm posting is that I am currently installing a Python 1.5 interpreter at a client's site which is running AIX 4.3.2 on a 2-processor PowerPC machine. It will use my mx Extensions as add-ons. The compiler used is gcc 2.95.1. Linking is done with the AIX linker. Since I can't possibly check all situations where this setup might fail, I would like to know if anybody else has made … [View More]

6 9

doc patch handling (was: patch handling (which was Python 1.6 timing
by pf＠artcom-gmbh.de Feb. 16, 2000

Feb. 16, 2000

Hi all! First sorry for the intrusion, since I'm not subscribed to this list. I've takeen the opportunity to review the discussion via the pipermail archive and now have a small annotation: AFAIK Fred L. Drake does the actual work on the /Doc sub tree. There is a list python-docs(a)python.org which should be used for comments (patches?) on the Python documentation. A week ago I submitted several small patches to this address and one of them found its way into the CVS immediately, where … [View More]

5 7