Python-Dev March 2002

python-dev@python.org

124 participants
237 discussions

RE: [Python-Dev] Those import related syntax errors again...

by Samuele Pedroni

Hi. [Mark Hammond] > The point isn't about my suffering as such. The point is more that > python-dev owns a tiny amount of the code out there, and I don't believe we > should put Python's users through this. > > Sure - I would be happy to "upgrade" all the win32all code, no problem. I > am also happy to live in the bleeding edge and take some pain that will > cause. > > The issue is simply the user base, and giving Python a reputation of not > being able to painlessly upgrade even dot revisions. I agree with all this. [As I imagined explicit syntax did not catch up and would require lot of discussions.] [GvR] > > Another way is to use special rules > > (similar to those for class defs), e.g. having > > > > <frag> > > y=3 > > def f(): > > exec "y=2" > > def g(): > > return y > > return g() > > > > print f() > > </frag> > > > > # print 3. > > > > Is that confusing for users? maybe they will more naturally expect 2 > > as outcome (given nested scopes). > > This seems the best compromise to me. It will lead to the least > broken code, because this is the behavior that we had before nested > scopes! It is also quite easy to implement given the current > implementation, I believe. > > Maybe we could introduce a warning rather than an error for this > situation though, because even if this behavior is clearly documented, > it will still be confusing to some, so it is better if we outlaw it in > some future version. > Yes this can be easy to implement but more confusing situations can arise: <frag> y=3 def f(): y=9 exec "y=2" def g(): return y return y,g() print f() </frag> What should this print? the situation leads not to a canonical solution as class def scopes. or <frag> def f(): from foo import * def g(): return y return g() print f() </frag> [Mark Hammond] > > This probably won't be a very popular suggestion, but how about pulling > > nested scopes (I assume they are at the root of the problem) > > until this can be solved cleanly? > > Agreed. While I think nested scopes are kinda cool, I have lived without > them, and really without missing them, for years. At the moment the cure > appears worse then the symptoms in at least a few cases. If nothing else, > it compromises the elegant simplicity of Python that drew me here in the > first place! > > Assuming that people really _do_ want this feature, IMO the bar should be > raised so there are _zero_ backward compatibility issues. I don't say anything about pulling nested scopes (I don't think my opinion can change things in this respect) but I should insist that without explicit syntax IMO raising the bar has a too high impl cost (both performance and complexity) or creates confusion. [Andrew Kuchling] > >Assuming that people really _do_ want this feature, IMO the bar should be > >raised so there are _zero_ backward compatibility issues. > > Even at the cost of additional implementation complexity? At the cost > of having to learn "scopes are nested, unless you do these two things > in which case they're not"? > > Let's not waffle. If nested scopes are worth doing, they're worth > breaking code. Either leave exec and from..import illegal, or back > out nested scopes, or think of some better solution, but let's not > introduce complicated backward compatibility hacks. IMO breaking code would be ok if we issue warnings today and implement nested scopes issuing errors tomorrow. But this is simply a statement about principles and raised impression. IMO import * in an inner scope should end up being an error, not sure about 'exec's. We will need a final BDFL statement. regards, Samuele Pedroni.

16 years, 1 month

PEP 278 - finished?

by Jack Jansen

As far as I know I've addressed all outstanding issues in PEP 278, http://python.sourceforge.net/peps/pep-0278.html and in the accompanying patch. -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

19 years

rotor module

by M.-A. Lemburg

While discussing the PSF contrib docs with Martin, we came across a possible violation of the US export regulations: According to the BXA web-site, all crypto code with more than 56 bit keys, has to be regsitered with the BXA. rotor uses 80 bit keys. Here's the application we would need to file: http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html The various sections referenced in that document can be found here: http://w3.access.gpo.gov/bxa/ear/ear_data.html With the definition of terms at: http://w3.access.gpo.gov/bxa/ear/txt/772.txt and a chart of available license exceptions at (open source software is covered under TSU): http://www.bxa.doc.gov/Encryption/lechart1.html -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

19 years

2.2.1 release mechanics

by Michael Hudson

I'm aware that I've not been great about keeping people up to date about my timing plans for the last couple of releases, so I'd like to be a little more organized this time. My plan goes roughly as follows: April 8 ~1200 GMT: freeze begins. Over the next 24 hours I'll do tests, write Misc/NEWS, update version numbers, etc. April 9 ~1200 GMT: freeze ends, release begins. This is when Fred, Tim and Jack do their magic, and check any changes they have to make into the tree. I'd really like to get the Mac release done at the same time as the others. During this time, I'll draft changes to python.org and an announcement. April 10 ~1200 GMT: release ends By now, F, T & J have done their bits, uploaded files to creosote and sf (or pointed me to where I can get them), etc. I twiddle pages on creosote, fiddle with sf, tag the tree, cut the tarball, compute md5s, etc. The cunning will notice that this doesn't require me to be in the office after half past five... Does this plan sound reasonable to everyone? Cheers, M. -- I don't have any special knowledge of all this. In fact, I made all the above up, in the hope that it corresponds to reality. -- Mark Carroll, ucam.chat

19 years

PEP 279

by Guido van Rossum

PEP 279 proposes three separate things. Comments on each: 1. New builtin: indexed() I like the idea of having some way to iterate over a sequence and its index set in parallel. It's fine for this to be a builtin. I don't like the name "indexed"; adjectives do not make good function names. Maybe iterindexed()? I don't like the start and stop arguments. If I saw code like for i, j in iterindexed("abcdefghij", 5, 10): print i, j I would expect it to print 5 f 6 g 7 h 8 i 9 j while the spec in the PEP would print 5 a 6 b 7 c 8 d 9 e Very confusing. I propose to remove the start/stop arguments, *or* change the spec to: def iterindexed(sequence, start=0, stop=None): i = start while stop is None or i < stop: try: item = sequence[i] except IndexError: break yield (i, item) i += 1 This reduces the validity to only sequences (as opposed to all iterable collections), but has the advantage of making iterindexed(x, i, j) iterate over x[i:j] while reporting the index sequence range(i, j) -- not so easy otherwise. The simplified version is still attractive because it allows arbitrary iterators to be passed in: def iterindexed(collection): i = 0 it = iter(collection) while 1: yield (i, it.next()) i += 1 2. Generator comprehensions I don't think it's worth the trouble. I expect it will take a lot of work to hack it into the code generator: it has to create a separate code object in order to be a generator. List comprehensions are inlined, so I expect that the generator comprehension code generator can't share much with the list comprehension code generator. And this for something that's not that common and easily done by writing a 2-line helper function. IOW the ROI isn't high enough. 3. Generator exception passing This is where the PEP seems weakest. There's no real motivation ("This is a true deficiency" doesn't count :-). There's no hint as to how it should be implemented. The example has a "return log" statement in the generator body which is currently illegal, and I can't figure out to where this value would be returned. The example looks like it doesn't need a generator, and if it did, it would be easy to stop the generator by setting a global "please stop" flag and calling next() once more. (If you don't like globals, make the generator a method of a class and make the stop flag an instance variable.) --Guido van Rossum (home page: http://www.python.org/~guido/)

19 years

Deprecating string exceptions

by Martin v. Loewis

http://python.org/sf/518846 reports that new-style classes cannot be used as exceptions. I think it is desirable that this is fixed, but I also believe that it conflicts with string exceptions. So I would like to propose that string exceptions are deprecated for Python 2.3, in order to remove them in Python 2.4, simultaneously allowing arbitrary objects as exceptions. Regards, Martin

19 years

Use of PyArg_NoArgs()

by Neal Norwitz

Should the use of PyArg_NoArgs() be deprecated? There are many uses (53) throughout Modules/*.c. It seems that this check is not useful anymore if the MethodDef is set to METH_NOARGS. Is this correct? If so, I can make a patch. Neal

19 years

PEP 285: Adding a bool type

by Guido van Rossum

I offer the following PEP for review by the community. If it receives a favorable response, it will be implemented in Python 2.3. A long discussion has already been held in python-dev about this PEP; most things you could bring up have already been brought up there. The head of the thread there is: http://mail.python.org/pipermail/python-dev/2002-March/020750.html I believe that the review questions listed near the beginning of the PEP are the main unresolved issues from that discussion. This PEP is also on the web, of course, at: http://python.org/peps/pep-0285.html If you prefer to look at code, here's a reasonably complete implementation (in C; it may be slightly out of date relative to the current CVS): http://python.org/sf/528022 --Guido van Rossum (home page: http://www.python.org/~guido/) PEP: 285 Title: Adding a bool type Version: $Revision: 1.12 $ Last-Modified: $Date: 2002/03/30 05:37:02 $ Author: guido(a)python.org (Guido van Rossum) Status: Draft Type: Standards Track Created: 8-Mar-2002 Python-Version: 2.3 Post-History: 8-Mar-2002, 30-Mar-2002 Abstract This PEP proposes the introduction of a new built-in type, bool, with two constants, False and True. The bool type would be a straightforward subtype (in C) of the int type, and the values False and True would behave like 0 and 1 in most respects (for example, False==0 and True==1 would be true) except repr() and str(). All built-in operations that conceptually return a Boolean result will be changed to return False or True instead of 0 or 1; for example, comparisons, the "not" operator, and predicates like isinstance(). Review Dear reviewers: I'm particularly interested in hearing your opinion about the following three issues: 1) Should this PEP be accepted at all. 2) Should str(True) return "True" or "1": "1" might reduce backwards compatibility problems, but looks strange to me. (repr(True) would always return "True".) 3) Should the constants be called 'True' and 'False' (corresponding to None) or 'true' and 'false' (as in C++, Java and C99). Most other details of the proposal are pretty much forced by the backwards compatibility requirement; e.g. True == 1 and True+1 == 2 must hold, else reams of existing code would break. Minor additional issues: 4) Should we strive to eliminate non-Boolean operations on bools in the future, through suitable warnings, so that e.g. True+1 would eventually (e.g. in Python 3000 be illegal). Personally, I think we shouldn't; 28+isleap(y) seems totally reasonable to me. 5) Should operator.truth(x) return an int or a bool. Tim Peters believes it should return an int because it's been documented as such. I think it should return a bool; most other standard predicates (e.g. issubtype()) have also been documented as returning 0 or 1, and it's obvious that we want to change those to return a bool. Rationale Most languages eventually grow a Boolean type; even C99 (the new and improved C standard, not yet widely adopted) has one. Many programmers apparently feel the need for a Boolean type; most Python documentation contains a bit of an apology for the absence of a Boolean type. I've seen lots of modules that defined constants "False=0" and "True=1" (or similar) at the top and used those. The problem with this is that everybody does it differently. For example, should you use "FALSE", "false", "False", "F" or even "f"? And should false be the value zero or None, or perhaps a truth value of a different type that will print as "true" or "false"? Adding a standard bool type to the language resolves those issues. Some external libraries (like databases and RPC packages) need to be able to distinguish between Boolean and integral values, and while it's usually possible to craft a solution, it would be easier if the language offered a standard Boolean type. The standard bool type can also serve as a way to force a value to be interpreted as a Boolean, which can be used to normalize Boolean values. Writing bool(x) is much clearer than "not not x" and much more concise than if x: return 1 else: return 0 Here are some arguments derived from teaching Python. When showing people comparison operators etc. in the interactive shell, I think this is a bit ugly: >>> a = 13 >>> b = 12 >>> a > b 1 >>> If this was: >>> a > b True >>> it would require one millisecond less thinking each time a 0 or 1 was printed. There's also the issue (which I've seen puzzling even experienced Pythonistas who had been away from the language for a while) that if you see: >>> cmp(a, b) 1 >>> cmp(a, a) 0 >>> you might be tempted to believe that cmp() also returned a truth value. If ints are not (normally) used for Booleans results, this would stand out much more clearly as something completely different. Specification The following Python code specifies most of the properties of the new type: class bool(int): def __new__(cls, val=0): # This constructor always returns an existing instance if val: return True else: return False def __repr__(self): if self: return "True" else: return "False" __str__ = __repr__ def __and__(self, other): if isinstance(other, bool): return bool(int(self) & int(other)) else: return int.__and__(self, other) __rand__ = __and__ def __or__(self, other): if isinstance(other, bool): return bool(int(self) | int(other)) else: return int.__or__(self, other) __ror__ = __or__ def __xor__(self, other): if isinstance(other, bool): return bool(int(self) ^ int(other)) else: return int.__xor__(self, other) __rxor__ = __xor__ # Bootstrap truth values through sheer willpower False = int.__new__(bool, 0) True = int.__new__(bool, 1) The values False and True will be singletons, like None; the C implementation will not allow other instances of bool to be created. At the C level, the existing globals Py_False and Py_True will be appropriated to refer to False and True. All built-in operations that are defined to return a Boolean result will be changed to return False or True instead of 0 or 1. In particular, this affects comparisons (<, <=, ==, !=, >, >=, is, is not, in, not in), the unary operator 'not', the built-in functions callable(), hasattr(), isinstance() and issubclass(), the dict method has_key(), the string and unicode methods endswith(), isalnum(), isalpha(), isdigit(), islower(), isspace(), istitle(), isupper(), and startswith(), the unicode methods isdecimal() and isnumeric(), and the 'closed' attribute of file objects. Note that subclassing from int means that True+1 is valid and equals 2, and so on. This is important for backwards compatibility: because comparisons and so on currently return integer values, there's no way of telling what uses existing applications make of these values. Compatibility Because of backwards compatibility, the bool type lacks many properties that some would like to see. For example, arithmetic operations with one or two bool arguments is allowed, treating False as 0 and True as 1. Also, a bool may be used as a sequence index. I don't see this as a problem, and I don't want evolve the language in this direction either; I don't believe that a stricter interpretation of "Booleanness" makes the language any clearer. Another consequence of the compatibility requirement is that the expression "True and 6" has the value 6, and similarly the expression "False or None" has the value None. The "and" and "or" operators are usefully defined to return the first argument that determines the outcome, and this won't change; in particular, they don't force the outcome to be a bool. Of course, if both arguments are bools, the outcome is always a bool. It can also easily be coerced into being a bool by writing for example "bool(x and y)". Issues Because the repr() or str() of a bool value is different from an int value, some code (for example doctest-based unit tests, and possibly database code that relies on things like "%s" % truth) may fail. How much of a backwards compatibility problem this will be, I don't know. If we this turns out to be a real problem, we could changes the rules so that str() of a bool returns "0" or "1", while repr() of a bool still returns "False" or "True". Other languages (C99, C++, Java) name the constants "false" and "true", in all lowercase. In Python, I prefer to stick with the example set by the existing built-in constants, which all use CapitalizedWords: None, Ellipsis, NotImplemented (as well as all built-in exceptions). Python's built-in module uses all lowercase for functions and types only. But I'm willing to consider the lowercase alternatives if enough people think it looks better. It has been suggested that, in order to satisfy user expectations, for every x that is considered true in a Boolean context, the expression x == True should be true, and likewise if x is considered false, x == False should be true. This is of course impossible; it would mean that e.g. 6 == True and 7 == True, from which one could infer 6 == 7. Similarly, [] == False == None would be true, and one could infer [] == None, which is not the case. I'm not sure where this suggestion came from; it was made several times during the first review period. For truth testing of a value, one should use "if", e.g. "if x: print 'Yes'", not comparison to a truth value; "if x == True: print 'Yes'" is not only wrong, it is also strangely redundant. Implementation An experimental, but fairly complete implementation in C has been uploaded to the SourceForge patch manager: http://python.org/sf/528022 Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil fill-column: 70 End:

19 years

POSIX thread code

by Gerald S. Williams

I recently came up with a fix for thread support in Python under Cygwin. Jason Tishler and Norman Vine are looking it over, but I'm pretty sure something similar should be used for the Cygwin Python port. This is easily done--simply add a few lines to thread.c and create a new thread_cygwin.h (context diff and new file both provided). But there is a larger issue: The thread interface code in thread_pthread.h uses mutexes and condition variables to emulate semaphores, which are then used to provide Python "lock" and "sema" services. I know this is a common practice since those two thread synchronization primitives are defined in "pthread.h". But it comes with quite a bit of overhead. (And in the case of Cygwin causes race conditions, but that's another matter.) POSIX does define semaphores, though. (In fact, it's in the standard just before Mutexes and Condition Variables.) According to POSIX, they are found in <semaphore.h> and _POSIX_SEMAPHORES should be defined if they work as POSIX expects. If they are available, it seems like providing direct semaphore services would be preferable to emulating them using condition variables and mutexes. thread_posix.h.diff-c is a context diff that can be used to convert thread_pthread.h into a more general POSIX version that will use semaphores if available. thread_cygwin.h would no longer be needed then, since all it does is uses POSIX semaphores directly rather than mutexes/condition vars. Changing the interface to POSIX threads should bring a performance improvement to any POSIX platform that supports semaphores directly. Does this sound like a good idea? Should I create a more thorough set of patch files and submit them? (I haven't been accepted to the python-dev list yet, so please CC me. Thanks.) -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-

19 years

Re: PEP 279

by Raymond Hettinger

> Subject: Re: [Python-Dev] Re: PEP 279 > From: Guido van Rossum <guido(a)python.org> > Date: Fri, 29 Mar 2002 01:41:05 -0500 [GvR] > I like the idea of having some way to iterate over a sequence and [GvR] > its index set in parallel. It's fine for this to be a builtin. > [RDH] Great! [RDH] > I like itercount() or enumerate(). The reason is that this [RDH] > function can work with any iterable including those that [RDH] > do not have numeric indices (such as dictionaries). [RDH] > Counting or enumeration is what is really happening. > [GvR] I don't like either of those, you don't seem to like iterindexed(), so [GvR] we'll have to think more about a name. [Just] I quite like the name enumerate. Hate itercount. I'm neutral on indexed. [RDH] > 3. itercount(collection) # good enough [GvR] I really hate the alternate count option, so let's agree to pick 3 [GvR] (with a different name). Done! Though my tastes are a little different, iterindexed() works just fine. I'm agreed (agreeing with dictators is good for ones health :-) to option three as you wrote it: [GvR] def iterindexed(collection): [GvR] i = 0 [GvR] it = iter(collection) [GvR] while 1: [GvR] yield (i, it.next()) [GvR] i += 1 Thank you. I'll put it back it the PEP just like this and mark it as Accepted. > > > 2. Generator comprehensions [GvR] If the only way to get you to stop asking for this is a -1 from me, [GvR] I'll give it a -1. Okay, I'll mark this one as rejected. The rationale for the rejection will be that the implementation and maintenance complexities exceed the added value. The added value would be minimal because it's already easy to code the generator directly. [RDH] > Several commenters wanted this one quite a bit. An excerpt: "This [RDH] > rules. You rock." [GvR] Yeah, if I left Python's design to Ping, it would become quite the [GvR] clever hack. :-) Poor Ping, getting a little public ribbing for foolishly supporting my proposal <grin> when the comment actually came from Kragen Sitaker :) > > > 3. Generator exception passing > [RDH] > I need help from others on py-dev who can articulate the need clearly. [RDH] > For me, it's as plain as day and I don't know what to say to convey the [RDH] > message better than it is expressed in the PEP. > [GvR] Too bad. This one gets a big fat -1 until there's a good motivational [GvR] section. Okay, let's defer this one until the case for or against becomes stronger. I'll move it to join the separate PEP for generator parameter passing. Putting that one in a separate pep was necessary because it wasn't yet ready for pronoucement. I'll mark the two (exception passing and parameter passing) as being proposed for 2.4 or later and note that the case is not currently strong enough to warrant acceptance. Executive Summary: 1. iterindexed(collection) --> accepted 2. gen comprehensions --> rejected 3. gen exception passing --> deferred, needs case building 4. gen parameter passing --> deferred, needs alternatives explored Everyone, thank you for your time and thoughtful comments. We're done. Raymond Hettinger _ ~ @ @ \_/

19 years

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev March 2002