Mailman 3 July 2004 - Python-Dev

Candidate Itertools
by Raymond Hettinger July 1, 2004

July 1, 2004

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 >>> … [View More]

11 15

Re: [Python-Dev] Allowing u.encode() to return non-strings
by Bill Janssen July 1, 2004

July 1, 2004

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 … [View More]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 [View Less]

4 7

Including translated doc strings in 2.4
by "Martin v. Löwis" July 1, 2004

July 1, 2004

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

Re: [Python-Dev] VC 7.1 maintenance?
by IxokaI July 1, 2004

July 1, 2004

> > Are there really technical reasons the VC7.1 built Python binaries must > > be distributed via msi technology or not? > > The most frequently requested thing MSI provides is the ability for admins > to use MS Group Policy to push installs out to boxes on a network. This > hasn't been requested often ("most frequently" is a relative measure ...). Can I jump in with a, "That is a *wonderful* thing" comment? We're about to go into beta with a complete re-… [View More]

1 0

Proposal: thread.get_dict
by Jim Fulton July 1, 2004

July 1, 2004

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 … [View More]

8 25

making weakref.ref objects subclassable
by Fred L. Drake, Jr. July 1, 2004

July 1, 2004

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 … [View More]

2 2

Re: [Python-checkins] python/nondist/sandbox/decimal Decimal.py, 1.37, 1.38
by M.-A. Lemburg July 1, 2004

July 1, 2004

rhettinger(a)users.sourceforge.net wrote: > Update of /cvsroot/python/python/nondist/sandbox/decimal > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22541 > > Modified Files: > Decimal.py > # rename Decimal.py and test_Decimal.py to lowercase decimal > # retarget the test directory to decimaltestdata Shouldn't these steps be applied *before* adding it to the core lib ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly … [View More]

2 2

Re: [Python-Dev] making weakref.ref objects subclassable
by Anthony Baxter July 1, 2004

July 1, 2004

Tim Peters wrote: > For the reasons given before, that won't happen. The analysis I gave was > based on a complete understanding of every gory detail of how Python's gc > works -- there's simply nothing risky about this change wrt gc performance. > Empirical validation is unnecessary <wink>. > > If people want to surprise us, better they spend time writing nasty new > tests of weakref subclassing! Why can I forsee the strings "garbage collector" and "subclasses of … [View More]

2 1

RE: [Python-Dev] PEP 276 (simple iterator for ints)
by Delaney, Timothy C (Timothy) June 30, 2004

June 30, 2004

Nick Coghlan wrote: > Interesting that in the course of this discussion I've gone from 'nice > idea' to 'no way!' That's exactly what happened to me when the PEP was first proposed. On the face of it, it's a nice, simple, easily-understood thing. However, when you think about the use cases, it starts looking more like a hack. Tim Delaney

1 0

Re: [Python-Dev] making weakref.ref objects subclassable
by Fred Drake June 30, 2004

June 30, 2004

On Wednesday 30 June 2004 11:46 pm, Tim Peters wrote: > Well, there is no change to gcmodule.c, except for the indirect change in > what the PyWeakref_Check() macro expands to. The risks with weakrefs The change in the macro expansion is exactly what I was referring to; not a source change, but a real change none the less. > For reasons given above, I believe gc performance will be virtually > unchanged for almost all programs. That was my conclusion as well. Empirical … [View More]

2 1