Mailman 3 June 2003 - Python-Dev

RE: [Python-Dev] Sneaky 'super' instances
by Phillip J. Eby 11 Jun '03

11 Jun '03

At 09:44 AM 6/11/03 +0100, Moore, Paul wrote: >But in practice, I can't see anything in either of these proposals which >really needs much change to what we currently have. I suspect that the >reality is that they are more or less descriptions of "useful patterns" >which can be used to offer a standard answer to issues which sometimes >come up with current methods, but which aren't frequent or severe enough >to justify major angst. (For example, the old one about what precisely >constitutes a "file-like" object in a given context). In this context, >it's not entirely clear to me why the proposals need "official sanction", >as opposed to simply being made available as user-level libraries, with >the possibility of migrating to "standard" status if the level of interest >proves to justify it. PEP 246 has a chicken-and-egg problem, because it's only useful if it's being used. adapt() by itself isn't at all useful if you don't have components or protocols that support it. And nobody wants to write components or protocols to support it, if nobody is using adapt(). If I understand Alex and Clark's intentions in writing the PEP, it was to get adapt() to have a ubiquitous presence, so that authors could assume their users would be able to use it. Two years after the original PEP, I saw a way to make use of it in a framework I was working on, and then noticed the chicken-and-egg problem. But, one thing that had changed since then was that Twisted and Zope both had significant "interface" packages. I saw a way to unite them, using PEP 246 as a mechanism, and how to make a toolkit that would allow developers to use adapt() in their own programs, without having to wait for anybody else to adopt adapt(). I'm hoping this will end the chicken-and-egg problem for PEP 246, as well as increase interoperability between frameworks. >As usual, I suspect the reality is somewhere between these two extremes. >But I'd like to see the two proposals restated in the form of working >library code. Then I could *try* them rather than arguing about theory. >[Of course if there really *is* a need for language support, this would >focus on the *exact* language change needed, along with a real use case >to justify it.] There is no need for language-level support; it's just a library. And, PyProtocols, my PEP 246 implementation and extension, is available for download now. As for the documentation framework sketched in the reference manual, that's not written. It will be, at some point, because I need it for my work. But, I'm wondering whether I should write it *such that it could go in the standard library*. See, I could probably write the documentation tool faster if I used PEAK, my application framework. But that would make it unlikely to ever be usable for the Python standard library, because that would be like distributing Zope in the standard library. In effect, my question is, "Should I expend the extra effort to develop the documentation tool in such a way that it could easily be distributed with the standard library?" And, since the tool would have to depend on PyProtocols, this means that (in effect) PyProtocols would have to be accepted for the standard library. So, what I want to know is: * Do other people find pydoc inadequate? * Does it seem likely that PyProtocols would be considered as an addition to the standard library (and by implication, used to document the interfaces of "standard" Python objects)? * Is there anything specific that anybody would want in an overhauled pydoc, that I should know about? Perhaps that clarifies my position and questions a bit better.

2 2

Updated 2.3 Release Schedule
by Raymond Hettinger 11 Jun '03

11 Jun '03

Once IDLEFORK is merged, is it time for a second Py2.3 beta release? Also, is July still reasonable for Py2.3 final? Raymond Hettinger

2 1

IDLEfork Re-integration into Python
by kbk＠shore.net 11 Jun '03

11 Jun '03

Guido has indicated that he would like IDLEfork to be integrated as .../src/Lib/idlelib/ instead of living under Tools/. To avoid losing history, a simple approach is to request the SF admins to add the IDLEfork RCS tree as .../src/Lib/idlelib/. I can make a small change to IDLEfork's CVS tarball to turn it into what's needed: remove the CVSROOT and website directories and repackage the tarball so the idle/ directory is renamed idlelib/ and is the top level. Once IDLE is in place in the new location, there are a number of things which need to be done. Here's my list; I'm sure there are other tasks that I'm not aware of, or better ways to do this, and I'd appreciate comments. 1. Change any references to idlefork to idle. 2. Simplify the scripts: idle, idle.py, idle.pyw 3. Eliminate setup.py, MANIFEST.in, LICENSE, and boolcheck.py (and associated references in the code) 4. Move the interruptmodule.c to /Modules. Eliminate the 2.2 compatibility code from the beginning of the file. Should the file be renamed? 5. Make the necessary changes to .../python/src/setup.py to build the interrupt extension. 6. Make needed changes to setup.py and the Windows installer to place the idle script in .../bin/ and idle.bat/idle.pyw in Scripts on Windows so that IDLE will continue to launch as it currently does. Maybe Tim could take a peek at this and tell me what ought to be done and by whom. 7. Rename files like NEWS.txt to NEWS to match Python standards. Should IDLE continue its own NEWS? (I'd vote yes.) 8. Tweak .../Tools/idle/setup.py to install at .../site-packages/old_idlelib (with the bin script named similarly) so if someone /did/ do an install there would not be a conflict. Maybe this should be done first? 9. Apply the forwardport patches from the IDLEfork Tracker -- KBK

5 10

towards a faster Python
by Neil Schemenauer 10 Jun '03

10 Jun '03

Hi guys, With Guido's blessing, I just commited a change that takes a small step towards where we want to be, IMO. Using __setattr__ on a module to create a global name that shadows a builtin name now raises a DeprecationWarning. E.g. import fileinput fileinput.open = 10 # <- warning will be raised The goal is that the compiler should be able to determine the scope of a name at compile time. Code like the above does not allow that and so non-local names must be searched for in both globals and builtins at run time. Unfortunately the warning is not bulletproof. It's possible to modify the module dict directly and bypass the warning. I'm not sure what to do about that. :-( Eventually we might want to allow optimizations based on known builtin functions. For example, code like for i in range(100000): ... could be rewritten to use an integer counter rather than creating a list and then iterating over it. I'm not sure how much resistance there would be in the community to disallowing reassignment of builtin names though. I don't think I've ever reassigned a builtin name so I think it would be worth it. The compiler could also warn about references to non-existent names. That's a common error and would be helpful to developers. Looking farther into the future, knowing that a name refers to a specific builtin function would give a type inference system a lot more information to work with. I guess it would help Psyco. Just some ideas to think about. Neil

17 37

RE: The Python interpreter is not fully thread-safe.
by Michael Chermside 10 Jun '03

10 Jun '03

[Michael Chermside] > Please note that what was confusing the the original poster was > almost certainly the docs saying that "Python" was not thread-safe > when what was really intended was, as Tim points out, that Python's > C api was not thread safe. Using the term "free threading" is fine, > but also make it clear that it's the _C api_ we're talking about, > because Python itself (ie, programs coded in pure Python) _IS_ > threadsafe. [Tim Peters] > Not really, under most meanings of "thread safe". For example, > > """ > id = 0 > def getid(): > global id > id += 1 > return id > """ > > wouldn't be considered a thread-safe way to get an id [...] > Thread safety is a complicated topic [...] > That's why I'd rather explain the situation than try to reduce it to > buzzword compliance -- the buzzwords here don't have objective, > app-independent, universally accepted meanings. Well, you have a very good point here... just slapping the lable "thread safe" onto it doesn't make the complexity go away. But I still have a concern... the PHB (pointy haired boss) issue. If the Python docs suggest that python is "not threadsafe", then the PHBs of the world are going to say "you must use Java", since it obviously IS threadsafe, whatever that means. Now, I *refuse* to lower the level of discourse to that which a PHB can comprehend. But it's worth a bit of care not to upset them. Replacing "not threadsafe" with something equivalent to Raymond's: > Any library that *is* "fully thread-safe" establishes certain > conventions that users have to follow to achieve thread-safety. The > same is true for Python: if the conventions (which are elaborated in > section 8.1) are followed, Python is also fully thread-safe. It's just > that it does not support what is commonly called "free threading". ...should do admirably. It explains things for those who want to know, but also has the key phrase "thread-safe" in it, which is all the PHB cares about. -- Michael Chermside and also

1 0

RE: PEP-317
by Michael Chermside 10 Jun '03

10 Jun '03

Guido writes: > There seem to be lots of different things in that PEP (I've got no > time to read it in full). Too bad... it's well written. > - deprecating string exceptions: definitely > > - making all exceptions derive from Exception: most probably Not actually part of this PEP... the author is going for the minimal PEP possible. But maybe it should be added. > - making Exception a new-style class: eventually Not really possible without this PEP. Basically, the PEP is all about the migration plan, without dealing much with the end point. It says "we all know string exceptions should go. Let's also say that eventually we'll use new-style classes, and maybe pack some extra functionality into the Exception class. Let's start the deprecation and warnings now." And it carefully considers all the kinds of code breakage and how to handle it. > But I'm not at all happy with the proposed deprecation of > > raise Class > > and > > raise Class, arguments > > in favor of > > raise Class() > > and > > raise Class(arguments) > > I don't see how this change is necessary in order to get any of the > other benefits. (1) There should be only one (preferably obvious) way to do it. (2) If I write "raise x" is that an example of "raise Class", or of "raise instance"? With old-style exceptions, you have to examine the type of x to figure out what to do. With new-style exceptions, even that wouldn't do. (3) The "raise Class" form has a spurious similarity with the except clause: try: raise MyError, raised except MyError, caught: pass Looks like "raised" is the same object as "caught". But it's not. (4) There's no benefit to having two syntaxes. See (1). > I also don't understand the commotion over deferred exception > instantiation, since it doesn't happen except for exceptions > raised from C code. Ignore it... it's a red herring. The whole deferred exception thing is just an implementation detail at the C level. -- Michael Chermside

1 0

RE: [Python-Dev] Re: PEP-317
by Moore, Paul 10 Jun '03

10 Jun '03

From: Steven Taschuk [mailto:staschuk@telusplanet.net] > 2. The run-time warnings are issued when raising an exception; > also not usually on a performance-critical path. (Except for > things like StopIteration. But the PEP does not propose any > change to the C API, so the built-in iterators won't be affected.) But the runtime check has to be done for all uses of the raise statement, so that the penalty is incurred not only by people who haven't changed their code but also by those who have. It's a pity that people who have done what is required still get penalised. That's in the nature of runtime warnings, but nevertheless shouldn't be ignored. Paul

2 1

RE: [Python-Dev] RE: PEP-317
by sismex01＠hebmex.com 10 Jun '03

10 Jun '03

> From: Aahz [mailto:aahz@pythoncraft.com] > Sent: Tuesday, June 10, 2003 9:23 AM > > Yeah. I've been thinking a bit, and while the proposed change makes > some sense for the case where you're passing an argument to an > exception, it makes this look uglier: > > class Found(Exception): > pass > > try: > for record in records: > for field in record.fields: > if data in field.data: > raise Found() > except Found: > # handle success > else: > # handle failure > > I find that extra set of parentheses unnecessary and ugly. > It implies a callable where it's not really being used that > way, particularly in the asymmetry between the ``raise`` and > the ``except``. > On the other hand, I read it quite clear; the extra set of parenthesis you find so ugly, imply to me that an instance of Found is being raised, and that except: is going to catch all instances of Found. It's a matter of taste, that you (aesthetically) like it or not, but it's a matter of consistency and correctness that it should be there or not. > > If this change goes through, I might start doing > > class Found(Exception): > pass > Found = Found() > You won't catch anything in that case, check this out: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> class Found(Exception): pass >>> Found = Found() >>> def fnEx(): try: print "Fire in the hole!" raise Found except Found: print "Fire extinguished." >>> >>> >>> fnEx() Fire in the hole! Traceback (most recent call last): File "<pyshell#21>", line 1, in ? fnEx() File "<pyshell#18>", line 4, in fnEx raise Found Found >>> >>> isinstance(Found,Found) Traceback (most recent call last): File "<pyshell#22>", line 1, in ? isinstance(Found,Found) TypeError: isinstance() arg 2 must be a class or type >>> You can't catch instances of the Found.__class__ by referring to Found, you'd have to do something like this: >>> >>> def fnEx(): try: print "Fire in the hole!" raise Found except Found.__class__: print "Caught." >>> >>> fnEx() Fire in the hole! Caught. >>> There it did get caught, but it seems quite uglier than an extra pair of parenthesis. just my 2 cents. -gca pd: Please excuse this unnecessary, hideous and wasteful legalese. :-( -- Advertencia:La informacion contenida en este mensaje es confidencial y restringida, por lo tanto esta destinada unicamente para el uso de la persona arriba indicada, se le notifica que esta prohibida la difusion de este mensaje. Si ha recibido este mensaje por error, o si hay problemas en la transmision, favor de comunicarse con el remitente. Gracias.

1 0

Re: [DB-SIG] API suggestion: expose 'quote' method
by Stuart Bishop 10 Jun '03

10 Jun '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, June 5, 2003, at 07:40 PM, M.-A. Lemburg wrote: > Magnus Lyckå wrote: >> At 17:18 2003-06-04 -0700, Chris Cogdon wrote: >>> So, perhaps what I really should be asking for is to include a >>> specification for an interface, such as what I've suggested before, >>> but make that a OPTIONAL part of the specification. Ie, if it's easy >>> enough to expose, then the driver writers should expose it in the >>> standard form. >>> >>> Does THAT sound reasonable ? >> Certainly. Many drivers implement things beyond the mandatory >> standard, and if it's possible to get the extras compatible >> across drivers, that's a big bonus in my opinion. > > No objection to adding a note to the spec about this. I still > think that you have to flesh out a reasonable API for this, > though, e.g. quoting should implemented on a per data type > basis rather than on a per SQL statement basis. Here is a starting point, stolen from Perl's DBI spec (which has had a fully functional quote method for almost a decade...) Translated into Python to avoid abuse ;) quote(value) Quote a value for use as a literal value in an SQL statement, by escaping any special characters (such as quotation marks) contained within the string and adding the required type of outer quotation marks :: >>> 'SELECT foo FROM bar WHERE baz = %s' % (con.quote("Don't")) "SELECT foo FROM bar WHERE baz = 'Don''t'" For most database types, quote would return ``'Dont''t'`` (including the outer quotation marks). A value of ``None`` will be returned as the string ``NULL`` to match how NULLs are represented in SQL. Quote will probably *not* be able to deal with all possible input (such as binary data or data containing newlines), and is not related in any way with escaping shell meta-characters. There is no need to quote values being passed as bound parameters to the ``execute`` or ``executemany`` methods. quoteidentifier(name) quoteidentifier(schema, table) quoteidentifier(catalog, schema, table) Quote an idenntifier (table name etc.) for use in an SQL statement, by escaping any special characters (such as double quotation marks) it contains and adding the required type of outer quotation marks. Undefined names are ignored and the remainder are quoted and then joined together, typically with a dot (``.``) character. For example:: con.quoteidentifier(None, 'Her schema', 'My table') would, for most database types, return ``"Her schema"."My table"`` (including all the double quotation marks). If three names are supplied then the first is assumed to be a catalog name. For example, for Oracle:: >>> con.quoteidentifier('link', 'schema', 'table') "schema"."table"@"link" - -- Stuart Bishop <zen(a)shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+5Zrgh8iUz1x5geARAmi2AJ9DFepNqmCakqhErOXkzCANynzXqwCgniQ9 KA6ggg4WGHl8gxuvcMzVNFA= =GMpq -----END PGP SIGNATURE-----

1 0

python-dev Summary for 2003-05-16 through 2003-05-31
by Brett C. 10 Jun '03

10 Jun '03

Here is the rough of the summary, as usual. I will not send it out any earlier than Tuesday. ------------------------- python-dev Summary for 2003-05-16 through 2003-05-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from May 16, 2003 through May 31, 2003. It is intended to inform the wider Python community of on-going developments on the list and to have an archived summary of each thread started on the list. To comment on anything mentioned here, just post to python-list(a)python.org or `comp.lang.python`_ with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the eighteenth summary written by Brett Cannon (has his own room with a door for the first time in over 22 years). All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; its simple and is accepted for `PEP markup`__. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the original text file. __ http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when wanting to look up any documentation on something mentioned here. To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . .. _python-dev: http://www.python.org/dev/ .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. contents:: .. _last summary: http://www.python.org/dev/summary/2003-05-01_2003-05-15.html ====================== Summary Announcements ====================== Sorry about the delay for this summary. I was visiting my mother and that puts me out of my hacking groove. I also had a roommate move out which means I got to move into his room. And on top of all of that I am having to decide which school to attend to get my CS masters. Life just likes to dump everything on you at once, huh? ==================================== `Vacation; Python 2.2.3 release.`__ ==================================== __ http://mail.python.org/pipermail/python-dev/2003-May/035642.html Related threads: - `Preparing docs for Python 2.2.3`__ - `Python 2.2.3`__ - `One other 2.2.3 failure`__ - `RELEASED Python 2.2.3c1`__ - `_sre changes`__ - `Python bug 544473 - bugfix candidate - was it applied?`__ - `Plans for Python 2.2.3 final`__ - Python 2.2.3 docs freeze`__ - RELEASED Python 2.2.3 (final)`__ __ http://mail.python.org/pipermail/python-dev/2003-May/035796.html __ http://mail.python.org/pipermail/python-dev/2003-May/035797.html __ http://mail.python.org/pipermail/python-dev/2003-May/035801.html __ http://mail.python.org/pipermail/python-dev/2003-May/035807.html __ http://mail.python.org/pipermail/python-dev/2003-May/035835.html __ http://mail.python.org/pipermail/python-dev/2003-May/035851.html __ http://mail.python.org/pipermail/python-dev/2003-May/035856.html __ http://mail.python.org/pipermail/python-dev/2003-May/035872.html __ http://mail.python.org/pipermail/python-dev/2003-May/035905.html `Python 2.2.3`_ has gone out the door! .. _Python 2.2.3: http://www.python.org./2.2.3/ =============================== `C new-style classes and GC`__ =============================== __ http://mail.python.org/pipermail/python-dev/2003-May/035661.html Jim Fulton updated the tutorial for creating new C types to use new-style classes. This led to the question of what the right way was for dealing with garbage collection. In terms of the tp_dealloc slot, having it call obj->ob_type->tp_free is best since that works the best when the type is subclassed. This also led to a discussion about the magic of PyType_Ready and whether it should do more. This wonderful function fills in tp_alloc and tp_free if tp_base and tp_bases are empty (they are set appropriately for PyBaseObject which is the C version of object). What was changed was that now the function does the right thing if the object should be checked for cycles based on settings in tp_flags. Paul Moore was worried about the loss of the tutorial for classic types. The response was that as long as they don't mess with there code it will continue to work, but if they decide to change something they should probably update. Michael Hudson's Misc/pymemcompat.h file is also helpful since it allows you to use 2.3's memory API but macro-replaces the call with the proper code all the way back to 1.5.2 . It was suggested adding a Misc/pyapipcompat.h for PyAPI_FUNC, PyAPI_DATA, and PyMODINIT_FUNC. ===================== `Attribute lookup`__ ===================== __ http://mail.python.org/pipermail/python-dev/2003-May/035730.html For the last summary I asked for the help of python-dev to find out the exact algorithm used to do attribute lookup for new-style classes (I don't care about classic classes since they are sooo 2.1 =). A bunch of people jumped in and made suggestions, but I am going to steal the explanation from Raymond Hettinger's explanation of descriptors which he is working on since I am reading it as I write this. =) The attribute lookup order gives "data descriptors priority over instance variables, instance variables priority over non-data descriptors, and assigns lowest priority to __getattr__ if provided." This is all is done by object.__getattribute__ . If you define your own __getattribute__ none of this is done unless you explicitly call object's implementation. You have to worry about calling a descriptor's __get__ method yourself if you decide not to call object.__getattribute__ . Raymond's descriptor essay/explanation/(group of words put together in attempt to make a coherent idea which he does) explains the difference between a data descriptor and non-data descriptor, but instead of make you wait I will just tell you. A data descriptor defines both a __get__ and __set__ method while a non-data descriptor defines only __get__. This makes sense when you think about non-data-descriptors such as functions. You have no need to assign to a function so not having a __set__ in no way harms the usage of a function plus it negates the need for any special flag or anything to define the difference between data and non-data descriptors. ================= `Introduction`__ ================= __ http://mail.python.org/pipermail/python-dev/2003-May/035792.html Splinter threads: - `Contracts PEP`__ __ http://mail.python.org/pipermail/python-dev/2003-May/035864.html What started off as Jeffrey Robert's introducing himself ended up becoming a short howto on how to get involved on python-dev. It was suggested to work on pyPy_ (although that is not exactly python-dev but is still cool and you could learn a lot about Python on a more abstract level =). Multiple people suggested working on bugs and patches. I specifically suggested looking at patches in development to learn what they were doing to the code's semantics. Mention of the AST branch and working on that was also brought up. Terrence Way then introduced himself and mentioned he had written a PEP about programming with contracts. It led to, in the end, Guido saying that he wanted to wait and let more implementations get out there and be weeded out before he started pronouncing on PEPs on the subject. .. _pyPy: http://codespeak.net/pypy/index.cgi?home ========= Quickies ========= `test_urllibnet failing on Windows`__ os.fdopen does not work with sockets under Windows when fetching its argument from fileno . .. __: http://mail.python.org/pipermail/python-dev/2003-May/035655.html `[development doc updates]`__ Here is a simple intelligence test: what do you think this email was about based on its subject? Get it right and you earned yourself a lollipop (on your own dime). .. __: http://mail.python.org/pipermail/python-dev/2003-May/035660.html `test_time fails with current CVS`__ No follow-up to this email so I don't know if MA Lemburg's issue with time.tzset was solved. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035669.html `a strange case`__ Splinter threads: `Unifying modules and classes?`__ Apparently the 2.2.x branch allows you to subclass a module. This has been fixed in 2.3 . And once again Guido stated that erasing the line separating classes and modules is not going to happen while his benevolently dictating body still has air in it (okay, he didn't say it that way, but I am sure he wouldn't object to a little artistic license to get his point across =). But if you really feel the need to have a module be a class just stick an instance in sys.modules; just don't expect everything to play well with it, though. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035676.html __ http://mail.python.org/pipermail/python-dev/2003-May/035731.html `test_bsddb185 failing under OS X`__ Tests were failing for me under OS X. After Skip Montanaro and I independently came up with a better way for the test to clean up after itself the tests passed from some odd reason. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035699.html `Need advice, maybe support`__ Christian Tismer was given two bits in tp_flags for Stackless_. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035701.html .. _Stackless: http://www.stackless.com./ `[Python-Dev] SF oddity`__ Remember folks, look out for horizontal scroll bars along with vertical ones. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035713.html Weekly Python Bug/Patch Summary * Ending on `2003-05-18`__ * Ending on `2003-05-25`__ __ http://mail.python.org/pipermail/python-dev/2003-May/035716.html __ http://mail.python.org/pipermail/python-dev/2003-May/035834.html `doctest extensions`__ Jim Fulton came up with some possible additions for doctest. You can see them at http://cvs.zope.org/Zope3/src/zope/testing/doctestunit.py?rev=HEAD&content-… . If you would like to see them added then speak up. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035718.html `+= on return of function call result`__ This is a continuation from `last summary`_. Samuele Pedroni wrote a simple function that simulates what was originally desired. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035500.html `Using emacs' unexec to speed Python startup`__ Splinter threads: - `portable undumper in xemacs`__ Some people tried to speed up loading Python for `some editor`__ when what they should have been doing is learning how to use a `better editor`__. =) .. __: http://mail.python.org/pipermail/python-dev/2003-May/035727.html __ http://mail.python.org/pipermail/python-dev/2003-May/035769.html .. _some editor: http://www.gnu.org/software/emacs/emacs.html .. _better editor: http://www.vim.org/ `[debian build error]`__ Some issue with using Debian packages and Python 2.2 with gcc 3.3 and libstdc++5. A Debian bug report has been filed. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035747.html `urllib2 proxy support broken?`__ Yes, but Gustavo Niemeyer would found the bug also came up with a patch. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035764.html `Python Run-Time System and Extensions`__ Daniel Silva is writing a compiler for Python to `PLT Scheme`_ code. He asked for suggestions on which of two ways to go for being able to run C extension code. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035773.html .. _PLT Scheme: http://www.plt-scheme.org/ `Descriptor API`__ We all learned what the difference is between a data and non_data descriptor (which you can know too by reading the summary for `Attribute lookup`_ ). .. __: http://mail.python.org/pipermail/python-dev/2003-May/035788.html `Of what use is commands.getstatus()`__ Guido ended up saying the commmands module should be redesigned, probably put into shutil, and then have the old version deprecated. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035799.html `Change to ossaudiodev setparameters() method`__ Some day Greg Ward will get his ossaudiodev module to work on both Guido's home machine and work machine. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035840.html `RE: Decimal class`__ A Decimal class is currently being worked on in the CVS sandbox. The question as to whether the values should be immutable was raised. Everyone agreed the change should happen. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035844.html `install debian package`__ python-dev is not the right place to bring up issues with Debian packages. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035849.html `Release question`__ Branches in CVS for Python are pretty much only used for minor versions (the "3" in "2.3.x"). Since 2.3 is in beta that means no semantic changes to the code. Any new features must wait for 2.4 development to start which occurs when 2.3 is out the door. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035873.html `Algoritmic Complexity Attack on Python`__ Someone tried to point out that Python was vulnerable to an attack if you naively took in certain things as keys to a dictionary. The big lesson is that Python's hash function can changes between releases and that it will always be as fast as possible. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035874.html `KeyboardInterrupt on Windows`__ An optimization on looping and using the JUMP_ABSOLUTE opcode was not catching exceptions since it was skipping that check in the interpreter loop. It has been fixed. .. __: http://mail.python.org/pipermail/python-dev/2003-May/035890.html `more-precise instructions for "Python.h first"?`__ David Abrahams didn't like the restriction of having to put Python.h before all other headers in C/C++ code. It is still being considered to make it so it is Python.h or pyconfig.h . .. __: http://mail.python.org/pipermail/python-dev/2003-May/035908.html

4 5