Mailman 3 April 2003 - Python-Dev

Evil setattr hack
by Guido van Rossum 19 Apr '03

19 Apr '03

Someone accidentally discovered a way to set attributes of built-in types, even though the implementation tries to prevent this. For example, you cannot modify the str type to add a new method. Let's define the method first: >>> def reverse(self): ... return self[::-1] ... >>> Using direct attribute assignment doesn't work: >>> str.reverse = reverse Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: can't set attributes of built-in/extension type 'str' >>> Using the dictionary doesn't work either: >>> str.__dict__['reverse'] = reverse Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: object does not support item assignment >>> But here's a trick that *does* work: >>> object.__setattr__(str, 'reverse', reverse) >>> Proof that it worked: >>> "hello".reverse() 'olleh' >>> What to do about this? I *really* don't want changes to built-in types to become a standard "hack", because there are all sorts of things that could go wrong. (For one, built-in type objects are static C variables, which are shared between multiple interpreter contexts in the same process.) --Guido van Rossum (home page: http://www.python.org/~guido/)

5 9

Final PEP 311 run
by Mark Hammond 19 Apr '03

19 Apr '03

Hi all, I'd like to get PEP311 in for the Python 2.3b1 - http://www.python.org/peps/pep-0311.html (or even if I miss, very soon after!) There appears to be no issues with the technical aspects of the PEP (please correct me now if I am wrong). The only issue is the name of the API. To save re-reading the PEP just to understand the names, I will summarize here (see the PEP for the full version): There are 2 new functions, called as a pair. The first function sets up the Python thread state, along with the GIL, so that the current thread can safely call the Python API. The function makes no assumptions about the current state of the GIL etc - it works out the current state, and does the "right thing". The second function is the reverse of the first, to indicate that the thread has finished with the thread state for the time being. The PEP calls these functions PyAutoThreadState_Ensure() and PyAutoThreadState_Release() Reasons for the names in the PEP: "Auto" reflects that the current thread-state need not be known (whereas the other APIs do). "Ensure()" reflects that nothing may actually be *created* - all we are doing is "ensuring" we have the resources, creating only if necessary. On the down-side - "Auto" will look strange in the future when this is the standard way of managing the lock. "ThreadState" does not reflect that the function does more than manage the PyThreadState - it also manages the locks (which while an implementation detail, are currently discrete) Other Proposals: Just: PyGIL_Ensure(), PyGIL_Release(): shorter to type, conveys the meaning. David Abrahams: Prefers SubjectVerbObject, so would prefer "PyEnsureGIL" - but likes PyAcquireInterpreter() and PyReleaseInterpreter() best. Dropping "Auto" from the PEP gives PyThreadState_Ensure() and PyThreadState_Release(). I admit to liking "PyAcquireInterpreter()" best, but it does not match the existing API structure. For the sake of typing, I would be happy to go with Just's PyGIL_Ensure(), but maybe PyInterpreter_Ensure() is a good compromise. Other opinions or pronouncements welcome :) Mark.

4 5

pytho-dev Summary for 2003-04-01 through 2003-04-15
by Brett Cannon 18 Apr '03

18 Apr '03

Sorry this is later than normal but I got sucked into helping with elections at UC Berkeley by providing IT support (first time elections are all on computer). Anyway, you guys have until Monday night to reply with corrections for the summary. +++++++++++++++++++++++++++++++++++++++++++++++++++++ python-dev Summary for 2003-04-01 through 2003-04-15 +++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from April 1, 2003 through April 15, 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 fifteenth summary written by Brett Cannon (<voice of Comic Book Guy from "The Simpsons">Most summaries written by a single person *ever* </voice>). 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 .. _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-03-16_2003-03-31.html ====================== Summary Announcements ====================== So all three people who expressed an opinion about the new Quickies_ format liked the new one, so it stays. Do you guys actually like the links to the CVS in the Summaries? The various links I put in to every single file mentioned that does not have direct documentation is time-consuming. But if you find it useful it can stay. Please let me know whether you actually use it (this means if you don't tell me!). ========= `Boom`__ ========= __ http://mail.python.org/pipermail/python-dev/2003-April/034370.html Splinter threads: - `RE: [Python-checkins] python/dist/src/Modules gcmodule.c <http://mail.python.org/pipermail/python-dev/2003-April/034371.html>`__ Related threads: - `Garbage collecting closures <http://mail.python.org/pipermail/python-dev/2003-April/034521.html>`__ - `Algorithm for finalizing cycles <http://mail.python.org/pipermail/python-dev/2003-April/034609.html>`__ Do you want to know what dedication is? Thinking of Python code that will cause Python to crash during dental surgery. Well, Tim Peters is that dedicated and managed to come up with some code that crashed Python when it attempted to garbage-collect some objects. This begins the joy that is garbage collection and finalizer functions. Gather around, children, as we learn about how Python tries to keep you from having to worry about keeping track of your trash. When Python executes the garbage collector, it looks to see what objects are unreachable based on reference counts; when something has a reference count of 0 nothing is referencing it so it is just floating out in the middle of no where with no one giving a hoot about whether it is their or not (children: "Awww! Poor, lonely object!"). But some of these lonely objects have what we call a finalizer (children: "What's that?!?"; isn't it cute when children are still inquisitive? Good for you for still being inquisitive! Have to be supportive, you know). A finalizer is either an instance that has a __del__ object or an object that has something in its tp_del slot (children: <nod>). Does anyone know why we have to take of these lonely objects that are somewhat special? (children: <look around for someone to be brave enough to actually try to answer; no one does>) Well, since these objects have something that must be called before they are garbage-collected, we have to make sure they don't reference an object that is out there but people think is cared about when it is only an object with a finalizer and we don't care about their opinions; it might want to keep an object's reference count above 0 and thus not be collected (children: "Oh..."). What makes them especially difficult to handle is that some objects that don't seem like finalizers lie end up acting like they do by defining a __getattr__ method that does very rude things (children: "That's not nice!"). And since it is really hard to tell whether they are real finalizers or just act like one, we just let them be out there forever so that they don't make the great Interpreter have to deal with them (some rabble-rouser: "My dad says that there is no great Interpreter and that everything came from the Compiler and Linker when they got together and did something my dad won't tell me about. Something about the bits and the bees..."; rest of children: "Nu-uh! The Interpeter is real! We've seen it! It's all-powerful and knowing! Take it back, take it back!"). Luckily, though, it is only an issue with something old-timers call classic classes; things that started to decay away long, long ago(children: "Yay! No more cruft!") And thanks to the diligent work of some very important people, it has been dealt with (children: "Yay! Thank you important people!"). There is a lesson to be learned here children; do not put old things to pasture to early since you can make stubborn old people mad which is bad since they make up the majority of voters in America (children: "Yes, teacher!"; smart-ass in the back of the room: "How old are you, teacher?" <snicker>). Guido said that Python's cleanup model could be summed up as "things get destroyed when> nothing refers to them at some arbitrary time after nothing refers to them." And the corollary is "always explicitly close your external resources." Tim Peters gave several suggestions in regards in how to make sure things get cleaned up; from registering cleanup code with sys.atexit() to keep a weakref in a module with a finalizer to be executed when the module is collected. ========= Quickies ========= `Distutils documentation amputated in 2.2 docs?`__ Splinter threads: - `How do I report a bug? <http://mail.python.org/pipermail/python-dev/2003-April/034328.html>`__ Greg Ewing that two sections from the Distutils docs disappeared between Python 1.6 and 2.2. Sections are still missing and will stay so until someone comes up with a patch to add in the missing sections. There was also a discussion on making it more obvious how to report a bug on SF_. __ http://mail.python.org/pipermail/python-dev/2003-April/034314.html .. _SF: .. _SourceForge: http://www.sf.net/ `PEP 269 once more.`__ Jonathan Riehl got his patch for implementing `PEP 269`_ ("Pgen Module for Python") but then uploaded a newer version that is better. __ http://mail.python.org/pipermail/python-dev/2003-April/034317.html .. _PEP 269: http://www.python.org/peps/pep-0269.html `Minor issue with PyErr_NormalizeException`__ It was discovered that PyErr_NormalizeException could dump core because it forgot to return on possible errors. It's been fixed and back-ported. __ http://mail.python.org/pipermail/python-dev/2003-April/034325.html `Capabilities (we already got one)`__ Splinter threads: - `Capabilities <http://mail.python.org/pipermail/python-dev/2003-April/034315.html>`__ - `Security challenge <http://mail.python.org/pipermail/python-dev/2003-April/034343.html>`__ The thread that refuses to die continued into this month. Nothing ground-breaking was said, though. Ben Laurie, though, did say he is working on a PEP_ so hopefully that will make this whole discussion clear. __ http://mail.python.org/pipermail/python-dev/2003-April/034323.html .. _PEP: http://www.python.org/peps/ `[PEP] += on return of function call result`__ Someone wanted to do ``log.setdefault(r, '') += "test %d\n" % t`` which does not work. But it was pointed out you can just do ``temp = log.setdefault(r, ''); temp += "test %d\n" % t``. __ http://mail.python.org/pipermail/python-dev/2003-April/034339.html `How to suppress instance __dict__?`__ This is only of interest to people who use `Boost.Python`_ (which I don't use so I am not going to summarize it; although if you use C++ you will want to look at Boost.Python). __ http://mail.python.org/pipermail/python-dev/2003-April/034319.html .. _Boost.Python: http://www.boost.org/libs/python/doc/ `Super and properties`__ Someone got bit by properties not working nicely with super(). Nathan Srebro subsequently posted a `link <http://www.ai.mit.edu/~nati/Python/>`__ to a his own version of super() which handles this problem. __ `fwd: Dan Sugalski on continuations and closures`__ Kevin Altis forwarded some posts by Dan Sugalski (the guy heading the Parrot_ project and who Guido will throw a pie at at OSCON 2004 =) about closures and continuations that he found at http://simon.incutio.com/archive/2003/04/03/#closuresAndContinuations . Very well-written and might clarify things for people if they care to know more about closures, continuations, and why Lisp folks claim they are so damn important. __ http://mail.python.org/pipermail/python-dev/2003-April/034368.html .. _Parrot: http://www.parrotcode.org/ `LONG_LONG`__ Python 2.3 renames the LONG_LONG definition from the C API to PY_LONG_LONG as it should have been renamed. Yes, this will break things, but it was incorrect to have not renamed it. If you need to keep compatibility with code before Python 2.3, just use the following code (contributed by Mark Hammond):: #if defined(PY_LONG_LONG) && !defined(LONG_LONG) #define LONG_LONG PY_LONG_LONG #endif __ http://mail.python.org/pipermail/python-dev/2003-April/034396.html `socket question`__ Someone asking why something didn't build under Solaris and subsequently being redirected to python-list(a)python.org . __ http://mail.python.org/pipermail/python-dev/2003-April/034399.html `PEP305 csv package: from csv import csv?`__ Why does one have to do ``from csv import csv``? Wouldn't it be more reasonable to just do some magic in __init__.py for the csv_ package to do this properly? Well, Skip Montanaro forwarded the question to cvs development list at csv(a)mail.mojam.com and said he probably will make the change in the near future. __ http://mail.python.org/pipermail/python-dev/2003-April/034409.html .. _csv: http://www.python.org/dev/doc/devel/lib/module-csv.html `SF file uploads work now`__ Yes, hell must have frozen over since you can now upload a file when you start a new patch or bug report on SourceForge_. __ http://mail.python.org/pipermail/python-dev/2003-April/034416.html `Unicode`__ Splinter threads: - `OT: Signal/noise ratio <http://mail.python.org/pipermail/python-dev/2003-April/034462.html>`__ Once again another question on python-dev that is not appropriate for the list. But this one spawned questions of whether the mailing list should be renamed (answer: no, since it is fairly well-known what python-dev is for) or go back to having the list being closed and requiring moderator approval for posts from people off the list (answer: no, because the amount of work was just too much of a pain and the amount of off-topic emails has not equated to the filtering work done previously). __ http://mail.python.org/pipermail/python-dev/2003-April/034453.html `Placement of os.fdopen functionality`__ It was suggested to make the fdopen method of the os_ module a class method of 'file'. That was determined to be YAGNI and thus won't happen. __ http://mail.python.org/pipermail/python-dev/2003-April/034380.html .. _os: http://www.python.org/dev/doc/devel/lib/os-newstreams.html `Adding item in front of a list`__ Tim Peters wonders how many people would be made upset if list.insert() supported a negative index argument. __ http://mail.python.org/pipermail/python-dev/2003-April/034518.html `Why is spawn*p* not available on Windows?`__ Shane Halloway might add one of the os.spawn*p*() functions to Windows. __ http://mail.python.org/pipermail/python-dev/2003-April/034473.html `tzset`__ time.tzset() is no long on Windows because it is broken (and I will behave and not make a joke about how it would be just as broken as the OS or anything because I am unbiased). __ http://mail.python.org/pipermail/python-dev/2003-April/034480.html `backporting string changes to 2.2.3`__ Neal Norwitz updated docs and back-ported changes to the string_ module to bring it in sync with the actual string object. __ http://mail.python.org/pipermail/python-dev/2003-April/034489.html .. _string: http://www.python.org/dev/doc/devel/lib/module-string.html `List wisdom`__ http://www.python.org/cgi-bin/moinmoin/PythonDevWisdom is a wiki page created to contain the random nuggets of wisdom that come up on python-dev. __ http://mail.python.org/pipermail/python-dev/2003-April/034575.html `ValueErrors in range()`__ Fixed the error where range() returned ValueError when it should return TypeError. __ http://mail.python.org/pipermail/python-dev/2003-April/034617.html `_socket efficiencies ideas`__ Marcus Mendenhall wanted to get a patch applied that would allow you to create a socket that could skip a DNS lookup. He also wanted to add the ability to include a '<numeric>' prefix IP addresses to make sure that DNS lookup was skipped. Various ways of trying to cut back on time wasted on unneeded DNS lookups was discussed but no solution was found acceptable. __ http://mail.python.org/pipermail/python-dev/2003-April/034403.html `tp_clear return value`__ tp_clear could stand to return void, but can't change because of backwards-compatibility. Will most likely end up documenting to ignore what is returned by what is put into tp_clear. __ http://mail.python.org/pipermail/python-dev/2003-April/034433.html `More socket questions`__ Someone suggested fixing something that has been solved in Python 2.3. __ http://mail.python.org/pipermail/python-dev/2003-April/034472.html `Embedded python on Win2K, import failures`__ Someone had errors embedding Windows. No real conclusion came out of it. __ http://mail.python.org/pipermail/python-dev/2003-April/034506.html `More int/long integration issues`__ Splintered threads: - `range() as iterator <http://mail.python.org/pipermail/python-dev/2003-April/034530.html>`__ Before Python 3.0 (when xrange() will disappear), there is a good chance that the idiom ``for x in range(): ...`` will be caught by the compiler and compiled into a lazy generator (probably a generator). __ http://mail.python.org/pipermail/python-dev/2003-April/034516.html `Changes to gettext.py for Python 2.3`__ Barry Warsaw suggested some changes to gettext_ but none of them seemed to catch on. __ http://mail.python.org/pipermail/python-dev/2003-April/034511.html .. _gettext: `Evil setattr hack`__ Someone discovered how to set attributes on built-in types. Guido checked in code to prevent it. __ http://mail.python.org/pipermail/python-dev/2003-April/034535.html `Using temp files and the Internet in regression tests`__ I asked if it was okay to use in regression tests temporary files (answer: yes it is and if you only need one use test.test_support.TESTFN) or sockets (answer: yes as long as test.test_support.is_resource_enabled("network") is True). It led to me being unofficially assigned the task of coming up with documentation for test_support and regrtest for both the library documentation and Lib/test/README. I also got CVS commit privileges on Python itself! I became an official Python developer! Woohoo! __ http://mail.python.org/pipermail/python-dev/2003-April/034538.html `migration away from SourceForge?`__ It was suggested we revisit the idea of moving Python development off of SourceForge_ because of the usual crappy CVS performance and underwhelming tracker performance. There is also the issue that problems with the setup cannot be fixed on our schedule. GForge_ and Roundup_ were both suggested as alternatives. Roundup specifically has gotten a decent amount of support since it is in Python and thus we could get things fixed quickly. Trouble is that it is not polished enough yet and we would need to furnish our own CVS (but Ben Laurie might be gracious enough to help us out on that front with possible hosting at http://www.thebunker.net/ ). __ http://mail.python.org/pipermail/python-dev/2003-April/034540.html .. _GForge: http://gforge.org/ .. _Roundup: http://roundup.sf.net/ `How should time.strptime() handle UTC?`__ I asked if anyone thought time.strptime() should recognize UTC and GMT timezones by default for setting whether or not daylight savings was being used. No one has given their opinion yet (do you have one?). __ http://mail.python.org/pipermail/python-dev/2003-April/034543.html `Big trouble in CVS Python`__ CVS Python was crashing on the regression tests. It turned out to be from the reuse of a variable in the code that implements range(). Tim Peters said a "Word to the wise: don't ever try to reuse a variable whose address is passed to PyArg_ParseTuple for anything other than holding what PyArg_ParseTuple does or doesn't store into it". __ http://mail.python.org/pipermail/python-dev/2003-April/034544.html `GIL vs thread state`__ Discovered the docs for PyThreadState_Clear() are incorrect (or at least not very clear). __ http://mail.python.org/pipermail/python-dev/2003-April/034574.html `test_pwd failing`__ test_pwd was failing and now it isn't. __ http://mail.python.org/pipermail/python-dev/2003-April/034626.html `lists v. tuples`__ You can tell whether a comparison function does a 3-way or 2-way (using <); but that is not Pythonic and thus won't be done so as to allow someone to pass either a 2 or 3-way comparison function to list.sort() and have the method figure out what type of sort it is. __ http://mail.python.org/pipermail/python-dev/2003-April/034646.html `LynxOS 4 port`__ Duane Voth wants to get Python ported to the LynxOS on PPC. __ http://mail.python.org/pipermail/python-dev/2003-April/034647.html `sre.c and sre_match()`__ The C code for the re module is not simple. =) __ http://mail.python.org/pipermail/python-dev/2003-April/034653.html

1 0

Built-in functions as methods
by Phillip J. Eby 18 Apr '03

18 Apr '03

Hi guys. Greg, you were asking about making built-in functions act like methods. This could break code, if it applies to all built-in functions. In more than one Python version, I have stuck a built-in type or function into a class, under the assumption that it would behave as a 'staticmethod' now does. If all built-in functions start acting like unbound methods, existing code will break. I'm not positive, but I think there's even code like this in the standard library. I'm all for anything that makes Pyrex easier for Greg to maintain <wink>, but perhaps there is a flag that could be used to request the behavior so that existing code won't break?

2 1

Build errors under RH9
by Gary Herron 18 Apr '03

18 Apr '03

I just upgraded my development system to RedHat 9, and now I get two compilation errors on the Python CVS tree. I'll have time to examine them tonight, but I thought I'd get a notice out now on the chance that someone else has already resolved them. 1. Compilation of _tkinter comes up with #error "unsupported Tcl configuration" The failing test was changed just yesterday, but the previous version gives the same results: In revision 1.155: #if TCL_UTF_MAX != 3 && !(defined(Py_UNICODE_WIDE) && TCL_UTF_MAX==6) and in revision 1.154: #if TCL_UTF_MAX != 3 And yet, if I remove the test, I get a (very minimally tested) working version of Tkinter, so the test should probably be modified to pass in whatever circumstances RH 9 presents. 2. Compilation of _ssl.c fails to find, through a chain of includes, file krb5.h. Then things rapidly go to hell. Defining #define OPENSSL_NO_KRB5 gets through the compilation, but I don't yet know how to test it. (How to I get past the "Use of the `network' resource not enabled" result of running test_socket_ssl.py?) Gary Herron

4 3

0400058546-ID: We are glad to inform you about the changes in our website
by g_a_l_l_a＠mail333.com 18 Apr '03

18 Apr '03

Dear Sir or Madam, We are glad to inform you about the changes in our website http://www.gallery-a.ru. Now you can get to know the price for the paintings in our gallery without filling the order form. Also, we have new works of Utkin Alexandr, Belonog Anatoly and other painters. Soon there will be pages of new painters and new section of free wallpapers and screensavers. Welcome to our website! Gallery-a curator. Sorry if that information not interesting for You and we disturb You with our message! For removing yor address from this mailing list just replay this message with word 'unsubscribe' in subject field or simple click this link: http://www.gallery-a.ru/unsubscribe.php?e=cHl0aG9uLWRldkBweXRob24ub3JnOjE2O…

1 0

Wrappers and keywords
by David LeBlanc 17 Apr '03

17 Apr '03

(You'll excuse me I hope if this is deemed inappropriate. I'm posting this here rather than in the general list since it's about the language and not it's application.) I am curious to know why the, what seems to me kludgy, "def x(): pass x = (static|class)method(x)" syntax was chosen over a simple "staticdef x ():..." or "classdef x ():..." def specialization syntax? Either method adds keywords to the language, but a direct declaration seems clearer and less error prone to me compared to the "call->assignment magically makes a wrapper" method. Is it hard to do the needed special wrapping directly? Regards, David LeBlanc Seattle, WA USA

4 6

Stackless 3.0 alpha 1 at blinding speed
by Christian Tismer 16 Apr '03

16 Apr '03

Dear community, dear Stackless addicts, dear friends, Ich habe Euch wirklich was zu erzählen, liebe Freunde, I really have to tell you a story! During the last four months, I have been struggling with Stackless Python, and especially with myself and how to get re-focused on my major project which you know very well. Some of you might know quite well too how hard this was for me, especially in the context of my parent's endangeroured health. This particular problem seems to be solved, for the moment, so let's celebrate the moment, celebrate the moment! Without going into details, I would like to tell you about the current status of Stackless Python. For short, like an abstract, Stackless 3.0 is something like an or-merge of Stackless 1.0 and 2.0 technology. Guido, Tim, you both will probably remember my lengthy approaches to introduce those continuations, years ago, you both convinced me to drop them, and I did what I was supposed to do. I'm hopefully a proper citizen, right now. Anyway, you know I'll never really be... After a long period of depression, I re-invented Stackless in early 2002, with a version number of 2.0, denoting that I had dropped all the 1.0 paradigms (as there are: (1) try to keep compatible, (2) do minimal changes only, (3) absolutely avoid assembly code at all) At the same time, I dismissed all of my Stackless 1.0 code, which was continuation-based, an absolute no-no in Guido's eyes. I still do think that TimP wasn't that conformant to this "nono"-statement, after I read a lot of his comments, especially side-notes on the thread-sig, but this time Guido's veto was clearly stronger than Tim's arguing, a thing that doesn't happen so often, but I'm proactively respecting this, positively. Now, after all that rubbish, let's go into facts, which are quite interesting. ------------------------------------------------------------- Today, I finished Stackless Python 3.0, alpha 3.0.1! First of all, I would like to talk about the new principles. Yes, no, there are no longer continuations in that sense. I'm meanwhile convinced that we don't want to support them, any longer, although I'm happy that Stackless allowed me to learn *all* any much more about them that that is avalable on the wor(th|ld) w/h)i(d|l)e net!! Q&A: Q: What is it about that Stackless 3.0, will this guy never shut up??? A: No, he most probably never will, unless he's dead, and this is another 40 or more years in advance, for heaven's sake. Q: So, what is it about that Stackless 3.0 hype around since months? A: Simple! Stackless 3.0 has all the hardware switching stuff in it that Stackless 2.0 had. Stackless 3.0 also incorporates 80% of the soft switching protocol that Stackless 1.0 had. But there are a lot of new features: Stackless has again shown how to marry the impossible with the imbelievable, and this is the new concept of Stackless 3.0: There is a maerge between (1.0) soft context switching and (2.0) hard context switching, which always does the most reasonable thing. There are a lot of benefits which stem from this hybrid solution, which will appear in one of my most recent papers, pretty soon. -------------------------------------------------------------- BLURB Let me simply end this pamphlete with some simple sentences: Stackless Python is more capable of tasklets switching than any other light-weight threading software package. If anyone disagrees, please give me a runnable counter-example. Here are some impressive site-specific time measurements, which especially show, that 20.000.000 cframe tasklet switches per second are really, really hard to beat. Pythonon Win32: D:\slpdev\src\2.2\src\Stackless\test>..\..\pcbuild\python taskspeed.py 10000000 frame switches took 3.83061 seconds, rate = 2610551/s 10000000 frame softswitches took 2.40112 seconds, rate = 4164718/s 10000000 cfunction calls took 2.13033 seconds, rate = 4694098/s 10000000 cframe softswitches took 0.49296 seconds, rate = 20285627/s 10000000 cframe switches took 1.98907 seconds, rate = 5027486/s 10000000 cframe 100 words took 3.93737 seconds, rate = 2539768/s The penalty per stack word is about 0.980 percent of raw switching. Stack size of initial stub = 14 Stack size of frame tasklet = 58 Stack size of cframe tasklet = 35 D:\slpdev\src\2.2\src\Stackless\test> Python on Debian -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

1 0

Super and properties
by Gonçalo Rodrigues 16 Apr '03

16 Apr '03

Hi all, Since this is my first post here, let me first introduce myself. I'm Gonçalo Rodrigues. I work in mathematics, mathematical physics to be more precise. I am a self-taught hobbyist programmer and fell in love with Python a year and half ago. And of interesting personal details this is about all so let me get down to business. My problem has to do with super that does not seem to work well with properties. I posted to comp.lang.python a while ago and there I was advised to post here. So, suppose I override a property in a subclass, e.g. >>> class test(object): ... def __init__(self, n): ... self.__n = n ... def __get_n(self): ... return self.__n ... def __set_n(self, n): ... self.__n = n ... n = property(__get_n, __set_n) ... >>> a = test(8) >>> a.n 8 >>> class test2(test): ... def __init__(self, n): ... super(test2, self).__init__(n) ... def __get_n(self): ... return "Got ya!" ... n = property(__get_n) ... >>> b = test2(8) >>> b.n 'Got ya!' Now, since I'm overriding a property, it is only normal that I may want to call the property implementation in the super class. But the obvious way (to me at least) does not work: >>> print super(test2, b).n Traceback (most recent call last): File "<interactive input>", line 1, in ? AttributeError: 'super' object has no attribute 'n' I know I can get at the property via the class, e.g. do >>> test.n.__get__(b) 8 >>> Or, not hardcoding the test class, >>> b.__class__.__mro__[1].n.__get__(b) 8 But this is ugly at best. To add to the puzzle, the following works, albeit not in the way I expected >>> super(test2, b).__getattribute__('n') 'Got ya!' Since I do not know if this is a bug in super or a feature request for it, I thought I'd better post here and leave it to your consideration. With my best regards, G. Rodrigues

3 2

Re: [Python-Dev] shellwords
by Guido van Rossum 16 Apr '03

16 Apr '03

> > > [1] http://www.crazy-compilers.com/py-lib/shellwords.html > > > > Hm, couldn't this be easily done with shlex? > > >From the homepage: > > """ > Frequently Asked Questions > > Q: Hey, there is 'shlex' coming with Python. Why there is a need for > this module? A: I know 'shlex' and I gave it a try. But 'shlex' takes > quotes as word-delemiters which divers from the shell-semantic (see > above). And even if 'shlex' would parse strings as needed, I would have > written a (very, very) thin layer above, since 'shlex' is simple but > seldomly used for this kind of job. > """ I saw that after posting. :-( The argument "'shlex' is simple but seldomly used for this kind of job." seems circular though: "I'm not using shlex because it's rarely used" ??? > I agree with him. Even disconsidering the fact of the syntax > divergence, shellwords is about half the size of shlex, and it's > much more confortable, allowing one liners like "for opt in > shellwords(line):". I know I've wished for this once or twice, but not badly enough to bother solving the problem right. I'm worrying that having too many ways to do mostly the same thing adds clode bloat. Couldn't adding something even smaller on top of shlex provide the same interface and solve the syntactic divergence? --Guido van Rossum (home page: http://www.python.org/~guido/)

5 8