Mailman 3 April 2002 - Python-Dev

Re: [Python-Dev] Re: PEP 279 revisited
by Neil Schemenauer 24 Apr '02

24 Apr '02

Alex Martelli wrote: > Apart from this, "indices" suggests you're getting ONLY indices -- > while when you iterate on this type you get indices AND contents. Ah, I misunderstood what this unnamed function does. I was thinking it works like .keys() on dictionaries. You're telling me it works like .items(). In that case I don't like enumerate() or itemize(). :-( Neil

2 1

FWD: Re: [Python-Dev] Fw: PEP 279 revisited
by Aahz 24 Apr '02

24 Apr '02

Raymond says Guido is handling the vote. ----- Forwarded message from Aahz <aahz(a)pythoncraft.com> ----- > Date: Wed, 24 Apr 2002 00:30:28 -0400 > From: Aahz <aahz(a)pythoncraft.com> > To: Raymond Hettinger <python(a)rcn.com> > Subject: Re: [Python-Dev] Fw: PEP 279 revisited > >> enumerate() -- does what is says. four syllables is a little long > > +1 ----- End forwarded message ----- -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ What if there were no rhetorical questions?

3 2

Re: [Python-Dev] LOAD_NAME & classes
by Michael Hudson 24 Apr '02

24 Apr '02

Tim Peters <tim.one(a)comcast.net> writes: > [Michael Hudson, on UnboundLocalErrors] > > ... > > Wouldn't it be nice if these were flagged at compile time! More work > > for Jeremy <wink>. > > As will (or already has <wink>) been pointed out, the compiler can only > guess, and can't always guess right (it could err on the side of bothering > you without cause, though). That's what I was implying, yes. > PyChecker goes a long way already. Java has a mass of "definite > assignment" rules instead, which in effect decree that you must > write code in such a way that the compiler can always guess right. Are these explained in an easy to digest form somewhere? Cheers, M. -- I saw `cout' being shifted "Hello world" times to the left and stopped right there. -- Steve Gonedes

3 2

Fw: PEP 279 revisited
by Raymond Hettinger 23 Apr '02

23 Apr '02

From: "Guido van Rossum" > See http://python.org/peps/pep-0279.html > > There's one nagging issue that I'd like to revisit. I think I still > like the name itemize() better than enumerate(), even though itemize() > reminds some people of items(). Somehow that doesn't strike me as a > strong argument: the words look pretty different to me. I like > itemize() better because (a) it's shorter, and (b) the LaTeX command > "\itemize" can produce numbered lists (it can also produce bulleted > lists). I'm ready to open this one for a vote. :-) Voter Information (recap of earlier discussions): iterindexed()-- five syllables is a mouthful index() -- nice verb but could be confused the .index() method indexed() -- widely liked however adjectives should be avoided indexer() -- noun did not read well in a for-loop count() -- direct and explicit but often used in other contexts itercount() -- direct, explicit and hated by more than one person iteritems() -- conflicts with key:value concept for dictionaries itemize() -- confusing because amap.items() != list(itemize(amap)) enumerate() -- does what is says. four syllables is a little long enum() -- pithy; less clear than enumerate; too similar to enum in other languages where it has a different meaning All of the names involving 'count' had the further disadvantage of implying that the count would begin from one instead of zero. All of the names involving 'index' clashed with usage in database languages where indexing implies a sorting operation rather than linear sequencing. All of the names involving 'items' clash with (key,value) concept used for dictionaries. American Heritage definition of itemize: 1. To set down item by item; list. 2. To list deductions from taxable income on a tax return. American Heritage definition of enumerate: 1. To count off or name one by one; list. 2. To determine the number of; count. Raymond Hettinger

1 0

Re: [Python-Dev] SF tracker groups ongoing...
by Anthony Baxter 23 Apr '02

23 Apr '02

> > but we should definately consider using "2.x.y" instead of "2.x.1", > > "2.x.2", etc. > > It's good to know which specific version of Python a bug was reported > against, and e.g. "2.1.1" is more informative than "2.x.y". Perhaps the > unspoken assumption here is that you and/or Anthony want the Group to > identify ... what? Something else, I guess <wink>. It would be nice to know the version, yes, but I'm more looking for things like 'to what does this bug apply'? That a bug was reported against 2.0.1 is completely irrelevant if it's a new bug which has lurked for years. As it is, with the poor filtering and display options available through SF, I can't say 'show me all outstanding 2.1.x bugs'. > > No idea. Is anyone planning to do such a merge [of Feature Requests > > into Bugs]? > Not that I know of. Given the nastiness of working with the trackers, perhaps this isn't a good idea after all. I don't see how we can get the FRs out of the bug tracker, tho. (I think I'm just spoilt having Richard sitting in the same office. I can ask him to make our roundup do what we want, assuming I can't do it myself...) Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

5 5

Re: [Python-Dev] LOAD_NAME & classes
by Michael Hudson 23 Apr '02

23 Apr '02

Tim Peters <tim.one(a)comcast.net> writes: > BTW2, I see plenty of UnboundLocalErrors in my own code, and some of > those have occurred when the same name is also in use as a global. > It's always been a logic error due to forgetting to initialize a > local, and usually due to "moving code up" in an editor. It sure > wouldn't be doing me any favor to let such code silently pick up > whatever crap happened to be bound to the same-named global; > UnboundLocalError is a fine bug-catcher. Wouldn't it be nice if these were flagged at compile time! More work for Jeremy <wink>. Cheers, M. -- Strangely enough I saw just such a beast at the grocery store last night. Starbucks sells Javachip. (It's ice cream, but that shouldn't be an obstacle for the Java marketing people.) -- Jeremy Hylton, 29 Apr 1997

2 1

SF tracker groups ongoing...
by Anthony Baxter 22 Apr '02

22 Apr '02

At the moment we have the following tracker groups: Any 3rd Party Feature Request Irreproducible Not a Bug Platform-specific Python 2.1.1 Python 2.1.2 Python 2.2 Python 2.2.1 candidate Python 2.3 Trash Can these be cleaned up a lot? merge Python 2.1.1 and 2.1.2 into Python 2.1.x, merge Python 2.2 and Python 2.2.1 candidate into Python 2.2.x. We'd need to mass-move the existing entries to them first, tho. I believe this needs one of the SF admin users to do this... Also, why do we have Groups like '3rd Party', 'Feature Request', 'Irreproducible', 'Not a Bug', 'Platform-specific', and 'Trash'? Some of these seem like resolutions, Feature Requests have their own tracker. On the subject of trackers, if FRs are merged into the main tracker then 'group: feature request' makes sense. I'd hope that merging them should be a matter of a database update at SF, to change the 'atid' of the existing items... has anyone asked SF if it's possible? also, why is there an empty 'support requests' tracker? shouldn't it be deleted? Anthony

4 3

autoheader warning for WITH_UNIVERSAL_NEWLINES
by Neal Norwitz 22 Apr '02

22 Apr '02

When running autoheader, I get the following warning: autoheader: missing template: WITH_UNIVERSAL_NEWLINES Sorry, I have no idea why. Neal

12 23

Problems with new-style classes and coercion
by David Abrahams 22 Apr '02

22 Apr '02

This appears to be a 2.2.1 bug. Just looking for confirmation or correction before I put it in the bug tracker: Python 2.2 (#28, Mar 13 2002, 23:18:18) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> coerce <built-in function coerce> >>> class ex(object): ... def __init__(self, v): ... self.v = v ... def __coerce__(self, other): ... return self, ex(other) ... def __add__(self, rhs): ... return ex(self.v + rhs.v) ... def __repr__(self): ... return 'ex(' + repr(self.v) + ')' ... >>> ex(3) ex(3) >>> coerce(ex(1),2.3) (ex(1), ex(2.2999999999999998)) >>> ex(1).__add__(ex(2)) ex(3) >>> ex(1)+2.3 Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 9, in __add__ AttributeError: 'float' object has no attribute 'v' Thanks, Dave +---------------------------------------------------------------+ David Abrahams C++ Booster (http://www.boost.org) O__ == Pythonista (http://www.python.org) c/ /'_ == resume: http://users.rcn.com/abrahams/resume.html (*) \(*) == email: david.abrahams(a)rcn.com +---------------------------------------------------------------+

4 7

Breaking builds
by Tim Peters 21 Apr '02

21 Apr '02

I may or may not have just broken one or more parts of the build for non-Windows boxes. Please check it out, especially on Linux. What changed: As spelled out before, as part of enabling pymalloc we need to redirect PyMem_{DEL, Del} to the pymalloc free(), for backward compatibility of old extension modules. This creates an internal problem because the parser stuff uses these guys, but has never included Python.h, and can't "see" the declarations of the PyObject_XYZ functions in objimpl.h. Instead, pgenheaders.h has been growing its own maze of includes and defines. I scrapped all that, and had it include Python.h instead, like everything else does. This all works on Windows, but Windows is Special <wink>. I at least expect that using pgen to rebuild the grammar files will need to link in obmalloc.o on Linux. Other changes: When PYMALLOC_DEBUG is defined (it is by default in a debug build), *all* PyMem_XYZ functions funnel thru the debugging allocator now. So we get debugging decorations on all allocations then, except for direct calls to platform malloc/realloc/free. Note that platform malloc/realloc/free cannot be mixed with PyMem_XYZ! compile.c actually did that once, and it broke (it's fixed).

1 0