Mailman 3 February 2000 - Python-Dev

using ":name" in ParseTuple()
by Greg Stein 25 Feb '00

25 Feb '00

If anyone out there is looking for some straight-forward changes to help with Python development, then here is a chance... I'll get around to submitting patches for this, but it would be much later. So, if somebody can beat me to it... Cheers, -g -- Greg Stein, http://www.lyra.org/ ---------- Forwarded message ---------- Date: Thu, 24 Feb 2000 16:42:12 -0500 From: Guido van Rossum <guido(a)python.org> To: Greg Stein <gstein(a)lyra.org> Cc: python-checkins(a)python.org Subject: Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.63, 2.64 > On a separate track, how about using the ":Name" form in the ParseTuple > calls? It improves the error response a bit more... > > Is that something you'd want to see in all the ParseTuple calls? Ah, darn. I tried ";message" but it's inferior; I'd forgotten about ":name". Yes, that should be standard... Patches, please? --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-checkins mailing list Python-checkins(a)python.org http://www.python.org/mailman/listinfo/python-checkins

2 3

Re: [Patches] Patch to src/Modules/mpzmodule.c
by pf＠artcom-gmbh.de 24 Feb '00

24 Feb '00

Hi! I wrote: > > >This patch allows building the Python 'mpzmodule' under SuSE Linux > > >without having to install the source package of the GMP-libary. > > >The gmp-mparam.h seems to be an internal header file. The patch > > >shouldn't hurt any other platforms. in src/Modules/mpzmodule.c > > >+ #if defined __GLIBC__ && __GLIBC__ >= 2 /*aid building on Linux distributions*/ > > >+ #define BITS_PER_MP_LIMB mp_bits_per_limb > > >+ #else > > > #include "gmp-mparam.h" > > >+ #endif > > Andrew replies: > > This seems like the wrong fix, tying GMP to the version of glibc! > > (They haven't rolled GMP into glibc, have they?) If GMP 2.0 exposes > > an mp_bits_per_limb constant, then the correct patch may just be > > changing BITS_PER_MP_LIMB to mp_bits_per_limb, inside an #ifdef GMP2 > > if necessary. Guido van Rossum wrote: > Darn. I just checked it in. Well, if something better comes up, I'll > check that in. I personally don't care much about this module (have > never bothered to download gmp even so I can't even compile it). I will investigate the source code of earlier versions of GMP in more detail later. May be Andrew is right, that my patch will hurt people, that happen to use a recent version GLIBC together with in ancient version of GMP. However also I believe this is rather unlikely, it shouldn't break. Sorry for the confusion I've caused. Regards, Peter -- Peter Funk, Oldenburger Str.86, 27777 Ganderkesee, Tel: 04222 9502 70, Fax: -60

1 0

Re: [Python-Dev] Re: RFC: malloc cleanup
by Vladimir Marangozov 23 Feb '00

23 Feb '00

Jean-Claude Wippler wrote: > > Hello Vladimir, > > >1) All C extension modules, without exceptions, would be silently redirected > > to use the Python malloc wrappers. Silently means that no one line of code > > would need to be modified and the modules will continue to compile and run > > as before. (i.e. all macros and functions used in C code remain the same) > > Have you taken C++ into account (i.e. new and new[] in the C++ runtime > calling malloc)? As long as Python objects are allocated and freed with PyObject_NEW/DEL, and Python memory is manipulated with the Python malloc interfaces, I don't see a problem, even if the core, or some extensions are compiled with a C++ compiler. C++ constructors and destructors use malloc (usually), but remain completely symmetrical. That is what's allocated via malloc() is released via free(). Why, should I be aware of something special? -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

1 0

Re: [Python-Dev] Re: RFC: malloc cleanup
by Jack Jansen 23 Feb '00

23 Feb '00

One point to think of, with the malloc cleanup: how many places are there where Python allocates something that is passed to some packages which then takes ownership of it (and ultimately free()s it)? And the other way around? For these cases we should probably continue to use malloc()/free() to be on the safe side. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 2

Unicode Implementation in JPython
by bckfnn＠worldonline.dk 23 Feb '00

23 Feb '00

Hi, My feeling on the unicode proposal and its implementation is that most of the changes can be integrated directly into JPython without breaking any existing JPython code. One thing concerns me though: open("out", "wb").write(u"hello") This writes a 10 bytes to the file "out". I have two problems with that: 1. In java, files are always byte-based. To move from unicode chars to bytes some kind of encoder must always be applied. It is also strange to see the actual byte layout of the data, which in my "out" file seems to be platform dependent. Is that the case? If it is, then the write(u"..") strikes me as somewhat random (unknown). 2. To get this behavior under JPython, it is necessary to introduce a new string type which in all other aspects are equal to the existing string type. Only when passed to file.write should the new string type returned a faked representation of its memory. When a normal string is passed to .write, some byte representation of the string is written to the file. I would prefer that in jpython a unicode string is the same as a normal string (type("") == type(u"")). Perhaps the real reason for my dislike of this feature of the unicode implementation is based on my (from java) assumption that a unicode character is an atomic data type. regards, finn

2 2

Expat -- it keeps going, and going, and going ...
by Paul Prescod 22 Feb '00

22 Feb '00

Apologies for the long message. There are a lot of issues to address: There was a clear concensus at the XML-SIG developer's day discussion that Expat should become part of the standard distribution. Admittedly the audience was biased and Fredrik wasn't in the room at that point but it was clear that everyone was in agreement (in contrast to the doc-sig discussion!). I think Andrew had some reservations (he was probably subconsciously channeling Guido) but almost everyone in the room was strongly behind the idea -- and the room was overfull. Insofar as this is not a democracy, I feel the need to channel some of the crowd's opinions and some of my own. The crowd (and I) obviously thought that XML support is an important part of coming with "batteries included" on the modern Web. There are four basic specs maintained by the W3C and IETF that underly the Web: URLs, HTTP, HTML and now XML. In fact, modern versions of HTML (XHTML) and HTTP (WebDAV) depend upon XML. Microsoft is also trying to establish XML-based protocols as replacements for CORBA and as the basis of their entire Web object model. Luckily, the important things to know about XML are very simple. It's a way of encoding hierarchical structures in text using a standard, language-independent syntax that happens to be compatible with document markup syntaxes. Some other things to know about it are: * it is very rigorously defined * there are test suites to verify implementations * it has enough nooks and crannies to be hard to implement * xmllib doesn't implement enough of it * and thus isn't a conforming XML parser xmllib was pretty cool when it was the first XML parser in a general purpose language. Now it is out of date. It is, however, what we present to the world as our "XML support." Whatever we do about expat, we need to decide what to do about the fact that xmllib is not a real XML processor (plus it is slow as hell!). Writing an XML processor is harder than it should be and very few people have the patience to pour over the spec and get it right. Okay, so of course you know where I am leading. Perl, Apache, Mozilla and most other C-coded open source software projects embed expat. This is because expat is blazingly fast, Unicode aware and highly conformant. It's written in ANSI-C and seems stable as a rock. It changes slowly and doesn't have a lot of extra features. Best of all, someone else maintains it and we have wrapped it in a pretty thin C layer which is easy to maintain. The layer is roughly the same size as xmllib. Guido astonished me at IPC8 with a level of humility and honesty that is very rare in this business -- especially coming from a successful language designer. He said that part of why Python didn't grab a bigger part of the CGI market was because he didn't understand the importance of CGI to the Web in the early days. He has also not been shy in saying he doesn't know much about XML. Many of us think that it will be much bigger than CGI. One opinion expressed during the meeting is that XML is a big draw for business, development money and publicity. Okay, having XML in a separate package is not the same as ignoring it altogether but people expect these fundamental technologies to be built in. As soon as you split them out you run into versioning and distribution issues. Yes, distutils will help, but I don't think it will do everything. I don't know of any package management system that can automatically correct version skew problems. The only "system" that works is full-distribution testing. Some feel that we should install PyExpat but not expat. The problem is installation, especially on Windows. It is demonstrably the case that windows programmers are ALREADY nervous about installing the XML toolkit. I got two personal emails about how to install last week (where do people get my email address??) and the XML-SIG list got one or two also. If we install pyexpat without expat, we'll have versioning problems, path problems, multiple DLL problems and so forth. If we statically bind expat and pyexpat the problems go away (on windows at least). There are rumours that some Unixes are not smart in the same situation. This can be solved by renaming symbols before building. This can be accomplished with the C pre-processor. Expat+Pyexpat is about 100K. My Python directory is 35MB so I'm not too worried. I think that the compressed Python tarball is more than 5MB now, isn't it? I'm not big on the idea of multiple Python "distributions" because in practice there will be only two: the portable one and the Windows-specific one. We'll still have to write emails like this imploring the (two) maintainers to support XML or whatever and we may have divergence between the two versions. Distributions make sense in the Linux case because there is a lot of money going around, there is money to be made on shrink-wrapped boxes and it is important to optimize for different cases. For Python, the freebsd model of "the same everywhere" is more appropriate. If that means a more distributed standard library maintenance mechanism, then fine, let's work that out. I don't expect Guido to maintain PyExpat or Expat any more than Larry Wall maintains the Perl XML parser layer or Brian B. maintains the XML support in Apache himself. If we can get concensus on this issue, I will approach James Clark for a more Pythonic license. Right now it has an MPL license but I suspect that James will be flexible. Therefore the concrete proposal is: * add expat, pyexpat and a thin SAX layer to the standard Python distribution * rename symbols in expat if necessary * deprecate xmllib * continue development of the XML toolkit for non-core tools -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski

7 10

davlib.py
by Greg Stein 22 Feb '00

22 Feb '00

One more module for consideration... My DAV client module has been around for a while, has been used in several contexts, and seems to do its job quite fine. However, I'm a bit concerned that it will see continued development over the next year as more WebDAV specs become finalized and turned into RFCs. So the question is: do we add the module now (it is useful), or do we wait for a while? Cheers, -g -- Greg Stein, http://www.lyra.org/

11 28

Re: [Python-Dev] win32 specific exception in the core?
by Jack Jansen 22 Feb '00

22 Feb '00

> Im looking for closure on the Win32 specific exception. Summary for those > that missed the thread: I'm sorry that I'm so late, but I was busy with other things. Anyway: > * I would like a standard exception for Win32 specific errors. The new > hopefully-to-be-standard "win32reg" module could make use of it, the win32 > extensions could switch to it. It is, in my mind at least, analogous to > OSError. Agreed. > My initial proposal called for: > > StandardError: > -> EnvironmentError: > -> IOError > -> OSError > -> Win32Error > > Which would generally lead to people writing "except Win32Error:" > > Tim's suggestion (as I understand it) was: > StandardError: > -> EnvironmentError: > -> IOError > -> OSError > -> CRTError (new - is what os.error would use) > -> Win32Error (new) I also like Mark's idea better. MacOSError has the same problems as Win32Error (different numbering scheme). If OSError can suddenly return numbers from one of three sets we're bound to break a lot of code. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: RFC: malloc cleanup
by Vladimir Marangozov 22 Feb '00

22 Feb '00

[Detailed RFC on a bunch of malloc interfaces] OK, I'll comment first as I'm probably one of the few who understands (what I'm talking about :-) what's this mess is all about in its deepest details while having an overall vision on the issue. So I feel obliged to expose a more friendly explanation. (This turned out to be only 2 screens long, so you may leave it for tomorrow morning ;-) I'll make it simple: What really happens if the RFC gets implemented and how it affects you? ----------------------------------------------------------------------- 1) All C extension modules, without exceptions, would be silently redirected to use the Python malloc wrappers. Silently means that no one line of code would need to be modified and the modules will continue to compile and run as before. (i.e. all macros and functions used in C code remain the same) Consequences: a) You *won't* be required to modify anything, to change your programming habits or to adopt new mandatory interfaces. You could continue the same way as before. b) All *user-defined* Python objects (not the "core" ones, like ints, dicts or strings) would start using the wrappers automatically, which may result in a tiny degradation in their performance. This is the price to pay if we want to make Python user-malloc friendly -- that is, decouple the core from its strong dependency on libc malloc and make 3rd party extensions depend only on Python's memory interfaces when they manipulate Python objects. Currently, the extensions depend on libc malloc (they use "public" memory offered by the system) and there's no way to make them use "private Python memory" for Python objects. BTW, user-defined objects are used far less frequently than the "core" ones. 2) All "core" objects will run as before at the same speed, but they'll use "private Python memory". 3) There would be an opportunity to make the code fancier. This is the whole point of the discussion about the NEW/DEL pairs. Fancier == more logical from the programmer's point of view. This is not mandatory, but it would be desirable to adopt these pairs so that mallocs don't mess again. And I'm volunteering to rename the core and the modules in the distribution so that they look fancier and that they serve as examples for future Python development. But all this remains optional. 4) Last, but not least, this will open the way to change (optionally) Python's core allocator to specialized and more appropriate mallocs than libc malloc. There's only one I know of for the moment (mine <wink>) and it's not "so good". But it looks promising, because it already serves Python better than libc malloc. The current state, however, prevents people to work in this area and to experiment alternatives, because it's very hard to get things working without an expert level knowledge of the internals. I personally find this regrettable and am willing to "repair" it, because I think that Python can make a noticeable profit from a specialized malloc (which may well outperform the tiny degradation caused by the wrappers). ------------ Currently I have a patch which does this the "easy way" -- it does not truly decouple the core from the extensions through the wrappers. However, one can already make experiments by recompiling Python *and* all user extensions with a new malloc. With the patch, Python doesn't dump core anymore, which may be a little gain in your eyes, but a huge one in mine <wink>. FYI, I've corresponded in private with Neil Shemenauer who's working on GC, and he tested & validated the present "easy" version of the patch by saying: > On Sun, Feb 13, 2000 at 04:06:05PM +0100, Vladimir Marangozov wrote: > > I'm appending another patch suite, so that you could test it directly > > on your setup with your malloc. Let me know how it goes. Hope we're > > making progress on this. > > It works for me. It passes the regression test and also does not > leak memory when cycles are created. :) > > > Neil > ------------ So what I'm looking for here is your approval or your objections to the principles I've exposed in this msg and in the RFC. I can presently send a whole bunch of patched files affected by the "easy" way, but it does not solve the real problem. The "easy way" does not redirect the extensions to the wrappers. i.e. it doesn't have the "private Python memory" concept. It *is* a step in the right direction, though. Final word: I'm okay for deferring this issue for future Python releases, if there's no time, no resources, no understanding, whatever (lately, I see a big increase in Python's contributions since the announce of the tight schedule for 1.6). That's why I won't push too much and I don't want to burded the atmosphere with still undecided interfaces -- better take some more time and get them right. OTOH, the sooner we get them right, the better. -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

3 2

Borland release free C++ compiler
by David Ascher 21 Feb '00

21 Feb '00

They've made their compiler free-as-in-beer. http://www.borland.com/about/press/2000/bcppcompiler.html It would be nice to have relevant makefiles in the source tree by the next release. --david

3 2