Mailman 3 April 2002 - Python-Dev

Re: [Python-Dev] Re: PEP 279
by Guido van Rossum 02 Apr '02

02 Apr '02

[David Abrahams] > I missed what this function does, x(seq) returns [(0, seq[0]), (1, seq[1]), ...] > but: > > "indexer" is a noun. I like it provided the function returns an > indexer(). Otherwise, I'm not too sure. Yeah, that's my main problem with it. > "enumerate()" sounds like it returns a list of the elements, or is > an iterator interface over the elements. Looking it up at > http://www.m-w.com/cgi-bin/dictionary > shows that it is dangerously close to meaning what we want to say. I say > "dangerously" because it *doesn't* mean what we want to say, and I think > a close-but-not-quite meaning is probably much worse than calling it > wafflebird. I don't know. > unfortunately, numerate and itemize both mean about the same... Numerate is obscure, but itemize() has potential! --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

NEW �ٴ�(Barney) �� SET (��..��)
by �� 02 Apr '02

02 Apr '02

1 0

restrictions on global statement
by Jeremy Hylton 01 Apr '02

01 Apr '02

The lang ref says: Names listed in a \keyword{global} statement must not be defined as formal parameters or in a \keyword{for} loop control target, \keyword{class} definition, function definition, or \keyword{import} statement. (The current implementation does not enforce the latter two restrictions, but programs should not abuse this freedom, as future implementations may enforce them or silently change the meaning of the program.) While this is all technically correct, the second paragraph is a bit misleading. The only case enforced by the compiler is that a formal parameter can't be declared global. Do we actually care about this rule? The lang ref would be shorter if it were silent on the issue, and it would more closely describe the way Python has behaved as long as I've been using it. Jeremy

2 1

"result type only depends on operand types"...?
by Alex Martelli 01 Apr '02

01 Apr '02

Back on March 10 in the thread on PEP 285 Guido wrote: """ This is a very general rule that I like a lot: that the type of a result should only depend on the type of the arguments, not on their values. I expect that this rule will make reasoning about programs (as in PsyCo or PyChecker) easier to do. I recently caved in and allowed an exception: 2**2 returns an int, but 2**-2 returns a float. This was a case of "practicality beats purity". I don't see True-1 in the same league though. """ And yet...: >>> type(2**10) <type 'int'> >>> type(2**100) <type 'long'> ...doesn't this apply to many operators on ints in 2.2? Yet _another_ (set of) exception(s) with practicality beating purity? Perhaps, but if a "very general rule" has so many exceptions in frequent and fundamental cases, is it a rule at all...? Alex

8 18

A Hygienic Macro System in Python?
by James_Althoff＠i2.com 01 Apr '02

01 Apr '02

Or ... invoke callable(): statement1 statement2 . . . statementn is syntax for: def temp(): statement1 statement2 . . . statementn callable(temp) del temp More generally, invoke expr-that-results-in-a-callable(a,b,c) lambda x,y,z: statement1 statement2 . . . statementn is syntax for: def temp(x,y,z): statement1 statement2 . . . statementn expr-that-results-in-a-callable(temp,a,b,c) del temp examples: invoke aquireLockAndDo(): sensitiveStuff() invoke withConnectionDo(): generateReport() invoke gui.showBusyCursorDuring(): doQuery() invoke gui.showStatusDuring(msg="Searching..."): doQuery() invoke gui.showBusyCursorDuring(): invoke gui.showStatusDuring(msg="Generating Report..."): invoke withConnectionDo(): generateReport() invoke button.setEventHandler() lambda event: print event Freely substitute any preferred keyword: "call", "run", etc. instead of "invoke". call aquireLockAndDo(): sensitiveStuff() run aquireLockAndDo(): sensitiveStuff() etc. Doesn't handle return values, but ... Jim

3 2

new section on naming and binding in reference manual
by Jeremy Hylton 01 Apr '02

01 Apr '02

I replaced the old "execution frames" section of the reference manual with the naming rules from Appendix A.1 this afternoon. I made an attempt to be thorough about noting all the rules and corner cases that the old documentation covered, but I may have missed something. For example, I deleted the table of code blocks and namespaces. I think all the rules it described are explained in the text. (And I think most people are better off not thinking too much about the cases it describe <0.2 wink>.) I'd appreciate some review to make sure I've not omitted something that's important. Jeremy

3 2

[development doc updates]
by Fred L. Drake 01 Apr '02

01 Apr '02

The development version of the documentation has been updated: http://www.python.org/dev/doc/devel/ Updated documentation on lexical scoping in the language reference.

1 0

Re: [Python-Dev] Namespaces
by David Abrahams 01 Apr '02

01 Apr '02

----- Original Message ----- From: "Jeremy Hylton" <jeremy(a)zope.com> > > The problem, which your response highlights, is what to call the thing > that isn't a namespace. I think '"attribute" things' suboptimal. How about "object"? Just about anything can have attributes.

1 0

New home for development version of docs
by Fred L. Drake, Jr. 01 Apr '02

01 Apr '02

The "in-developement" version of the documentation, previously found at python.sourceforge.net, is now available from the development area on python.org: http://www.python.org/dev/doc/ -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

1 0

RE: [Python-Dev] Re: PEP 285: Adding a bool typen
by Gerald S. Williams 01 Apr '02

01 Apr '02

I'm not questioning whether it's broken or not, just stating that this is a likely mistake for people to make. Especially since the latter case does work if expr is the result of an operation with a logical result but not for other expressions that are often used in a logical context. I probably should have used "expr_result" rather than "expr". I really meant for "expr" to be a variable, and was thinking about the case where you would do this: expr = ...some expression with a "logical" outcome... if not expr: .... In a strongly-typed language, this isn't an issue, since you'd have declared "expr" as a boolean type. In that case, "not expr" is the same as "expr == False". Considering Python's roots as a teaching language, it would be preferable to immediately catch situations where Boolean values are compared to non-Boolean ones and do *something* about it. -Jerry -O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.com O- -O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661 O- -O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592 O- Paul Svensson wrote: > On Mon, 1 Apr 2002, Gerald S. Williams wrote: > >Consider that the main source of confusion won't come from > >comparisons to True, but comparisons to False. These two > >statements might look identical to the casual observer, but > >they really aren't: > > > > if not expr: > > > > if expr == False: > > Of course they aren't; > the first example is good code, > the second is broken, > and deserves to lose.

1 0