Mailman 3 November 2004 - Python-Dev

TRUNK FROZEN for 2.4rc1 from around 1200 UTC on Thurs 18
by Anthony Baxter Nov. 17, 2004

Nov. 17, 2004

Please hold off on any checkins after 1200 UTC on Thursday 18th (about 22 hours after this message was sent). We're cutting 2.4rc1 then. Assuming all goes well, we'll be looking at a 2.4 final for Nov 30. Could people please be _very_ conservative with checkins between now and 2.4 final? A brown-paper-bag 2.4.1 would suck :-( ta Anthony

1 0

__pycode__ extension
by Stelios Xanthakis Nov. 17, 2004

Nov. 17, 2004

Hi. I posted a message on c.l.p a couple of days ago about a python patch which adds a member __pycde__ to functions and classes. This member is a string which holds the python code of the function/class. (It works in interactively defined code and exec'd definitions) Supposing that: I ported this to 2.4b2 and made it have zero overhead when python runs in normal mode, is there any chance it would be considered a candidate for inclusion in mainline python? If yes, I'd appreciate it if … [View More]

7 9

Looking for authoritative documentation on packages, import & ihooks
by Carlos Ribeiro Nov. 17, 2004

Nov. 17, 2004

I have posted this question on c.l.py yesterday but received no answers. Given the complexity of the theme, I hope that people will not mind if I ask it here. I am looking for information on packages & import hooks, including simple examples on how to implement a simple import hook. Quick googling turns out some documents, such as: -- PEP 302: http://www.python.org/peps/pep-0302.html -- What's new on Python 2.3: http://www.python.org/doc/2.3.4/whatsnew/section-pep302.html -- … [View More]

7 9

Re: [Python-Dev] syntactic shortcut - unpack to variably sized list
by Nick Coghlan Nov. 17, 2004

Nov. 17, 2004

Aahz wrote: > Please fix your Thunderbird to stop adding spurious ^M characters: Sorry about that. It looks like either Google's SMTP server is doing something odd or Thunderbird's TLS implementation has issues - I switched back to my ISP's SMTP server and the problem went away. Cheers, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan(a)email.com | Mobile: +61 409 573 268

1 0

Re: __pycode__ extension
by Stelios Xanthakis Nov. 17, 2004

Nov. 17, 2004

Fernando Perez: > Well, not necessarily pushback, but I'd like a clarification at least. > What kind of memory overhead does this introduce? If every function > running around is holding a full copy of all its source, is this > overhead potentially significant? The overhead I'm worried about is the performance cost in the parser. The memory doesn't worry me because computer's memory gets more every year while python source remains compact. It's the debate of maintanability vs … [View More]

1 0

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser Nov. 17, 2004

Nov. 17, 2004

Patch / Bug Summary ___________________ Patches : 246 open ( +2) / 2699 closed ( +1) / 2945 total ( +3) Bugs : 770 open ( -1) / 4614 closed (+19) / 5384 total (+18) RFE : 156 open ( -1) / 135 closed ( +1) / 291 total ( +0) New / Reopened Patches ______________________ httplib: allowing stream-type body part in requests (2004-11-12) http://python.org/sf/1065257 opened by Alessandro Forghieri Fix pydoc crashing on unicode strings (2004-11-14) http://python.… [View More]

1 0

RE: [Python-Dev] os.access versus os.exist
by Robert Brewer Nov. 16, 2004

Nov. 16, 2004

Me: > > > It would be awfully nice (on posix platforms, for my > > > use-case) to find out whether a file is inaccessible > > > due to permission restrictions, or due to non-existence. Guido van Rossum: > > Why can't you solve this by doing a stat() when access() > > returns False? Me: > In my current case, stat() gives an error (even though the > file exists): > > OSError: [Errno 2] No such file or directory: > u'S:/Scans/Projects/… [View More]

2 1

PEP 310 Status
by Michael Walter Nov. 16, 2004

Nov. 16, 2004

Hello everyone, I was just wondering about the status of PEP 310 ("with" statement) - has there been any concensus/plan to implement it? (I tried to google the answer, but failed ;-) How about the potentiel inclusion of user-defined "blocks"? I suppose this would be only a Python 3000 thing, if ever included? Cheers, Michael

3 3

RE: [Python-Dev] Int literals and method calls
by Delaney, Timothy C (Timothy) Nov. 15, 2004

Nov. 15, 2004

"Martin v. Löwis" wrote: > If you meant to parse > > 1.__class__ > > as "<integer 1>" "." "<identifier __class__>", not as "<float 1.0>" > "<identifier __class_>" On a related note ... All this would just go away if in Python 3.0 (or even earlier ;) floats required something after the decimal point i.e. to get '<float 1.0>' you had to type '1.0' and '1.' by itself was a syntax error. I've never actually seen the use case for having '1.' … [View More]

3 2

Re: [Python-Dev] proposal+patch: sys.gettickeraccumulation()
by Ralf W. Grosse-Kunstleve Nov. 15, 2004

Nov. 15, 2004

Nick Coghlan wrote: > Ralf W. Grosse-Kunstleve wrote: > > A pure Python program will spent the bulk of the time interpreting > > bytecode. > > Perhaps, perhaps not. Right. But remember what the actual goal is: we want to answer the question "Is it worth reimplementing a piece currently written in Python in C/C++?" > A heck of a lot of the Python core isn't written > in Python - time spent executing builtins, or running methods of builtin > objects … [View More]usually doesn't involve the main interpreter loop (we're > generally in pure C-code at that point). If a piece of Python code leads to heavy use of complex, time-consuming builtin operations it will be of less benefit to reimplement that code in C/C++. This is exactly what we want to learn. > I'm curious how the suggested feature can provide any information that > is actually useful for optimisation purposes. Just because a low > proportion of time is spent in Python code, doesn't mean the Python code > isn't at fault for poor performance. > > As an example, in CPython 2.3 and earlier, this: > > result = "" > for x in strings: > result += x > > is a lot worse performance-wise than: > > result = "".join(strings) > > The first version does spend more time in Python code, but the > performance killer is actually in the string concatenation C code. So > the time is spent in the C code, but the fault lies in the Python code > (In Python 2.4, the latter version is still faster, but the difference > isn't as dramatic as it used to be). Exactly. If you try out my patch and look at time/ticks you will see immediately that there is no point in reimplementing "".join(strings) in C/C++. Importantly, you don't have to look at the code to arrive at this conclusion. The time/tick alone will tell you. This is very helpful if you are working with third-party code. > Knowing "I'm spending x% of the time executing Python code" just isn't > really all that interesting, Right. Sorry if I gave the wrong impression that this could be interesting. It is indeed not. What is interesting is the estimated benefit of reimplementing a piece of Python in C/C++. This is in fact highly correlated with the time/tick. > I'd rather encourage people to write appropriate benchmark scripts and > execute them using "python -m profile <benchmark> ", This approach is impractical/impossible in the real world. For example, this is the problem prompting me to implement sys.gettickeraccumulation(): http://pyquante.sourceforge.net/ - It is not our code, i.e. it is difficult for us to know where the time is spent. - It makes heavy use of Numeric. - It has a few innermost loops implemented in C. We are using only some parts of this library. Question: if we reimplement these parts completely in C++, what speedup can we expect? So we run a whole calculation and print the time/tick, which you can do with less than a one-minute investment: print time.time()/sys.gettickeraccumulation()*1.e6 as the last statement of your code. If the printed value is close 0.15 on our reference platform we know that the speedup will be in the neighborhood of 100. Any value higher than 0.15 indicates that the expected speedup will less. In our case the value was 0.35, and after we did the reimplementation in C++ we found a speedup of about 10. We have other applications with time/tick around 10. Just looking at this number tells us that there is not much to gain unless we completely eliminate Python. Bring in the cost for the C++ programmer and the increased cost of maintaining the C++ code compared to Python, and you know what we decided (not) to do. > rather than lead > them up the garden path with a global "Python/non-Python" percentage > estimation utility. Please consider that that utility is simply printing time.time()/sys.gettickeraccumulation(), that my patch is trivial, and that the runtime penalty is close to non-existing. Cheers, Ralf [View Less]

3 3