Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
Greg Ewing wrote: > Walter Dörwald wrote: >> Greg Ewing wrote: >> >>> Wouldn't it be better for the setter to raise an exception >>> if it's out of range? It probably indicates a bug in the >>> caller's code. >> >> The day before Monday is -1, so it adds a little convenience. > > In that case, why doesn't the global function > allow the same convenience? For backwards compatibility reasons. >> I think we've spent more time discussing the calendar module, than the >> Python community has spent using it! ;) > > It makes a nice change from adaptation and generic > functions. :-) ;) Bye, Walter Dörwald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
Tim Peters wrote: > Note that it's very easy to do this with __del__. The trick is for > your type not to have a __del__ method itself, but to point to a > simple "cleanup object" with a __del__ method. Give that "contained" > object references to the resources you want to close, and you're done. > Because your "real" objects don't have __del__ methods, cycles > involving them can't inhibit gc. The cleanup object's only purpose in > life is to close resources. Like: > > class _RealTypeResourceCleaner: > def __init__(self, *resources): > self.resources = resources > > def __del__(self): > if self.resources is not None: > for r in self.resources: > r.close() > self.resources = None > > # and typically no other methods are needed, or desirable, in > # this helper class > > class RealType: > def __init__(*args): > ... > # and then, e.g., > self.cleaner = _ResourceCleaner(resource1, resource2) > > ... tons of stuff, but no __del__ > > That's the simple, general way to mix cycles and __del__ without problems. So, stealing this trick for generators would involve a "helper" object with a close() method, a __del__ method that invoked it, and access to the generator's frame stack (rather than to the generator itself). class _GeneratorCleaner: __slots__ = ["_gen_frame"] def __init__(self, gen_frame): self._gen_frame = gen_frame def close(self): # Do whatever gen.close() currently does to the # raise GeneratorExit in the frame stack # and catch it again def __del__(self): self.close() The generator's close() method would then change to be: def close(self): self._cleaner.close() Would something like that eliminate the current cycle problem? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.5 (alpha 1)
On behalf of the Python development team and the Python community, I'm happy to announce the first alpha release of Python 2.5. This is an *alpha* release of Python 2.5, and is the *first* alpha release. As such, it is not suitable for a production environment. It is being released to solicit feedback and hopefully discover bugs, as well as allowing you to determine how changes in 2.5 might impact you. If you find things broken or incorrect, please log a bug on Sourceforge. In particular, note that changes to improve Python's support of 64 bit systems might require authors of C extensions to change their code. More information (as well as source distributions and Windows installers) are available from the 2.5 website: http://www.python.org/2.5/ The plan from here is for a number of additional alpha releases, followed by one or more beta releases and moving to a 2.5 final release around August. PEP 356 includes the schedule and will be updated as the schedule evolves. The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the language features added include conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce a coroutine kind of functionality, and a brand new AST-based compiler implementation. New major modules added include hashlib, ElementTree, sqlite3 and ctypes. In addition, a new profiling module cProfile was added. A large number of bugs, regressions and reference leaks have been fixed since Python 2.4. See the release notes for more. Enjoy this new (alpha!) release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpxtlomMJgfe.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 2.5 (alpha 1)
On 4/5/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > On behalf of the Python development team and the Python > community, I'm happy to announce the first alpha release > of Python 2.5. Excellent! Downloading it now for a test run... One (possibly very minor) point - the web page offers Windows 64-bit MSI installers for Itanium and AMD64, but these seem to point to the same file! I'm not a Win64 user, so I don't know if this is actually wrong, but it's confusing at least... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TRUNK is UNFROZEN
Python 2.5a1 is done. Please feel free to checkin to the trunk again. I should note here - the ubuntu dapper x86 buildbot is now running with a compiler of "icc -Wp64". This is Intel's C compiler, with warnings about potential 64 bit issues turned on. I tried with -Wall, but the icc compiler's -Wall mode is unbelievably picky and whiny, and the output was less than useful. www.python.org/dev/buildbot/all, and select one of the compile logs from the "ubuntu dapper x86 (icc)" column. Be aware that this is an old 500MHz box I had lying around that's found a new use as a buildslave, so it's not the fastest box in the world... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 2.5 (alpha 1)
On Wednesday 05 April 2006 23:16, Paul Moore wrote: > One (possibly very minor) point - the web page offers Windows > 64-bit MSI installers for Itanium and AMD64, but these seem to > point to the same file! I'm not a Win64 user, so I don't know if > this is actually wrong, but it's confusing at least... Damn. Missed that one. Fixed, will be visible again when the website auto-rebuilds (5-10 minutes). Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] suggest: nowait option in subprocess.communicate
I'd like to start several processes, each a pipe reading from my python main process. It looks like I want to write all my data to each process, then use communicate(), but I don't want to wait for each process yet, since then they would block each other. Why not add a nowait option to communicate? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TRUNK is UNFROZEN
On Wednesday 05 April 2006 23:20, Anthony Baxter wrote: > www.python.org/dev/buildbot/all, That should be www.python.org/dev/buildbot/all/ (needs the trailing /) Anthony ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Suggestion: Please login to wiki when you make changes
I know it's a minor point, but for those of us who monitor changes to the wiki I think it would make our task a bit easier if people within the Python developer community were logged in when they made changes. That way, instead of seeing a mail subject like [PythonInfo Wiki] Update of "BuildBot" by 24.6.150.200 I would see a person or login I recognize, like [PythonInfo Wiki] Update of "BuildBot" by SkipMontanaro Seeing a recognized name, I could just delete the mail without considering if it was wiki spam. It's a small point, but when you get hundreds of emails a day, speed is everything... Thx, Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] strftime/strptime locale funnies...
G'day,
Just noticed on Debian (testing), Ubuntu (warty?), and RedHat (old)
based systems Python's time.strptime() seems to ignore the environment's
Locale and just uses "C".
Last time I looked at this, time.strptime() leveraged off the platform's
strptime(), which meant it had all the extra features, bugs and
missingness of the platform's implementation.
We now seem to be using a Python implementation in _strptime.py. This
implementation does Locale's by feeding a magic date to time.strftime()
and figuring out how it formats it.
This revealed that time.strftime() is not honouring the Locale settings,
which is causing the new Python strptime() to also get it wrong.
$ set | grep "^LC\|LANG"
GDM_LANG=en_AU.UTF-8
LANG=en_AU.UTF-8
LANGUAGE=en_AU.UTF-8
LC_COLLATE=C
$ date -d "1999-02-22" +%x
22/02/99
$ python
...
>>> import time
>>> time.strftime("%x", time.strptime("1999-02-22","%Y-%m-%d"))
'02/22/99'
This is consistent across all three platforms for multiple Python
versions, including 2.1 and 1.5 (where they were available) which BTW
don't use the Python implementation of strptime().
This suggests that all three of these platforms have a broken libc
strftime() implementation... but all three? And why does date work?
Can others reproduce this? Have I done something stupid? Is this a bug,
and in what, libc or Python?
Slightly OT, is it wise to use a Python strptime() on platforms that
have a perfectly good one in libc? The Python reverse-engineering of
libc's strftime() output to figure out locale formatting is clever,
but...
I see there have already been bugs submitted about strftime/strptime
non-symmetry for things like support of extensions. There has also been
a bug against strptime() Locale switching not working because of caching
Locale formatting info from the strftime() analysis, but I can't seem to
get non-C Locale's working at all...
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PY_SSIZE_T_MIN?
Congratulations to the Python 2.5a1 release! I started adjusting Boost.Python to work with this new release and it is going very well. I noticed this #define in pyport.h: #define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)>>1)) However, I couldn't find a corresponding PY_SSIZE_T_MIN which would come in handy to adjust old code using INT_MIN (from limits.h). Are there arguments against defining PY_SSIZE_T_MIN? Or is this just an oversight? Objects/longobject.c uses: return -PY_SSIZE_T_MAX-1; To maximize consistency this would seem ideal to me: pyport.h: #define PY_SSIZE_T_MIN (-PY_SSIZE_T_MAX-1) longobject.c: return PY_SSIZE_T_MIN; Cheers, Ralf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5a1 Performance
Realizing that early releases don't normally perform as well as final releases, I ran pystone for 2.5a1 and compared with 2.4.2 (what I had handy). 2.5a1 got slightly more than 30k, while 2.4.2 gets slightly more than 35k (1.4 GHz, Pentium M, 1 Meg L2 cache). I also ran a large test suite for a project with both 2.5a1 and 2.4.2 and got nearly identical times. I haven't seen general performance mentioned here lately, so I thought I'd share those numbers. On a related note: it might be nice to put a pystone run in the buildbot so it'd be easier to compare pystones across different releases, different architectures, and between particular changes to the code. (That's assuming that the machines are otherwise idle, though.) -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
On 4/5/06, Benji York <[EMAIL PROTECTED]> wrote: > Realizing that early releases don't normally perform as well as final > releases, I ran pystone for 2.5a1 and compared with 2.4.2 (what I had > handy). 2.5a1 got slightly more than 30k, while 2.4.2 gets slightly > more than 35k (1.4 GHz, Pentium M, 1 Meg L2 cache). We should verify that all the compiler optimizations that existed in Python 2.4 still exist in Python 2.5. We didn't expend much effort in that area during the compiler development. Not sure if there are any that would affect pystone or not. Jeremy > > I also ran a large test suite for a project with both 2.5a1 and 2.4.2 > and got nearly identical times. > > I haven't seen general performance mentioned here lately, so I thought > I'd share those numbers. > > On a related note: it might be nice to put a pystone run in the buildbot > so it'd be easier to compare pystones across different releases, > different architectures, and between particular changes to the code. > (That's assuming that the machines are otherwise idle, though.) > -- > Benji York > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PY_SSIZE_T_MIN?
Ralf W. Grosse-Kunstleve wrote: > #define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)>>1)) > > However, I couldn't find a corresponding PY_SSIZE_T_MIN which would come in > handy to adjust old code using INT_MIN (from limits.h). Are there arguments > against defining PY_SSIZE_T_MIN? Or is this just an oversight? That's just an oversight; I just added it. Thanks for pointing that out, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
Benji York wrote: > Realizing that early releases don't normally perform as well as final > releases, I ran pystone for 2.5a1 and compared with 2.4.2 (what I had > handy). 2.5a1 got slightly more than 30k, while 2.4.2 gets slightly > more than 35k (1.4 GHz, Pentium M, 1 Meg L2 cache). What operating system and compiler? > On a related note: it might be nice to put a pystone run in the buildbot > so it'd be easier to compare pystones across different releases, > different architectures, and between particular changes to the code. > (That's assuming that the machines are otherwise idle, though.) That would do it across different architectures and particular changes to the code (although then something should keep a record of what pystone had been observed at what time). It won't do it across different releases, because we don't have Python binaries for each release available on each slave. Unfortunately, there can't be a guarantee that the slaves are idle. Several of them fulfill some primary function for whoever contributed the slave installation (I know *my* Solaris machine has to do other things, as well). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] suggest: nowait option in subprocess.communicate
Neal Becker <[EMAIL PROTECTED]> wrote: > > I'd like to start several processes, each a pipe reading from my python main > process. It looks like I want to write all my data to each process, then > use communicate(), but I don't want to wait for each process yet, since > then they would block each other. Why not add a nowait option to > communicate? Alternatively, someone could commit some rough equivalent of this to the subprocess module: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Yes, I wrote it, and previously suggested it within the previous thread "Add timeout to subprocess.py?". Guido had previously privately asked if it could be phased as a patch to subprocess.py in such a way to be 2.2 compatible. Aside from fcntl module semantics (I don't know if they changed, whether it should be using FCNTL instead, ...), and/or the 3 additional functions from pywin32 that probably should be included in the _subprocess module on Windows, the core functionality of a pollable subprocess is available in the above recipe. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
Martin v. Löwis wrote: > What operating system and compiler? Oops, should have included that: Ubuntu Breezy, Kernel 2.6.12-10-686 GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) > It won't do it across different > releases, because we don't have Python binaries for each release > available on each slave. I was thinking of "active" branches that there are buildbot slaves dedicated to (2.4 at the moment) and the trunk, but (as I mentioned) non-idleness pretty much kills that idea. I wonder if the slaves that are known to be dedicated to running buildbot and nothing else could be flagged as such. -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How to determine if char is signed or unsigned?
Is there are #define symbol which allows to determine if 'char' is signed or unsigned? __CHAR_UNSIGNED__, maybe? I guess the buildbot failures on the ppc debian box are caused by ctypes using signed chars always. Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
Benji York wrote: > I was thinking of "active" branches that there are buildbot slaves > dedicated to (2.4 at the moment) and the trunk, but (as I mentioned) > non-idleness pretty much kills that idea. I wonder if the slaves that > are known to be dedicated to running buildbot and nothing else could be > flagged as such. The problem is that even these could do different things simultaneously: I still haven't figured out how to mutually lock out builders that are on the same slave. This is a frequent thing to happen, as people often check-in trunk and backported branch patches nearly simultaneously (which is fine, of course - the machines just have to cater with that). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] strftime/strptime locale funnies...
On 4/5/06, Donovan Baarda <[EMAIL PROTECTED]> wrote:
> G'day,
>
> Just noticed on Debian (testing), Ubuntu (warty?), and RedHat (old)
> based systems Python's time.strptime() seems to ignore the environment's
> Locale and just uses "C".
>
> Last time I looked at this, time.strptime() leveraged off the platform's
> strptime(), which meant it had all the extra features, bugs and
> missingness of the platform's implementation.
>
> We now seem to be using a Python implementation in _strptime.py. This
> implementation does Locale's by feeding a magic date to time.strftime()
> and figuring out how it formats it.
>
The Python implementation of time.strptime() has been in Python since
summer 2002 so it was first introduced in 2.3 (I can't believe I have
been on python-dev that long!).
> This revealed that time.strftime() is not honouring the Locale settings,
> which is causing the new Python strptime() to also get it wrong.
>
This isn't time.strftime() . If you look at Modules/timemodule.c:450
you will find ``buflen = strftime(outbuf, i, fmt, &buf);`` for the
actual strftime() call. Before that the only things that could
possibly change the locale are localtime() or gettmarg(). Everything
else is error-checking of arguments.
> $ set | grep "^LC\|LANG"
> GDM_LANG=en_AU.UTF-8
> LANG=en_AU.UTF-8
> LANGUAGE=en_AU.UTF-8
> LC_COLLATE=C
>
> $ date -d "1999-02-22" +%x
> 22/02/99
>
> $ python
> ...
> >>> import time
> >>> time.strftime("%x", time.strptime("1999-02-22","%Y-%m-%d"))
> '02/22/99'
>
> This is consistent across all three platforms for multiple Python
> versions, including 2.1 and 1.5 (where they were available) which BTW
> don't use the Python implementation of strptime().
>
> This suggests that all three of these platforms have a broken libc
> strftime() implementation... but all three? And why does date work?
>
Beats me. This could be a locale thing. If I remember correctly
Python assumes the C locale on some things. I suspect the reason for
this is in the locale module or libc. But you can't even find the
word 'locale' or 'Locale' in timemodule.c nor do I know of any calls
that mess with the locale, so I doubt 'time' is at fault for this.
> Can others reproduce this? Have I done something stupid? Is this a bug,
> and in what, libc or Python?
>
> Slightly OT, is it wise to use a Python strptime() on platforms that
> have a perfectly good one in libc? The Python reverse-engineering of
> libc's strftime() output to figure out locale formatting is clever,
> but...
>
The reason it was made the default implementation is for consistency
across platforms. Since the trouble to implement a pure Python
version was done and it is not a performance critical operation,
consistency across platforms was deemed more important than allowing
various platforms to support whatever directives they chose and having
people writing code the relied upon it.
Plus it has been in there for so long there would be
backwards-compatibility issues if we switched this now.
> I see there have already been bugs submitted about strftime/strptime
> non-symmetry for things like support of extensions. There has also been
> a bug against strptime() Locale switching not working because of caching
> Locale formatting info from the strftime() analysis,
None open, right? Those should all be closed and fixed.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use dlopen() on Darwin/OS X to load extensions?
Hello folks, I just ran all the test iterations Martin suggested on Py2.5a1. That is, I did a normal build and ran 'make test', then installed and ran 'import test.regrtest; test.regrtest.main()', and then I did the whole thing over again with a framework build and install. All four test runs worked out fine. So at least on 10.4.5, this patch seems to be as tested as it's going to be. I've had some reports that it works fine on 10.3, and the patch doesn't change anything on 10.2. So given Bob's previous OK, this is probably ready to be applied -- unless anyone else has further concerns? Zach PS. I should mention as an aside that test_startfile.py is reported as 'failing unexpectedly on darwin', but since startfile is a windows thing, it really should be added to the expected tests in Lib/test/ regrtest.py. My patch didn't mess this up, though -- the startfile test is absent from the 'exclude' list in the SVN repository. On Apr 4, 2006, at 11:57 AM, Bob Ippolito wrote: >> No, it's fine. Thanks for reminding us about this issue. >> Unfortunately, without an explicit ok from one of the Mac >> maintainers, >> I don't want to add this myself. If you can get Bob, Ronald, or Jack >> to say ok, I will apply the patch ASAP. I have a Mac OS X.4 box and >> can test it, but don't know the suitability of the patch. > > The patch has my OK (I gave it a while ago on pythonmac-sig). > > -bob > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to determine if char is signed or unsigned?
Thomas Heller wrote: > Is there are #define symbol which allows to determine if > 'char' is signed or unsigned? __CHAR_UNSIGNED__, maybe? You could define an autoconf test for that. There is no predefined symbol. > I guess the buildbot failures on the ppc debian box are caused by > ctypes using signed chars always. So you think char is unsigned on ppc debian? I would find that very surprising. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
FYI, on my WinXP box, there appears to be about a 1% pystone difference: best seen for 2.4.3: 48118.9 best seen for trunk: 47629.8 While tiny, the difference "looked real", as many runs on 2.4.3 broke 48000 but none did on the trunk. Note that pystone uses wall-clock time on Windows (with sub-microsecond resolution), but CPU time on Linux (with resolution that varies by Linux flavor, but maybe no better than 0.01 second) -- that's all inherited from time.clock. As a result, I never see the same pystone result twice on Windows :-) When thinking about fiddling the buildbots, remember that we only do debug builds now, and pystone is much slower then. For example, on this box, the best trunk debug-build pystone result I got was 17484.3 (a factor of 2.7x smaller). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tally (and other accumulators)
Jess Austin wrote: > Alex wrote: >> On Apr 4, 2006, at 10:53 PM, Jess Austin wrote: >>> Alex wrote: import collections def tally(seq): d = collections.defaultdict(int) for item in seq: d[item] += 1 return dict(d) [Jess again] >>> def tally(seq): >>> return dict((group[0], len(tuple(group[1]))) >>> for group in itertools.groupby(sorted(seq))) >>> In general itertools.groupby() seems like a very clean way to do this >>> sort of thing, whether you want to end up with a dict or not. I'll go >>> so far as to suggest that the existence of groupby() obviates the >>> proposed tally(). Maybe I've just coded too much SQL and it has >>> warped my brain... > You're right in that it won't raise an exception on an iterator, but the > sorted() means that it's much less memory efficient than your version > for iterators. Another reason to avoid sorted() for this application, > besides the big-O. Anyway, I still like groupby() for this sort of > thing, with the aforementioned caveats. Functional code seems a little > clearer to me, although I realize that preference is not held > universally. However, sorted requires ordering. Try seq = [1, 1j, -1, -1j] * 5 Alex's tally works, but yours does not. -- -- Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
On 4/5/06, Benji York <[EMAIL PROTECTED]> wrote: > Martin v. Löwis wrote: > > What operating system and compiler? > > Oops, should have included that: > Ubuntu Breezy, Kernel 2.6.12-10-686 > GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) 32-bit or 64-bit? I would expect a modest diff on 64-bit between 2.4 and 2.5. You built both HEAD and 2.4 from scratch, right? To get more consistent results, you need to pass an option to gcc to tell it to use consistent branch prediction (or something like that). Otherwise, you will not get consistent results with the same source code. This option is not in the build system, you'll need to research it. I don't expect that to make more than a couple tenths of a percent diff though. I haven't done any profiling and I'm not likely to before 2.5 is released. It would be good if someone took a look at this though. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
Neal Norwitz wrote: > 32-bit or 64-bit? I would expect a modest diff on 64-bit between 2.4 and 2.5. 32-bit; don't know of any 64-bit Pentium Ms :) > You built both HEAD and 2.4 from scratch, right? Right. -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should issubclass() be more like isinstance()?
Crutcher Dunnavant wrote: > On 4/4/06, Greg Ewing <[EMAIL PROTECTED]> wrote: >> Crutcher Dunnavant wrote: >>> B) issubclass() won't work on a list of classs, >> > the way isinstance() does. >> >> That sounds more reasonable. I can't think of any >> reason why it shouldn't work. There is an issue of confusion: class CheeseShop(Sketch, ByCleese, ByGraham): pass You need to be careful that the user understands issubclass(SillyWalks, (Sketch, ByCleese, ByGraham)) is not simply testing that SillyWalks has the same ancestors as CheeseShop, but is True simply because issubclass(SillyWalks, Sketch) is True. More a document issue than anything, but to be considered. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
> I still haven't figured out how to mutually lock out builders that are
> on the same slave. This is a frequent thing to happen, as people often
> check-in trunk and backported branch patches nearly simultaneously
> (which is fine, of course - the machines just have to cater with that).
You can tell the Builder to claim a slave-wide "Lock" before starting the
build. Only one build can claim this Lock at a time, which will probably
accomplish what you want for performance testing (assuming the host isn't
doing anything other than buildbot work, of course).
I don't know what the python buildbot's master.cfg looks like, but you'll
probably want to add something like this (taken from the buildbot.texinfo
user's manual)
from buildbot import locks
cpulock = locks.SlaveLock("cpu")
b1 = {'name': 'buildername', 'slavename': 'bot-1', 'factory': f,
'locks': [cpulock]}
c['builders'].append(b1)
The name of the lock is meant for debugging, so you can tell why a given
builder is stalled. Each buildslave gets its own lock, and the builder claims
every lock listed in the 'locks' key before starting.
The one big problem with this approach is that the build looks like it's
stalled while it waits for the lock: you get a big yellow box between the
time it is supposed to start and the time it finally claims the lock.
Oh, and obviously you need to list the lock in all builders that are supposed
to compete for it.
cheers,
-Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
I compiled 2.4 and 2.5 from svn. The machine is Fedora Core 4, AMD64. I built both with ./configure && make (which gives a "64-bit" binary) and then ran pystone with 20 iterations 10 times: for i in `seq 1 10`; do ./python Lib/test/pystone.py 20 ; done The machine was "near idle" at the time. The best result for 2.4 (svn revision 43663) was 4.49 seconds (44343.4 pystones/second), which occurred on 4 of the runs. The best result for 2.5 (svn revision 43675) was 4.27 seconds (46620 pystones/second), which occurred on only one run. 4.29 seconds, the next best time, occurred on 3 runs. I'm not trivially able to try a 32-bit build, but for my system it appears that 2.5 is moderately faster than 2.4 when built with all the defaults. Jeff ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
Jeff Epler wrote: > I'm not trivially able to try a 32-bit build, but for my system it > appears that 2.5 is moderately faster than 2.4 when built with all the > defaults. OK, this prompted me to question my sanity. Being on a laptop the default is to do frequency scaling (different speeds depending on CPU load). When running pystone I've always seen an initial run that was much slower than subsequent runs, so I'd run several and throw out the first few. This gives a max of 35k pystones with 2.4.2 and 30k with 2.5a1. I decided to force the CPU freq. to the maximum (1.4 GHz) and remeasure. 2.5a1 reported the same pystones (30k) and, to my surprise, 2.4 reported 31k (about 5k *less* than with freq. scaling on). So there seems to be some interaction between frequency scaling and pystones. Benchmarking is hard, let's go shopping! -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Possible issue with 2.5a1 Win32 binary
Can someone check http://www.python.org/sf/1465093 for me? It looks like a fairly serious issue with the Windows binaries - pywin32 is a pretty important package on Windows. I've verified it on 2 machines, but can't work out what the issue might be. I've assigned it to Martin, as the owner of the MSI files, but if someone else is better placed to check it out, please do. I'm happy to run tests, or whatever to help locate the issue, but I don't have a Windows build environment to build Python myself. Thanks, Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
> Benchmarking is hard, let's go shopping! Quick reminder: pystone is mostly useful for predicting Python's relative performance across various machines and operating systems. For benchmarking Python itself, pystone is a seriously impaired tool. For one, it exercises only a tiny subset of the language. For another, it times an empty loop and subtracts that from the result of loops with bodies -- that means that improvements/impairments to the eval-loop get netted-out of the result. Let's stop talking about pystone in this thread and focus on meaningful metrics instead. If you want some good measurements of the eval-loop speed and a few simple instructions, use timeit.py. The results should be directly comparable between Py2.4 and Py2.5a. If you want good measurements that specifically exercise a wide gamut of commonly used functions, then use pybench.py. If you want to thoroughly exercise the language, use the parrot benchmark in the sandbox. Of course, the only truly useful benchmark is how Python performs on your own apps. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 2.5 (alpha 1)
Anthony Baxter wrote: > On behalf of the Python development team and the Python > community, I'm happy to announce the first alpha release > of Python 2.5. I noticed in PEP 356 Open Issues "StopIteration should propagate from context managers" that there's a still a question (from Jim Jewett) about whether the fix is correct. We'll need to get confirmation from PJE, but I'm pretty sure this can be removed from open issues - returning False from __exit__ will result in the original exception being re-raised. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 2.5 (alpha 1)
At 03:29 PM 4/5/2006, Delaney, Timothy (Tim) wrote: >Anthony Baxter wrote: > > > On behalf of the Python development team and the Python > > community, I'm happy to announce the first alpha release > > of Python 2.5. > >I noticed in PEP 356 Open Issues "StopIteration should propagate from >context managers" that there's a still a question (from Jim Jewett) >about whether the fix is correct. > >We'll need to get confirmation from PJE, but I'm pretty sure this can be >removed from open issues - returning False from __exit__ will result in >the original exception being re-raised. It is correct, and for the reason you describe. __exit__ *must* return True or False unless the generator raises a new, non-StopIteration exception. All other exceptions must be swallowed in __exit__. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible issue with 2.5a1 Win32 binary
Paul Moore wrote: > Can someone check http://www.python.org/sf/1465093 for me? It looks > like a fairly serious issue with the Windows binaries - pywin32 is a > pretty important package on Windows. My feeling is that this is a very shallow, easily fixed problem. > I've verified it on 2 machines, but can't work out what the issue > might be. I've assigned it to Martin, as the owner of the MSI files, > but if someone else is better placed to check it out, please do. I'm > happy to run tests, or whatever to help locate the issue, but I don't > have a Windows build environment to build Python myself. What happens when you run D:\Apps\Python25\python.exe -Wi D:\Apps\Python25\Lib\compileall.py -f -x badsyntax D:\Apps\Python25\Lib and look at the status of the program? I think also excluding bad_coding might already help. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tally (and other accumulators)
Jess Austin wrote: > I'll go > so far as to suggest that the existence of groupby() obviates the > proposed tally(). Except that it requires building a list of values in each group when all you want at the end is the length of the list. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
On Thursday 06 April 2006 04:10, Benji York wrote: > On a related note: it might be nice to put a pystone run in the > buildbot so it'd be easier to compare pystones across different > releases, different architectures, and between particular changes > to the code. (That's assuming that the machines are otherwise idle, > though.) -- -1. A bad benchmark (which pystone is) is much worse than no benchmark. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use dlopen() on Darwin/OS X to load extensions?
On Thursday 06 April 2006 05:28, Zachary Pincus wrote: > PS. I should mention as an aside that test_startfile.py is reported > as 'failing unexpectedly on darwin', but since startfile is a > windows thing, it really should be added to the expected tests in > Lib/test/ regrtest.py. My patch didn't mess this up, though -- the > startfile test is absent from the 'exclude' list in the SVN > repository. I fixed this shortly after Py2.5a1. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] elementtree in stdlib
A while ago there was some discussion about including elementtree in the std lib. I can't remember what the conclusion about that was, but if it does go ahead, I'd like to suggest that it be reorganised a bit. I've just started playing with it, and having a package called elementtree containing a module called ElementTree containing a class called ElementTree is just too confusing for words! -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
On Apr 5, 2006, at 8:30 PM, Greg Ewing wrote: > A while ago there was some discussion about including > elementtree in the std lib. I can't remember what the > conclusion about that was, but if it does go ahead, > I'd like to suggest that it be reorganised a bit. > > I've just started playing with it, and having a > package called elementtree containing a module > called ElementTree containing a class called > ElementTree is just too confusing for words! Try the 2.5 alpha 1 just released, and you'll see that the toplevel package is now xml.etree. The module and class are still called ElementTree, though. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
On Apr 5, 2006, at 9:02 PM, Alex Martelli wrote: > > On Apr 5, 2006, at 8:30 PM, Greg Ewing wrote: > >> A while ago there was some discussion about including >> elementtree in the std lib. I can't remember what the >> conclusion about that was, but if it does go ahead, >> I'd like to suggest that it be reorganised a bit. >> >> I've just started playing with it, and having a >> package called elementtree containing a module >> called ElementTree containing a class called >> ElementTree is just too confusing for words! > > Try the 2.5 alpha 1 just released, and you'll see that the toplevel > package is now xml.etree. The module and class are still called > ElementTree, though. It would be nice to have new code be PEP 8 compliant.. Specifically: Modules should have short, lowercase names, without underscores. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Bob Ippolito wrote: > > Try the 2.5 alpha 1 just released, and you'll see that the toplevel > > package is now xml.etree. The module and class are still called > > ElementTree, though. > > It would be nice to have new code be PEP 8 compliant.. it's not new code, and having *different* module names for the same well-established library isn't very nice to anyone. > Modules should have short, lowercase names, without underscores. the PEP changes over time. the ElementTree module was perfectly PEP-compatible when it was written. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot slave locks (Was: 2.5a1 Performance)
Brian Warner wrote: > I don't know what the python buildbot's master.cfg looks like, but you'll > probably want to add something like this (taken from the buildbot.texinfo > user's manual) Thanks, I have now done that, and it seems to work. It would be nice if the builder status would indicate that it is waiting for a lock. > The name of the lock is meant for debugging, so you can tell why a given > builder is stalled. Each buildslave gets its own lock, and the builder claims > every lock listed in the 'locks' key before starting. It wasn't first clear to me what "each buildslave gets its own lock"; I assumed it was my job to create a lock for each buildslave. I only then found out that a SlaveLock is always per slave (unlike a master lock, which is for the entire installation). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
