Mailman 3 April 2006 - Python-Dev

Re: [Python-Dev] [Python-checkins] r45721 - python/trunk/Lib/test/test_with.py
by Nick Coghlan 28 Apr '06

28 Apr '06

tim.peters wrote: > Author: tim.peters > Date: Wed Apr 26 03:15:53 2006 > New Revision: 45721 > > Modified: > python/trunk/Lib/test/test_with.py > Log: > Rev 45706 renamed stuff in contextlib.py, but didn't rename > uses of it in test_with.py. As a result, test_with has been skipped > (due to failing imports) on all buildbot boxes since. Alas, that's > not a test failure -- you have to pay attention to the > > 1 skip unexpected on PLATFORM: > test_with > > kinds of output at the ends of test runs to notice that this got > broken. That would be my fault - I've got about four unexpected skips I actually expect because I don't have the relevant external modules built. I must have missed this new one joining the list. > It's likely that more renaming in test_with.py would be desirable. Yep. I can see why you deferred fixing it, though :) I'm also curious as to why that test uses its own version of Nested rather than the one in contextlib. (granted, you can't inherit from the contextlib version, but containment should work fine) Anyway, I've created SF bug #1476845 to keep track of the things that need to be done to finish the PEP 343 terminology cleanup. (What we have now should be fine for alpha 2) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

2 1

what do you like about other trackers and what do you hate about SF?
by Brett Cannon 27 Apr '06

27 Apr '06

I am starting to hash out what the Call for Trackers is going to say on the Infrastructure mailing list. Laura Creighton suggested we have a list of features that we would like to see and what we all hate about SF so as to provide some guidelines in terms of how to set up the test trackers that people try to sell us on. So, if you could, please reply to this message with ONE thing you have found in a tracker other than SF that you have liked (especially compared to SF) and ONE thing you dislike/hate about SF's tracker. I will use the replies as a quick-and-dirty features list of stuff that we would like to see demonstrated in the test trackers. -Brett

5 5

"mick-windows" buildbot uptime
by Trent Mick 27 Apr '06

27 Apr '06

We've pretty much gotten settled into our new diggs at work here (ActiveState) so my Windows buildbot machine should have better uptime from now on. Cheers, Trent -- Trent Mick trentm(a)activestate.com

1 0

Re: [Python-Dev] New-style icons, .desktop file
by Andrew Clover 27 Apr '06

27 Apr '06

Morning! I've done some tweaks to the previously-posted-about icon set, taking note of some of the comments here and on -list. In particular, amongst more minor changes: - added egg icon (based on zip) - flipped pycon to work better with shortcut arrow - emphasised borders of 32x32 version of pycon, and changed text colour, in order to distinguish more from pyc. In balance I think this is enough of a change, though Nick Coghlan's idea of just using the plus in this case also has merit - indeed this is what happens at 16x16 - built .ico files without the Windows Vista enormo-icons. If the icons *were* to go in the win32 distribution, it probably wouldn't make sense to spend the considerably larger filesize on Vista icons until such time as people are actually using Vista. - included PNG and SVG version of icons. The SVG unfortunately doesn't preserve all the effects of the original Xara files, partly because a few effects (feathering, bevels) can't be done in SVG 1.1, and partly because the current conversion process is bobbins (but we're working on that!). So the nice gradients and things are gone, but it should still be of use as a base for anyone wanting to hack on the icons. - excised file() in favour of open() ;-) Files and preview here: http://doxdesk.com/img/software/py/icons2.zip http://doxdesk.com/img/software/py/icons2.png Oh, and is the intention to deprecate the purple/green horizontal snake logo previously used for 'Python for Windows' (as well as PSF)? If so, Erik van B's installer graphic could probably do with a quick refresh. cheers, -- And Clover mailto:and@doxdesk.com http://www.doxdesk.com/

8 11

A better and more basic array type
by Dennis Heuer 27 Apr '06

27 Apr '06

Yes, this was previously "inheriting basic types more efficiently" but now I want something different ;) I looked at the array type and found it quite C-ish. It is also not suited for arithmetics because it's a sequence type like a constrained list and not efficiently (and comfortably) usable like a *sliceable* integer. I'd rather like to find a basic built-in array type in python, which doesn't even ask for the format but just deals with the technical issues internally. This array type works like the long type but is mutable and supports *slicing* (focusing on a bit-range in the presentation of the number). The advantage of this array is that it is fully supporting arithmetics--even on slices--, that there is no need for boundary-checking, and that this mutable array type is actually usable as a superclass for new types. The other type of array, the constrained list, is inclusive: x = array() x += 255 # x now holds the number 255 or, in other words, the first # 8 bits are set to 1 x += "1010" # x interprets "1010" as a bit-pattern and adds 10 x.step(8) # telling x that, from now on, a *unit* is 8-bit long # (for correct slicing and iteration; this is not # related to the real/internal array layout) x[:] = 0 # clearing all bits or setting x to zero f = open("binary file", "rb") x += f.read() for n in x: # n holds always the next 8 bit (a byte) <do something with n> y = x[4:6] # stores the fifth and the sixth byte in y x.step(1) # telling x that, from now on, a *unit* is 1-bit long z = x[4:6] # stores the fifth and the sixth bit in z x[0:2] = z # overwrites the first two bits in x with the two bits in z Possibly the step attribute can become problematic and it's better to define a fix step at initialization. Smaller bit-packages from otherwise compatible types could be packed up with trailing zeroes. I hope that somebody agrees and is already starting to implement this new array type. My best wishes are with you.

2 1

Re: [Python-Dev] inheriting basic types more efficiently
by Dennis Heuer 27 Apr '06

27 Apr '06

Have never seen such an answer before. Please excuse if I read it wrong. The method would just return the new values, for shure. That is what it shall do. The interpreter calls that method for receiving the new (to be used) values to pass them on to the real target (the called attribute). The method is a kind of filter to be used intermediately. Dennis On Wed, 26 Apr 2006 17:35:22 +0200 python-dev-bounces(a)python.org wrote: > The results of your email command are provided below. Attached is your > original message. > > > - Unprocessed: > quite now: > The new-style classes support the inheritance of basic types, like int, > long, etc. Inheriting them is nice but not always efficient because one > can not *control* the inherited methods but only overwrite them. For > example, I want to implement a bitarray type. Because the long type is > unlimited and implemented as an integer array (as far as I know), it > seems to be a good choice for basing a bitarray type on it. Boolean > arithmetics on long integers should work quite fast, I expect. However, > the bitarray class should accept different values than the long type > accepts, like "101010". This is not only true for initialization but > also for comparisons, etc.: > if x < "101010": print True. > Here now the trouble appears. There seems to be no way to catch an > input value before it reaches the attribute, to parse and convert it > into the appropriate integer, and to send this integer to the attribute > instead. One actually has to overwrite all the inherited methods to > call the validation method from inside each of them individually. This > renders the inheritance of the long type useless. One could just write > a new class instead. This is not optimal. > Please think about implementing a method that catches all input values. > > - Ignored: > This method would just return the new values. > > Thanks, > Dennis > > - Done. > >

4 8

Re: [Python-Dev] traceback.py still broken in 2.5a2
by Phillip J. Eby 27 Apr '06

27 Apr '06

At 11:38 AM 4/27/2006 -0700, Guido van Rossum wrote: >The change below was rolled back because it broke other stuff. But IMO >it is actually necessary to fix this, Huh? The change you showed wasn't reverted AFAICT; it's still on the trunk. > otherwise those few exceptions >that don't derive from Exception won't be printed correctly by the >traceback module: It looks like the original change (not the change you listed) should've been using "issubclass(etype, BaseException)". (I only reverted the removal of 'isinstance()', which was causing string exceptions to break.) Anyway, looks like a four-letter fix (i.e. add "Base" there), unless there was some other problem I'm missing?

2 1

traceback.py still broken in 2.5a2
by Guido van Rossum 27 Apr '06

27 Apr '06

The change below was rolled back because it broke other stuff. But IMO it is actually necessary to fix this, otherwise those few exceptions that don't derive from Exception won't be printed correctly by the traceback module: guido:~/p/osx guido$ ./python.exe Python 2.5a2 (trunk:45765, Apr 27 2006, 11:36:10) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def f(): ... raise KeyboardInterrupt ... >>> f() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in f KeyboardInterrupt >>> import traceback >>> try: ... f() ... except: ... traceback.print_exc() ... Traceback (most recent call last): File "<stdin>", line 2, in <module> File "<stdin>", line 2, in f <class 'exceptions.KeyboardInterrupt'> >>> --Guido ---------- Forwarded message ---------- From: phillip.eby <python-checkins(a)python.org> Date: Mar 24, 2006 3:10 PM Subject: [Python-checkins] r43299 - python/trunk/Lib/traceback.py To: python-checkins(a)python.org Author: phillip.eby Date: Fri Mar 24 23:10:54 2006 New Revision: 43299 Modified: python/trunk/Lib/traceback.py Log: Revert r42719, because the isinstance() check wasn't redundant; formatting a string exception was causing a TypeError. Modified: python/trunk/Lib/traceback.py ============================================================================== --- python/trunk/Lib/traceback.py (original) +++ python/trunk/Lib/traceback.py Fri Mar 24 23:10:54 2006 @@ -158,7 +158,7 @@ """ list = [] if (type(etype) == types.ClassType - or issubclass(etype, Exception)): + or (isinstance(etype, type) and issubclass(etype, Exception))): stype = etype.__name__ else: stype = etype _______________________________________________ Python-checkins mailing list Python-checkins(a)python.org http://mail.python.org/mailman/listinfo/python-checkins -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

trunk is UNFROZEN
by Anthony Baxter 27 Apr '06

27 Apr '06

The release is done. The trunk is now unfrozen. Thanks, Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

RELEASED Python 2.5 (alpha 2)
by Anthony Baxter 27 Apr '06

27 Apr '06

On behalf of the Python development team and the Python community, I'm happy to announce the second alpha release of Python 2.5. This is an *alpha* release of Python 2.5. 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/ Since the first alpha, a host of bug fixes and smaller new features have been added. See the release notes (available from the 2.5 webpage) for more. The plan from here is for either one more alpha release, or (more likely) moving to the beta releases, then 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 modules added include hashlib, ElementTree, sqlite3 and ctypes. In addition, a new profiling module cProfile was added. In addition, in the second alpha we have the new 'mailbox' module (a product of last years Google Summer of Code). Enjoy this new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

1 0