Mailman 3 January 2008 - Python-Dev

Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
by Phillip J. Eby 07 Jan '08

07 Jan '08

At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote: >Maybe the situation is different here, but having someone installing a >different version of sqlite behind my back makes me nervous. Er, someone who? Behind whose back? I'm quite confused by what it is that's making you nervous. Do you worry about people bundling newer versions of say, the optparse module or wsgiref with their applications? If so, why? Or if not, what's different?

8 8

Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
by Phillip J. Eby 06 Jan '08

06 Jan '08

At 03:01 PM 1/6/2008 -0700, Steven Bethard wrote: >Note that this all happens "behind my back" because I didn't know that >pyxml would be replacing pyexpat in such a way that would cause this >crash. In fact, I didn't even know that pyxml was installing pyexpat. Ah -- so this is 100% orthogonal to namespace packages, since this is something that can happen even without __path__ munging. Namespace packages don't actually make this any easier, either, so I don't see how this reflects on the proposal. Without a namespace package, packages earlier on sys.path *completely* override those that are installed later. With a namespace package, only the specific submodules/subpackages that exist can override the ones that appear later. IOW, without namespace packages, if you have two 'foo' packages, one containing 'bar' and the other both 'bar' and 'baz', then with namespace packages you'll always see a foo.bar and a foo.baz, with the contents of foo.bar depending on path order. *Without* namespace packages, the exact same thing is true of foo.bar, but foo.baz will also be either visible or invisible depending on the path order. In other words, the status quo actually has *more* variability of what happens. So, while it might be a good idea to advise people against replacing packages they don't "own" or at least making it prominently visible that a package replaces something in the stdlib, it doesn't (so far as I can tell) have anything to do with the merits of namespace packages one way or the ohter. Unless there is something else I'm missing?

1 0

Return type of round, floor, and ceil in 2.6
by Jeffrey Yasskin 06 Jan '08

06 Jan '08

I've been backporting pep 3141 to the trunk, and ran into the issue that round, math.floor, and math.ceil, which it specifies to return Integrals, currently return floats. Guido suggested privately that, to make sure that 2.6 is compatible with 2.5, they should keep returning floats for float arguments. Probably this implies that they should also keep returning float for int and long arguments. For other types, we're probably free to do whatever. Consistency across all Real implementations suggests that those 3 functions should always return their argument type. Consistency and compatibility with 3.0 suggest that they should return long for every new type we add them to. What does the list think? Thanks, Jeffrey Yasskin

20 53

Extend reST spec to allow automatic recognition of identifiers in comments?
by Jameson "Chema" Quinn 06 Jan '08

06 Jan '08

This is a VERY VERY rough draft of a PEP. The idea is that there should be some formal way that reST parsers can differentiate (in docstrings) between variable/function names and identical English words, within comments. PEP: XXX Title: Catching unmarked identifiers in docstrings Version: 0.0.0.0.1 Last-Modified: 23-Aug-2007 Author: Jameson Quinn <firstname dot lastname at gmail> Status: Draft Type: Informational Content-Type: text/x-rst Created: 23-Aug-2007 Post-History: 30-Aug-2002 Abstract ======== This PEP makes explicit some additional ways to parse docstrings and comments for python identifiers. These are intended to be implementable on their own or as extensions to reST, and to make as many existing docstrings as possible usable by tools that change the visible representation of identifiers, such as translating (non-english) code editors or visual programming environments. Docstrings in widely-used modules are encouraged to use \`explicit backquotes\` to mark identifiers which are not caught by these cases. THIS IS AN EARLY DRAFT OF THIS PEP FOR DISCUSSION PURPOSES ONLY. ALL LOGIC IS INTENTIONALLY DEFINED ONLY BY EXAMPLES AND THERE IS NO REFERENCE IMPLEMENTATION UNTIL A THERE ARE AT LEAST GLIMMERINGS OF CONSENSUS ON THE RULE SET. Rationale ========= Python, like most computer languages, is based on English. This can represent a hurdle to those who do not speak English. Work is underway on Bityi_, a code viewer/editor which translates code to another language on load and save. Among the many design issues in Bityi is that of identifiers in docstrings. A view which translates the identifiers in code, but leaves the untranslated identifier in the docstrings, makes the docstrings worse than useless, even if the programmer has a rudimentary grasp of English. Yet if all identifiers in docstrings are translated, there is the problem of overtranslation in either direction. It is necessary to distinguish between the variable named "variable", which should be translated, and the comment that something is "highly variable", which should not. .. _Bityi: http://wiki.laptop.org/go/Bityi Note that this is just one use-case; syntax coloring and docstring hyperlinks are another one. This PEP is not the place for a discussion of all the pros and cons of a translating viewer. PEP 287 standardizes reST as an optional way to markup docstrings. This includes the possibility of using \`backquotes\` to flag Python identifiers. However, as this PEP is purely optional, there are many cases of identifiers in docstrings which are not flagged as such. Moreover, many of these unflagged cases could be caught programatically. This would reduce the task of making a module internationally-viewable, or hyperlinkable, considerably. This syntax is kept relatively open to allow for reuse with other programming languages. Common cases of identifiers in docstrings ========================================= The most common case is that of lists of argument or method names. We call these "identifier lists":: def register(func, *targs, **kargs): """register a function to be executed someday func - function to be called targs - optional arguments to pass kargs - optional keyword arguments to pass """ #func, targs, and kargs would be recognized as identifiers in the above. class MyClass(object): """Just a silly demonstration, with some methods: thisword : is a class method and you can call it - it may even return a value. As with reST, the associated text can have several paragraphs. BUT - you can't nest this construct, so BUT isn't counted. anothermethod: is another method. eventhis -- is counted as a method. anynumber --- of dashes are allowed in this syntax But consider: two words are NOT counted as an identifier. things(that,look,like,functions): are functions (see below) Also, the docstring may have explanatory text, below or by itself: so we have to deal with that. Thus, any paragraph which is NOT preceded by an empty line or another identifier list - like "itself" above - does not count as an identifier. """ #thisword, anothermethod, eventhis, anynumber, and things would be #recognized as identifiers in the above. Another case is things which look like functions, lists, indexes, or dicts:: """ afunction(is,a,word,with,parentheses) [a,list,is,a,bunch,of,words,in,brackets] anindex[is, like, a, cross, between, the, above] {adict:is,just:words,in:curly, brackets: likethis} """ #all of the above would be recogniszed as identifiers. The "syntax" of what goes inside these is very loose. identifier_list ::= [<initial_word>]<opening_symbol> <content_word> {<separator_symbol> <content_word>} <closing symbol> , with no whitespace after initial_word, and where separator_symbol is the set of symbols ".,<>{}[]+-*^%=|/()[]{}" MINUS closing_symbol. content_word could maybe be a quoted string, too. In the "function name", no whitespace is allowed, but the symbols ".,*^=><-" are. Thus:: """ this.long=>function.*name(counts, and: so |do| these {so-called] arguments) {but,you - cant|use[nested]brackets{so,these,are.identifiers }but,these,arent} {heres.an.example.of."a string, no identifiers in here",but.out.here.yes } { even.one.pair.of.words.with.no symbols.means.nothing.here.is.an.identifier} Any of these structures that open on one line {but.close.on. the.next} are NOT counted as identifiers. """ #in the above: lines 1,2,and the parts of 3 outside the quotes #would be recognized as identifiers The above flexibility is intended to cover the various possibilities for argument lists in a fair subset of other languages. Languages which use only whitespace for argument separation are not covered by these rules. The final case is words that are in some_kind of mixedCase. These are only optionally counted as identifiers if they are also present as an identifier OUTSIDE the comments somewhere in the same file. Doctest and preformatted reST sections should be considered as 100% python code and treated as identifiers (or keywords). Recommended use =============== The rules above are designed to catch the large majority of identifiers already present in docstrings, while applying only extremely rarely to words that should properly be considered as natural language. However, they are inevitably imperfect. All docstrings of modules intended for wide use should manually fix all cases in which these rules fail. If the rules underapply, you can use either \`back quotes\` or parentheses() to mark words as identifiers; if they overapply and reformatting tricks don't fix the problem, <SOME DIRECTIVE TO TURN OFF ALL THIS LOGIC FOR A STRING> Optional use inside comments or non-docstring strings ===================================================== Comments -------- Comments or blocks of comments alone on consecutive lines should be able, optionally, to use these same tricks to spotlight identifiers. Other strings ------------- I'm not sure yet what the rules should be here. One option I'm considering is to be able to turn on all the above logic with some evil hack such as '' 'a string like this, concatenated with an empty string'. Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

2 2

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
by Raymond Hettinger 06 Jan '08

06 Jan '08

[GvR to Tim] > Do you have an opinion as to whether we should > adopt round-to-even at all (as a default)? For the sake of other implementations (Jython, etc) and for ease of reproducing the results with other tools (Excel, etc), the simplest choice is int(x+0.5). That works everywhere, it is easy to explain, it runs fast, and it is not hard to get right. my two cents, Raymond

6 7

Return type of round, floor, and ceil in 2.6
by Art Rasmussen 05 Jan '08

05 Jan '08

Added Python to the referenced article (because I believe Python should be seen everywhere C#, PHP, Visual Basic, etc., are seen). Please let me know if the article needs updating/fixing. http://en.wikipedia.org/wiki/Rounding --- Art Rasmussen

3 2

Repeatability of looping over dicts
by A.M. Kuchling 05 Jan '08

05 Jan '08

This post describes work aimed at getting Django to run on Jython: http://zyasoft.com/pythoneering/2008/01/django-on-jython-minding-gap.html One outstanding issue is whether to use Java's ConcurrentHashMap type to underly Jython's dict type. See <http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentHash…>. ConcurrentHashMap scales better in the face of threading because it doesn't lock the whole table when updating it, but iterating over the map can return elements in a different order each time. This would mean that list(dict_var) doesn't return values in the same order as a later call to list(dict_var), even if dict_var hasn't been modified. Why? Under the hood, there are 32 different locks, each guarding a subset of the hash buckets, so if there are multiple threads iterating over the dictionary, they may not go through the buckets in order. <http://www.ibm.com/developerworks/java/library/j-jtp08223/> discusses the implementation, at least in 2003. So, do Python implementations need to guarantee that list(dict_var) == a later result from list(dict_var)? --amk

7 11

Re: [Python-Dev] Repeatability of looping over dicts
by Raymond Hettinger 05 Jan '08

05 Jan '08

>> ConcurrentHashMap scales better in the face of threading .. . >> So, do Python implementations need to guarantee that list(dict_var) == >> a later result from list(dict_var)? > What code would break if we loosened this restriction? I can imagine someone has code like this: for k in d: print '%5s' % k for k in d: print '-----' for v in d.values(): print '%5s' % v It seems likely to me that a lot of code using d.values() would care about the order of the values and the only order that matters is corresponding to some set of keys. There are probably a lot of functions that take keys and values separately, so it would not be uncommon to call those with a pattern like: save_config(configfile, d.keys(), d.values()). In the OP's context where multiple threads are running, it may be fair to say that all bets are off. Raymond

1 0

Re: [Python-Dev] function call syntax oddity
by Raymond Hettinger 04 Jan '08

04 Jan '08

[Paul Moore] > 1 .__str__() > This one is a number "1" followed by > the operator "." followed by "__str__". FWIW, I would avoid the odd spacing and write this as: (1).__str__() Raymond

1 0

function call syntax oddity
by Joseph Armbruster 04 Jan '08

04 Jan '08

All, I was showing a co-worker some python today (using the trunk) when I stumbled upon this. I was not sure what to think since I have never really experimented with using spaces like this. So here tis. Be careful to notice the spaces as they are significant here. >>> 1.3.__str__() '1.3' >>> 1.3 .__str__() '1.3' >>> a = " somestring " >>> a .split() ['somestring'] >>> a. split() ['somestring'] Cool I suppose, except here's an odd man out: >>> 1.__str__() File "<stdin>", line 1 1.__str__() ^ SyntaxError: invalid syntax >>> 1 .__str__() '1' Joseph Armbruster

2 1