Mailman 3 June 2004 - Python-Dev

Re: [Python-Dev] VC 7.1 maintenance?
by Jack Jansen 05 Jul '04

05 Jul '04

On 16 Jun 2004, at 22:46, Tim Peters wrote: > [M.-A. Lemburg] >> Are we going to have a VC7.1 binary of Python 2.4 for Windows ? > > That's indeed my understanding of The Plan today. More, we will not > have a > VC6 binary for Python 2.4. That may be controversial, but nobody has > volunteered to produce an installer for a VC6 version. Does this mean that the final answer to the question of whether VC7 was GPL-compatible was "yes"? -- Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

7 17

Re: [Python-Dev] Re: decorators and 2.4
by Jewett, Jim J 03 Jul '04

03 Jul '04

Jeff Bone: > Yet --- true, but only if one accepts a particular and rather > simple-minded and overly-literal interpretation of the ***GOALS*** of > PEP 318, That simple-minded and overly-literal interpretation may well be correct. PEP 318 does not intend to change the semantics or capabilities of the language in any way whatsoever. The only reason to add 318 is so that a particular idiom will be easier to understand (and perhaps more efficient). The other goals are really damage control. If the idiom becomes easy to use, it will get used more often. Sometimes, that will be good, as it will replace something more byzantine. It is true that we don't want to encourage certain types of coding, but they're already possible, and the consensus was not to ban them now. Discourage in a style guide, maybe, but not ban. The arguments about syntax are because we don't want the new and improved idiom to end up uglifying the rest of the language. Ideally, any change will remove more clutter than it creates, so adding new meaning to certain magic characters ... is risky. If we put restrictions on decorators, people may just keep using the current idiom -- and then we would have added the clutter for no gain at all. -jJ

6 5

SHA-256 module
by A.M. Kuchling 02 Jul '04

02 Jul '04

Patch #935454 is a module implementing SHA-256, a variant of the 160-bit SHA algorithm supported in Python's existing sha module. Though it's more recent than the original SHA-160, SHA-256 is just as "standard"; both algorithms are specified by a NIST document. The submitter comments: The difference is that it produces a 256 bit hash value, instead of a 160 bit hash value. SHA-256 thus has 128 bits of resistance against birthday attacks, which makes it secure in certain protocols where SHA-1 is questionable (e.g. digital signatures; or RNGs or Key-Derivation Functions where you want to produce keys for 256-bit ciphers). A quick skim over the code doesn't turn up any issues, and the patch includes a test suite but no documentation. I don't want to do a detailed code review or require docs from the submitter if the module isn't likely to be included, so do we want to add this module? There are a bunch of other variants with different bit sizes such as 512, 384, and 224 bits. The only one likely to matter is SHA-512, so adding sha256 might mean that down the road we need to add a sha512 module, too, but that seems unlikely. --amk

9 21

Candidate Itertools
by Raymond Hettinger 01 Jul '04

01 Jul '04

Feedback is requested for two prospective itertools: def count_elements(iterable): b = {} for elem in iterable: b[elem] = b.get(elem, 0) + 1 return ((cnt, elem) for elem, cnt in b.iteritems()) def pairswap(iterable): return ((b,a) for a,b in iterable) The first is designed to provide item counts for min(), max(), sorted(), nlargest(), and nsmallest(). It accepts any iterable including generator expressions: >>> from heapq import nlargest >>> words = (word for line in open('mystory.txt') for word in line.split()) >>> nlargest(count_elements(words), 3) [(200, 'super'), (129, 'hero'), (103, 'villain')] The second handles reordering of fields in tuples of length two. It works well with dict(), enumerate(), dict.iteritems(), itertools.starmap() and anything else that accepts or returns a series of pairs: >>> list(pairswap(_)) [('super', 200), ('hero', 129), ('villain', 103)] >>> inversemap = dict(pairswap(forwardmap.iteritems())) >>> maptoposition = dict(pairswap(enumerate(mysequence))) Raymond P.S. If you have naming suggestions other than pairswap() and count_elements(), I'm all ears.

11 15

Re: [Python-Dev] Allowing u.encode() to return non-strings
by Bill Janssen 01 Jul '04

01 Jul '04

Tim, I'm not sure this needs to be on the list. My major point, I guess, is that the byte vectors we tend to call strings in Python have no string-ness, as understood in the 21st century. There is no character set associated with them, which means that there is effectively no way to look at the "next character" in a string (you don't know how long a character is), no way to count the number of characters, etc. The documentation, particularly the language manual, is extremely confusing on this point, in classifying "string" and "Unicode" objects as the same sort of thing. And then not documenting them clearly. "struct.pack", for instance, doesn't really return a string -- it returns a byte vector. Unicode is really the only kind of *string* type that's supported, which is problematic, as it's not integrated with the file streams support. For instance, how do I write a function that opens a file containing text in some multi-byte format (which, we'll assume, I know the name of -- perhaps from a content-type field), and reads the first three characters of the text? Can't. That's because the "file" constructor doesn't take an encoding, and "read" and "readline" don't return Unicode objects. I could try, by reading some bytes, then using unicode to turn it into a string, then seeing how many characters I read, but that's pretty imprecise. I go round and round the "codecs" module thinking that someone must have thought of this -- or maybe there's an optional argument to file() that make it return real (Unicode) strings -- but no luck. I find it hard to believe that I've dreamed up something that neither you nor (especially) Martin have thought of till now. But consider this idea. Any file that is not explicitly opened as binary (with the 'b' flag (and, by the way, why isn't the 'b' flag the default for file opening? It would save a lot of grief dealing with Windows.)) should be considered a text file, and it should have an associated "encoding" attribute (as file objects already do), which would also be a keyword parameter to the constructor. The default would be sys.getdefaultencoding(). The "size" parameter to the methods "read" and "readline" should refer to characters, not bytes, for text files. The return values from "next", "read" and "readline" would be Unicode objects for text files. Similarly, the methods "write" and "writelines" should, for text files, take Unicode objects and raise an exception if fed a "byte vector". I'd go further. I'd introduce the notation v = b"abc" which means that "v" has assigned to it an 8-bit "string" byte vector. Then, after a release or two, I'd make plain old "foo" mean what u"foo" means today, so that string literals are by default Unicode (module PEP 263). Bill

4 7

Including translated doc strings in 2.4
by "Martin v. Löwis" 01 Jul '04

01 Jul '04

In the translation project, we now have two (partial) translation of Python doc strings: for German, and for Turkish. I'd like to ship the compiled message catalogs with Python 2.4, so that pydoc will automatically display translated doc strings if they are available. I would suggest to place the catalogs into Lib/messages/*.mo (alternatively, if a "non-doc" message catalog for Python is foreseen, Lib/doc/*.mo would also be reasonable). What do you think? Regards, Martin

6 14

Proposal: thread.get_dict
by Jim Fulton 01 Jul '04

01 Jul '04

We often want to associate data with threads. Python manages a dictionary per-tread for this purpose, but there's currently no way to get to this dictionary from Python. I propose, for 2.4, to add a get_dict method to the thread module that will return this dictionary. This will be implemented via a call to PyThreadState_GetDict. Any objections? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

8 25

making weakref.ref objects subclassable
by Fred L. Drake, Jr. 01 Jul '04

01 Jul '04

I'm planning to commit a patch (http://www.python.org/sf/983019) that makes weak references subclassable. This includes the following changes: - weakref.ref and weakref.ReferenceType will become aliases for each other - weakref.ref will be a modern, new-style class with proper __new__ and __init__ methods - weakref.WeakValueDictionary will have a lighter memory footprint, using a new weakref.ref subclass to associate the key with the value, allowing us to have only a single object of overhead for each dictionary entry (currently, there are 3 objects of overhead per entry: a weakref to the value, a weakref to the dictionary, and a function object used as a weakref callback; the weakref to the dictionary could be avoided without this change) - a new macro, PyWeakref_CheckRefExact(), will be added - PyWeakref_CheckRef() will check for subclasses of weakref.ref - the cyclic garbage detector will be affected by the change to PyWeakref_CheckRef(); it will potentially call issubtype() for objects in the unreachable list that do not have finalizers (in the move_troublemakers() function). This should only happen for weakref objects which are not of one of the "standard" three types (ref, proxy, and callable proxy). For debug builds, it will also affect assertions in the clear_weakerfs() and release_weakrefs() functions. The change to the cyclic garbage detector probably carries the most risk, and that only because the potential for a performance penalty. Running the Zope 3 test suite did not show any clear change in performance, and a key subsystem in Zope (zope.interface) uses weakrefs extensively. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

2 2

Re: Revised Proposal: thread.get_dict
by Edward Loper 30 Jun '04

30 Jun '04

Is this also intended for use as a base class? In particular, it seems like if I have a class Foo, then I can make a thread-local version with the following (as long as Foo doesn't rely on overriding __getattribute__/__setattr__). class LocalFoo(local, Foo): pass Is that right? (I can see how it works in the Python implementation, but don't know enough about extensions to see if that translates directly to the c implementation.) Actually, does local.__init__() need a call to super(self, local).__init__() to make this work? -Edward

2 1

PEP 276 (simple iterator for ints)
by Andrew Koenig 30 Jun '04

30 Jun '04

I happened to look at PEP 276 and was struck by the thought that PEP 276 is really an implementation of the well-known set-theoretic construction of the natural numbers that defines each natural number as the set of all smaller ones. In other words, it defines 0 as the empty set, 1 as the set whose only element is 0, 2 as the set whose elements are 0 and 1, and so on. Indeed, under PEP 276, sets.Set(42) would be a set with 42 elements that would be exactly the canonical representation of 42.

4 5