Mailman 3 August 2000 - Python-Dev

Re: [Python-Dev] Lukewarm about range literals
by Michael Hudson 29 Aug '00

29 Aug '00

Skip Montanaro <skip(a)mojam.com> writes: > One of the original arguments for range literals as I recall was that > indexing of loops could get more efficient. The compiler would know that > [0:100:2] represents a series of integers and could conceivably generate > more efficient loop indexing code (and so could Python2C and other compilers > that generated C code). This argument doesn't seem to be showing up here at > all. Does it carry no weight in the face of the relative inscrutability of > the syntax? IMHO, no. A compiler sufficiently smart to optimize range literals ought to be sufficiently smart to optimize most calls to "range". At least, I think so. I also think the inefficiency of list construction in Python loops is a red herring; executing the list body involves going round & round the eval loop, and I'd be amazed if that didn't dominate (note that - on my system at least - loops involving range are often (marginally) faster than ones using xrange, presumably due to the special casing of list[integer] in eval_code2). Sure, it would be nice is this aspect got optimized, but lets speed up the rest of the interpreter enough so you can notice first! Cheers, Michael -- Very rough; like estimating the productivity of a welder by the amount of acetylene used. -- Paul Svensson, comp.lang.python [on the subject of the measuring programmer productivity by LOC]

1 0

Python 2.0 License Discussion Mailing List Created
by Guido van Rossum 29 Aug '00

29 Aug '00

Now that the CNRI license issues are nearly settled, BeOpen.com needs to put its own license on Python 2.0 (as a derivative work of CNRI's Python 1.6) too. We want an open discussion about the new license with the Python community, and have established a mailing list for this purpose. To participate subscribe, go to http://mailman.beopen.com/mailman/listinfo/license-py20 and follow the instructions for subscribing. The mailing list is unmoderated, open to all, and archived (at http://mailman.beopen.com/pipermail/license-py20/). Your questions, concerns and suggestions are welcome! Our initial thoughts are to use a slight adaptation of the CNRI license for Python 1.6, adding an "or GPL" clause, meaning that Python 2.0 can be redistributed under the Python 2.0 license or under the GPL (like Perl can be redistributed under the Artistic license or under the GPL). Note that I don't want this list to degenerate into flaming about the CNRI license (except as it pertains directly to the 2.0 license) -- there's little we can do about the CNRI license, and it has been beaten to death on comp.lang.python. In case you're in the dark about the CNRI license, please refer to http://www.python.org/1.6/download.html for the license text and to http://www.python.org/1.6/license_faq.html for a list of frequently asked questions about the license and CNRI's answers. Note that we're planning to release the first beta release of Python 2.0 on September 4 -- however we can change the license for the final release. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

2 2

Re: [Python-Dev] Pragma-style declaration syntax
by Jack Jansen 29 Aug '00

29 Aug '00

> The basic syntax in the above examples is: > > "pragma" NAME "=" (NUMBER | STRING+) > > It has to be that simple to allow the compiler use the information > at compilation time. Can we have a bit more syntax, so other packages that inspect the source (freeze and friends come to mind) can also use the pragma scheme? Something like "pragma" NAME ("." NAME)+ "=" (NUMBER | STRING+) should allow freeze to use something like pragma freeze.exclude = "win32ui, sunaudiodev, linuxaudiodev" which would be ignored by the compiler but interpreted by freeze. And, if they're stored in the __pragma__ dictionary too, as was suggested here, you can also add pragmas specific for class browsers, debuggers and such. -- 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

2 1

Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_popen2,1.2,1.3
by Guido van Rossum 28 Aug '00

28 Aug '00

How about popen4? Or is that Windows specific? --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

3 3

Re: [Python-Dev] Re: [PEP 224] Attribute Docstrings
by M.-A. Lemburg 28 Aug '00

28 Aug '00

Aahz Maruch wrote: > > [p&e] > > In article <39AA22A0.D533598A(a)lemburg.com>, > M.-A. Lemburg <mal(a)lemburg.com> wrote: > > > >> >>> docs(instance) > >> {'a': 'Description of a.', 'b': 'Description of b.'} > >> > >> There are repercussions here. A module containing the example from (3) above > >> would have a __docs__ dictionary containing mappings for docstrings for each > >> top-level class and function defined, in addition to docstrings for each > >> global variable. > > > >This would not work well together with class inheritance. > > Could you provide an example explaining this? Using a dict *seems* like > a good idea to me, too. class A: " Base class for database " x = "???" " name of the database; override in subclasses ! " y = 1 " run in auto-commit ? " class D(A): x = "mydb" """ name of the attached database; note that this must support transactions """ This will give you: A.__doc__x__ == " name of the database; override in subclasses ! " A.__doc__y__ == " run in auto-commit ? " D.__doc__x__ == """ name of the attached database; note that this must support transactions """ D.__doc__y__ == " run in auto-commit ? " There's no way you are going to achieve this using dictionaries. Note: You can always build dictionaries of docstring by using the existing Python introspection features. This PEP is meant to provide the data -- not the extraction tools. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

need help with build on HP-UX
by Jeremy Hylton 28 Aug '00

28 Aug '00

We have a bug report for Python 1.5.2 that says building with threads enabled causes a core dump with the interpreter is started. #110650: http://sourceforge.net/bugs/?func=detailbug&bug_id=110650&group_id=5470 I don't have access to an HP-UX box on which to text this problem. If anyone does, could they verify whether the problem exists with the current code? Jeremy

2 1

New dictionaries patch on SF
by Fred L. Drake, Jr. 28 Aug '00

28 Aug '00

I've been playing with dictionaries lately trying to stamp out a bug: http://sourceforge.net/bugs/?func=detailbug&bug_id=112558&group_id=5470 It looks like any fix that really works risks a fair bit of performance, and that's not good. My best-effort fix so far is on SourceForge: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 but doesn't quite work, according to Guido (I've not yet received instructions from him about how to reproduce the observed failure). None the less, performance is an issue for dictionaries, so I came up with the idea to use a specialized version for string keys. When I saw how few of the dictionaries created by the regression test ever had anything else, I tried to simply make all dictionaries the specialized variety (they can degrade themselves as needed). What I found was that just over 2% of the dictionaries created by running the regression test ever held any non-string keys; this may be very different for "real" programs, but I'm curious about how different. I've also done *no* performance testing on my patch for this yet, and don't expect it to be a big boost without something like the bug fix I mentioned above, but I could be wrong. If anyone would like to play with the idea, I've posted my current patch at: http://sourceforge.net/patch/?func=detailpatch&patch_id=101309&group_id=5470 Enjoy! ;) -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

3 3

Python keywords
by Thomas Wouters 28 Aug '00

28 Aug '00

Mark, (and the rest of python-dev) There was a thread here a few weeks ago (or so, I seem to have misplaced that particular thread :P) about using Python keywords as identifiers in some cases. You needed that ability for .NET-Python, where the specs say any identifier should be possible as methods and attributes, and there were some comments on the list on how to do that (by Guido, for one.) Well, the attached patch sort-of does that. I tried making it a bit nicer, but that involved editing all places that currently use the NAME-type node, and most of those don't advertise that they're doing that :-S The attached patch is in no way nice, but it does work: >>> class X: ... def print(self, x): ... print "printing", x ... >>> x = X() >>> x.print(1) printing 1 >>> x.print <method X.print of X instance at 0x8207fc4> >>> x.assert = 1 >>> However, it also allows this at the top level, currently: >>> def print(x): ... print "printing", x ... which results in some unexpected behaviour: >>> print(1) 1 >>> globals()['print'](1) printing 1 But when combining it with modules, it does work as expected, of course: # printer.py: def print(x, y): print "printing", x, "and", y # >>> import printer >>> printer.print <function print at 0x824120c> >>> printer.print(1, 2) printing 1 and 2 Another plus-side of this particular method is that it's simple and straightforward, if a bit maintenance-intensive :-) But the big question is: is this enough for what you need ? Or do you need the ability to use keywords in *all* identifiers, including variable names and such ? Because that is quite a bit harder ;-P -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

4 4

c.l.p.a -- what needs to be done ?
by M.-A. Lemburg 28 Aug '00

28 Aug '00

I've asked this question before: when are we going to see comp.lang.python.announce back online ? I know that everyone is busy with getting the betas ready, but looking at www.python.org I find that the "latest" special announcement is dated 22-Mar-2000. People will get the false idea that Python isn't moving anywhere... at least not in the spirit of OSS' "release early and often". Could someone please summarize what needs to be done to post a message to comp.lang.python.announce without taking the path via the official (currently defunct) moderator ? I've had a look at the c.l.p.a postings and the only special header they include is the "Approved: fleck(a)informatik.uni-bonn.de" header. If this is all it takes to post to a moderated newsgroup, fixing Mailman to do the trick should be really simple. I'm willing to help here to get this done *before* the Python 2.0beta1 announcement. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

6 15

Is Python moving too fast? (was Re: Is python commercializationazing? ...)
by Skip Montanaro 27 Aug '00

27 Aug '00

Alex> When I told people that the 1.5.2 release I was using, the latest Alex> one, had been 100% stable for over a year, I saw lights of wistful Alex> desire lighting in their eyes (at least as soon as they understood Alex> that here, for once, 'stable' did NOT mean 'dead':-).... Oh well, Alex> it was nice while it lasted; now, the perception of Python will Alex> switch back from "magically stable and sound beyond ordinary Alex> mortals' parameters" to "quite ready to change core language for Alex> the sake of a marginal and debatable minor gain", i.e., "just Alex> another neat thing off the net". I began using Python in early 1994, probably around version 1.0.1. In the intervening 6+ years, Python has had what I consider to be five significant releases: 1.1 (10/11/94), 1.2 (4/10/95), 1.3 (10/8/95), 1.4 (10/25/96) and 1.5 (12/31/97). (1.5.1 was released 4/13/98 and 1.5.2 was released 4/13/99). So, while it's been a bit over a year since 1.5.2 was released, Python really hasn't changed much in over 2.5 years. Guido and his core team have been very good at maintaining backward compatibility while improving language features and performance and keeping the language accessible to new users. We are now in the midst of several significant changes to the Python development environment. From my perspective as a friendly outsider, here's what I see: 1. For the first time in it's 10+ year history, the language actually has a team of programmers led by Guido whose full-time job is to work on the language. To the best of my knowledge, Guido's work at CNRI and CWI focused on other stuff, to which Python was applied as one of the tools. The same observation can be made about the rest of the core PythonLabs team: Tim, Barry, Fred & Jeremy. All had other duties at their previous positions. Python was an important tool in what they did, but it wasn't what they got measured by in yearly performance reviews. 2. For the first time in its history, a secondary development team has surfaced in a highly visible and productive way, thanks to the migration to the SourceForge CVS repository. Many of those people have been adding new ideas and code to the language all along, but the channel between their ideas and the core distribution was a very narrow one. In the past, only the people at CNRI (and before that, CWI) could make direct changes to the source code repository. In fact, I believe Guido used to be the sole filter of every new contribution to the tree. Everything had to pass his eyeballs at some point. That was a natural rate limiter on the pace of change, but I believe it probably also filtered out some very good ideas. While the SourceForge tools aren't perfect, their patch manager and bug tracking system, coupled with the externally accessible CVS repository, make it much easier for people to submit changes and for developers to manage those changes. At the moment, browsing the patch manager with all options set to "any" shows 22 patches, submitted by 11 different people, which have been assigned to 9 different people (there is a lot of overlap betwee the gang of 9 and the gang of 11). That amount of parallelism in the development just wasn't possible before. 3. Python is now housed in a company formed to foster open source software development. I won't pretend I understand all the implications of that move beyond the obvious reasons stated in item one, but there is bound to be some desire by BeOpen to put their stamp on the language. I believe that there are key changes to the language that would not have made it into 2.0 had the license wrangling between CNRI and BeOpen not dragged out as long as it did. Those of us involved as active developers took advantage of that lull. (I say "we", because I was a part of that. I pushed Greg Ewing's original list comprehensions prototype along when the opportunity arose.) 4. Python's user and programmer base has grown dramatically in the past several years. While it's not possible to actually measure the size of the user community, you can get an idea of its growth by looking at the increase in list traffic. Taking a peek at the posting numbers at http://www.egroups.com/group/python-list is instructive. In January of 1994 there were 76 posts to the list. In January of 2000 that number grew to 2678. (That's with much less relative participation today by the core developers than in 1994.) In January of 1994 I believe the python-list(a)cwi.nl (with a possible Usenet gateway) was the only available discussion forum about Python. Egroups lists 45 Python-related lists today (I took their word for it - they may stretch things a bit). There are at least three (maybe four) distinct dialects of the language as well, not to mention the significant growth in supportef platforms in the past six years. All this adds up to a system that is due for some significant change. Those of us currently involved are still getting used to the new system, so perhaps things are moving a bit faster than if we were completely familiar with this environment. Many of the things that are new in 2.0 have been proposed on the list off and on for a long time. Unicode support, list comprehensions, augmented assignment and extensions to the print statement come to mind. They are not new ideas tossed in with a beer chaser (like "<blink>"). From the traffic on python-dev about Unicode support, I believe it was the most challenging thing to add to the language. By comparison, the other three items I mentioned above were relatively simple concepts to grasp and implement. All these ideas were proposed to the community in the past, but have only recently gained their own voice (so to speak) with the restructuring of the development environment and growth in the base of active developers. This broadening of the channel between the development community and the CVS repository will obviously take some getting used to. Once 2.0 is out, I don't expect this (relatively) furious pace to continue. -- Skip Montanaro (skip(a)mojam.com) http://www.mojam.com/ http://www.musi-cal.com/ [Completely unrelated aside: I've never voiced an opinion - pro or con - about the new print syntax, either on python-list or python-dev. This will be my only observation. I have used the following print statement format for several years when I wanted to insert some temporary debugging statements that I knew I would later remove or comment out: print ">>", this, that, and, the, other, stuff because it would make it easier to locate them with a text editor. (Right shift, while a very useful construct, is hardly common in my programming.) Now, I'm happy to say, I will no longer have to quote the ">>" and it will be easier to get the output to go to sys.stderr...]

2 1