Seen on perl5-porters:
>...and thus providing a rationale for C<exists $foo>, as opposed
>C<defined $foo> 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
the abstruse into the quotidian, thereby reducing the already
debatable accessibility of Perl by those common masses who need it
most--all because of the irrepressible urge by the destructively
clever to continue unfettered these labyrinthine embellishments,
gratuitous nuances of surpassing subletly and dubious utility. Let
your true be true and your false be false, and add not to the
confusing number of falsehoods, lest the resulting eminently
confusable shadings be forever beyond the ken of mortal men trying
to get their jobs done without first subjecting themselves to
of monastic study.
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
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
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... :-)
Python Pages: http://www.lemburg.com/python/
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 semantics of
"from X to Y" for aribtrary X and Y that the interpreter should let
non-integer indices pass.
Skip Montanaro | http://www.mojam.com/
skip(a)mojam.com | http://www.musi-cal.com/
"Languages that change by catering to the tastes of non-users tend not to do
so well." - Doug Landauer
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 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
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
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.
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).
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 */
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)
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).
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
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
Doc for the new class will also be needed, but (of course) the old doc
Any comments on the module and/or its inclusion into 1.6?
Greg Stein, http://www.lyra.org/
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 reinventing the wheel.
* No confusion about what exception Python programmers should catch. In the
same way that "OSError" will be thrown any time the C runtime library fails,
the "Win32Error" exception will be thrown whenever a Win32 API function
(called directly) fails.
This has come up now that I am looking at a "win32reg" (or "_win32reg")
module for inclusion in Python 1.6. It makes sense to me that rather than
creating specific exceptions for each new module of this ilk, we define a
single exception able to be shared by any core or 3rd party module that
Ideally, this exception should derive from "EnvironmentError" - however,
this is pretty specific to the OSError mechanics. The other alternatives
are to create a Win32Error that derives directly from "StandardError", or to
introduce an intermediate "PlatformError".
The Win32 extensions have been doing this for ages (ie, every win32*.pyd
module shares and raises the same exception object) and IMO it is a good
thing. If we do go this route, the Win32 exceptions could also share this
exception object, which is, IMO, also a good thing (in the same way that
extension modules now can already raise OSError without a need to redefine
the semantics each time)
Does anyone have thoughts on this? Is it a good thing or a bad thing?
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 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
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
If not set, the slash charac-
ter is treated as an ordinary
and in the GNU/Linux manual as
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
DOS/Windows : \ (and maybe / too?)
I propose changing the signature of 'fnmatch.translate()' from
to at least
and possibly to
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
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
> > #define Py_TPFLAGS_DEFAULT (Py_TPFLAGS_HAVE_GETCHARBUFFER)
> I would modify this to include Py_TPFLAGS_HAVE_SEQUENCE_IN by default.
> The flag means that the code knows that the sq_contains field exists;
> not that this particular object has a non-NULL value in it. So it can
> always be on in code compiled with this version of the header file.
Guido: adding new flags is *only* necessary when you want to avoid changes
in the PYTHON_API_VERSION. If the API has already changed between 1.5 and
1.6, then PYTHON_API_VERSION should be bumped, and this new tp_flags value
is not necessary.
In fact, when you bump the VERSION, it can even be argued that these
specific flags get obsoleted (since an extension must be compiled with the
new VERSION to be properly loaded, which makes it pick up the new slot).
So... I'd pose this question to you, Guido: will the API version be bumped
for Python 1.6? If so, then we have some potential cleanup that can occur.
(note: tp_flags is not *reserved* for slot extensions; it is simply that
we haven't discovered any other flags to put in there yet)
> > ***************
> > *** 1405,1410 ****
> > --- 1432,1439 ----
> > 0, /*tp_str*/
> > (getattrofunc)instance_getattr, /*tp_getattro*/
> > (setattrofunc)instance_setattr, /*tp_setattro*/
> > + 0, /* tp_as_buffer */
> > + Py_TPFLAGS_HAVE_SEQUENCE_IN, /* tp_flags */
> This could be Py_TPFLAGS_DEFAULT.
I'd rephrase as *should*.
Remember: the flag bits (as used today) are to determine whether a slot
exists -- in lieu of changing the PYTHON_API_VERSION. Once you compile
under the new definition of PyBufferProcs or PySequenceMethods, then the
slots will definitely exist; therefore, Py_TPFLAGS_DEFAULT should be used.
Greg Stein, http://www.lyra.org/
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
some experience with similar setups.
Python does compile (I had to disable the fcntl module though) and
seems to run fine. My mx Extensions also compile and import
properly, but I haven't run any extended tests yet.
Has Python already been tested extensively on 64-bit machines ?
Thanks for any hints,
Python Pages: http://www.lemburg.com/python/
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 the other patches
were ignored or delayed? I don't know. (May be bad english? I'm no native
speaker) However the new patch submission guide lines on python.org are fine.
But additionally the page should point out, *where* to submit patches
for the documentation subtree: Either to patches(a)python.org
or to python-docs(a)python.org as before. It should definitely be the same
address, which will be referenced by the mailto:-links on each
page of the upcoming Python-1.6-HTML-documentation.
Regards from Germany and have nice weekend, Peter
Peter Funk, Oldenburger Str.86, 27777 Ganderkesee, Tel: 04222 9502 70, Fax: -60