Mailman 3 August 2000 - Python-Dev

Re: [Python-checkins] CVS: python/dist/src/Modules pyexpat.c,2.12,2.13
by Andrew Kuchling Aug. 25, 2000

Aug. 25, 2000

On Thu, Aug 24, 2000 at 02:57:46PM -0700, Fred L. Drake wrote: >Remove the Py_FatalError() from initpyexpat(); the Guido has decreed >that this is not appropriate. So what is going to catch errors while initializing a module? Or is PyErr_Occurred() called after a module's init*() function? --amk

2 1

Re: [Patches] [Patch #101234] Allow all assignment expressions after 'import something as'
by Thomas Wouters Aug. 24, 2000

Aug. 24, 2000

On Sun, Aug 20, 2000 at 01:02:32PM -0700, noreply(a)sourceforge.net wrote: > Summary: Allow all assignment expressions after 'import something as' > Date: 2000-Aug-19 21:29 > By: twouters > > Comment: > This absurdly simple patch (4 lines changed in 2 files) turns 'import-as' > and 'from-import-as' into true assignment expressions: the name given > after 'as' can be any expression that is a valid l-value: > >>> from sys import version_info as (maj,min,pl,relnam,relno) > >>> maj,min,pl,relnam,relno > (2, 0, 0, 'beta', 1) [snip other examples] > This looks so natural, I would almost treat this as a bugfix instead of a > new feature ;) > ------------------------------------------------------- > > Date: 2000-Aug-20 20:02 > By: nowonder > > Comment: > Looks fine. Works as I expect. Doesn't break old code. I hope Guido likes > it (assigned to gvanrossum). Actually, it *will* break old code. Try using some of those tricks on, say, 'encodings', like so (excessively convoluted to prove a point ;): >>> x = {} >>> from encodings import cp1006 as x[oct(1)], cp1026 as x[hex(20)] Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: cannot import name cp1026 I've another patch waiting which I'll upload after some cleanup, which circumvents this. The problem is that find_from_args is having a hard time figuring out how 'import' is being called, exactly. So instead, I create a list *before* calling import, straight from the information available at compile-time. (It's only a list because it is currently a list, I would prefer to make it a tuple instead but I donno if it would break stuff) That patch is necessary to be able to support this new behaviour, but I think it's worth checking in even if this patch is rejected -- it speeds up pystone ! :-) Basically it moves the logic of finding out what the import arguments are to com_import_stmt() (at compiletime), rather than the 'IMPORT_NAME' bytecode (at runtime). The only downside is that it adds all 'from-import' arguments to the co_consts list (as PyString objects) as well as where they already are, the co_names list (as normal strings). I don't think that's a high price to pay, myself, and mayhaps the actual storage use could be reduced by making the one point to the data of the other. Not sure if it's worth it, though. I've just uploaded the other patch, it can be found here: http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470 -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

4 9

two tests fail
by Jeremy Hylton Aug. 24, 2000

Aug. 24, 2000

After the augmented assignment checkin (yay!), I see two failing tests: test_augassign and test_parser. Do you see the same problem? Jeremy

3 4

Re: [Python-checkins] CVS: python/dist/src/Lib UserString.py,1.5,1.6
by Thomas Wouters Aug. 24, 2000

Aug. 24, 2000

On Thu, Aug 24, 2000 at 02:47:36PM -0700, Peter Schneider-Kamp wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5582 > > Modified Files: > UserString.py > Log Message: > > simple typo that makes regression test test_userstring fail WTF ? Hmm. I was pretty damned sure I'd fixed that one. I saw it two times, fixed it in two trees at least, but apparently not the one I commited :P I'll get some sleep, soon :P > *************** > *** 56,60 **** > elif isinstance(other, StringType) or isinstance(other, UnicodeType): > self.data += other > ! else > self.data += str(other) > return self > --- 56,60 ---- > elif isinstance(other, StringType) or isinstance(other, UnicodeType): > self.data += other > ! else: > self.data += str(other) > return self -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

Check your "Accepted" patches
by Skip Montanaro Aug. 24, 2000

Aug. 24, 2000

There are 8 patches with status "Accepted". They are assigned to akuchling, bwarsaw, jhylton, fdrake, ping and prescod. I had not been paying attention to that category and then saw this in the Open Items of PEP 0200: Get all patches out of Accepted. I checked and found one of mine there. Skip

1 0

Augmented assignment
by Thomas Wouters Aug. 24, 2000

Aug. 24, 2000

I've finished rewriting the PyNumber_InPlace*() calls in the augmented assignment patch and am about to check the entire thing in. I'll be checking it in in parts, with the grammar/compile/ceval things last, but you might get some weird errors in the next hour or so, depending on my link to sourceforge. (I'm doing some last minute checks before checking it in ;) Part of it will be docs, but not terribly much yet. I'm still working on those, though, and I have a bit over a week before I leave on vacation, so I think I can finish them for the most part.) I'm also checking in a test case, and some modifications to the std library: support for += in UserList, UserDict, UserString, and rfc822.Addresslist. Reviewers are more than welcome, though I realize how large a patch it is. (Boy, do I realize that!) -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 2

CVS patch fixer?
by Fred L. Drake, Jr. Aug. 24, 2000

Aug. 24, 2000

Someone (don't remember who) posted a Perl script to either this list or the patches list, perhaps a month or so ago(?), which could massage a CVS-generated patch to make it easier to apply. Can anyone provide a copy of this, or a link to it? Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

1 0

Need help with SF bug #112558
by Fred L. Drake, Jr. Aug. 24, 2000

Aug. 24, 2000

I'd like some help with fixing a bug in dictobject.c. The bug is on SourceForge as #112558, and my attempted fix is SourceForge patch #101277. The original bug is that exceptions raised by an object's __cmp__() during dictionary lookup are not cleared, and can be propogated during a subsequent lookup attempt. I've made more detailed comments at SourceForge at the patch: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 Thanks for any suggestions! -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

2 1

PyNumber_*() binary operations & coercion
by Thomas Wouters Aug. 24, 2000

Aug. 24, 2000

While re-writing the PyNumber_InPlace*() functions in augmented assignment to something Guido and I agree on should be the Right Way, I found something that *might* be a bug. But I'm not sure. The PyNumber_*() methods for binary operations (found in abstract.c) have the following construct: if (v->ob_type->tp_as_number != NULL) { PyObject *x = NULL; PyObject * (*f)(PyObject *, PyObject *); if (PyNumber_Coerce(&v, &w) != 0) return NULL; if ((f = v->ob_type->tp_as_number->nb_xor) != NULL) x = (*f)(v, w); Py_DECREF(v); Py_DECREF(w); if (f != NULL) return x; } (This is after a check if either argument is an instance object, so both are C objects here.) Now, I'm not sure how coercion is supposed to work, but I see one problem here: 'v' can be changed by PyNumber_Coerce(), and the new object's tp_as_number pointer could be NULL. I bet it's pretty unlikely that (numeric) coercion of a numeric object and an unspecified object turns up a non-numeric object, but I don't see anything guaranteeing it won't, either. Is this a non-issue, or should I bother with adding the extra check in the current binary operations (and the new inplace ones) ? -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

3 5

2.0 Release Plans
by Tim Peters Aug. 24, 2000

Aug. 24, 2000

PythonLabs had a high-decibel meeting today (well, Monday), culminating in Universal Harmony. Jeremy will be updating PEP 200 accordingly. Just three highlights: + The release schedule has Officially Slipped by one week: 2.0b1 will ship a week from this coming Monday. There are too many Open and Accepted patches backed up to meet the original date. Also problems cropping up, like new std tests failing to pass every day (you're not supposed to do that, you know! consider yourself clucked at), and patches having to be redone because of other patches getting checked in. We want to take the extra week to do this right, and give you more space to do *your* part right. + While only one beta release is scheduled at this time, we reserve the right to make a second beta release if significant problems crop up during the first beta period. Of course that would cause additional slippage of 2.0 final, if it becomes necessary. Note that "no features after 2.0b1 is out!" still stands, regardless of how many beta releases there are. + I changed the Patch Manager guidelines at http://python.sourceforge.net/sf-faq.html#a1 to better reflect the way we're actually using the beast. In a nutshell, Rejected has been changed to mean "this patch is dead, period"; and Open patches that are awaiting resolution of complaints should remain Open. All right. Time for inspiration. From my point of view, you've all had waaaaaay too much sleep in August! Pull non-stop all-nighters until 2.0b1 is out the door, or go work on some project for sissies -- like Perl 6.0 or the twelve thousandth implementation of Scheme <wink>. no-guts-no-glory-slow-and-steady-wins-the-race-ly y'rs - tim

8 17