Mailman 3 September 2011 - Python-ideas

Proposed additions to inspect module for function and generator state introspection
by Nick Coghlan Sept. 30, 2011

Sept. 30, 2011

Based on the testability comments in the closure threads, I created http://bugs.python.org/issue13062 to propose two new introspection functions: inspect.getclosure(func) Returns a dictionary mapping closure references from the supplied function to their current values. inspect.getgeneratorlocals(generator) Returns the same result as would be reported by calling locals() in the generator's frame of execution The former would just involve syncing up the names on the code object … [View More]

2 1

Before and after the colon in funciton defs.
by Ron Adam Sept. 23, 2011

Sept. 23, 2011

(This idea may have been suggested before, because it seems too obvious to me.) How about if we remove the requirement that the colon be on the same line as the function name. And, what if the colon is then used to split the difference between the definition time, and call time code in function definitions. So that every thing before the colon is done at definition time. Everything after the colon is done at call time. def foo(...): """ doc string """ <function body> Then … [View More]

24 82

static vs atdef, etc
by Jim Jewett Sept. 22, 2011

Sept. 22, 2011

On Thu, Sep 22, 2011 at 10:34 AM, Paul Moore <p.f.moore(a)gmail.com> wrote: > * I'm sorry but the keyword atdef is ugly. The only proposal I like is > static, but I agree that it only makes sense to someone with a C-type > background. Even with a C background, static is a bad choice, because it has already been used for too many different meanings. (Admittedly, not all in C.) -jJ

2 1

win32 extensions
by Massimo Di Pierro Sept. 21, 2011

Sept. 21, 2011

Just a question. What is the reason the win32 extensions are shipped separately? Is it a licensing issue or is there another reason? Massimo

11 40

Break the dominance of boolean values in boolean context
by Lukas Lueg Sept. 21, 2011

Sept. 21, 2011

Hi, the proposal is to reduce the number of occurences where Python automatically and inevitably uses pure boolean objects (bool()), instead of relying on rich object behaviour. My goal is to give objects finer control over how they want to be interpreted in a boolean context. This reaches down as far as implementing the boolean operations as an object-protocol. In Python, no kind of object is in any way special. Instead of relying on what an object actually IS, we rely on what an object can … [View More]DO. This approach of anti-discrimination is the source of great confidence about the language and it's aversion to black magic. The bool()-type however is a primus inter pares: In numerous locations, Python strongly favors this type of object either explicitly by casting to it or implicitly through the compiled code. Here are a three examples (protocol-, object- and code-based) where Python grinds a boolean context down to pure boolean values: In protocol behaviour: The documentation about how to implement __contains__ vaguely states that the function "should return true, false otherwise". In fact we may return any object that can be interpreted as a boolean, this is intented behaviour. However the implementation of COMPARE_OP in Python/ceval.c inevitably casts the result of "x in y" to Py_True or Py_False, throwing away our object and leaving us with this bool only. This kills any chance of producing useful objects in __contains__, even objects that may have a meaning outside the pure boolean context. For example: x = mycontainer(['foo', 'bar', 'bar', 'foo', 'foo']) y = 'foo' in mycontainer print y == True >> True print y >> mycontainer('foo', 'foo', 'foo') This has been discussed on python-ideas in mid-2010 (http://mail.python.org/pipermail/python-ideas/2010-July/007733.html) without distinct outcome. In object behaviour: Rich Comparision allows numeric- or set-like comparision in any way we like, returing any kind of object. The documentation clearly states that the returned object is only(!) interpreted as a boolean when used in a boolean context (__contains__ falls short here). For example: x = set((1,2,3,4,5)) y = set((2,3,4)) z = x > y print z == True >> True print z >> set([1,5]) # equivalent to x - y z = x < y print z == True >> False print z >> set([]) # equivalent to y - x print 3 > 2 >> 1 print (3 > 2) == True >> True In code behaviour: Why is it, that we can override the behaviour of arithmetic operations like "+, -, *, /", but not the boolean operations like "and, or, xor, not" ? Why do we force any value being generated in a boolean context like "if x == 1 or y == 1" to actually be of boolean type? The result of "(x/y) == 1" may be any kind of object coming from __eq__. However the "or"-operator here grinds them both down to being just True or False. This is due to the fact that the generated bytecode evaluates one expression at a time and does not keep track of the objects it got while doing so. The pure boolean behaviour arises from the use of JUMP_IF_FALSE/TRUE after each comparision. Instead of having boolean operations being a part of the language, we could implement them as a an extension to the Rich Comparision Protocol, giving rise to functions like object.__bor__, object.__bnot__ or object.__band__: The expression "if x == 1 or y == 1" would then become equivalent to tmp1 = x.__eq__(1) if tmp1: return tmp1 tmp2 = y.__eq__(1) if tmp2: return tmp2 return = tmp1.__bor__(tmp2) Likewise, the expression "if x == 1 and y == 1" would become tmp1 = x.__eq__(1) if not tmp1: return tmp1 tmp2 = y.__eq__(1) if not tmp2: return tmp2 return tmp1.__band__(tmp2) The object-example from above now tells us how boolean behaviour and arithmetic behaviour go hand in hand: "(setA > setB) or (setA < setB)" is True because "set([1,5]).__bor__(set([]))" is the same as "set([1,5]) + set([])" and equivalent to True in a boolean context. Likewise, "(setA > setB) and (setA < setB)" is False because "set([1,5]).__band__set([])" is just "set([])". It follows that "(setA > setB) == (setA - setB) == (setA & setB)". We can't do this with boolean operations being part of the language only. Summing all up, I really think that we should break the dominance of bool() and take a look at how we can implement boolean contexts without relying on boolean values all the time. None of this can be implemented without breaking at least the CPython API. For example, the behaviour of __contains__ can't be changed in the proposed way without changing the signature of "int PySequence_Contains()" to "PyObject* PySequence_Contains()". [View Less]

25 81

Re: [Python-ideas] [Python-Dev] Persistent Python - a la Smalltalk
by Glyph Lefkowitz Sept. 20, 2011

Sept. 20, 2011

On Sep 19, 2011, at 3:12 AM, Godson Gera wrote: > On Mon, Sep 19, 2011 at 12:03 AM, Glyph Lefkowitz <glyph(a)twistedmatrix.com> wrote: > > Actually, the Twisted developers also found this to be a terrible idea, and doesn't really do it any more. I definitely understand the appeal of such a system, but it has far too many problems to work well in Python, and even in Smalltalk (which was built from the start to work like this) it was the source of a number of long-term … [View More]

4 3

Re: [Python-ideas] [Python-Dev] Persistent Python - a la Smalltalk
by Glyph Lefkowitz Sept. 18, 2011

Sept. 18, 2011

On Sep 18, 2011, at 4:55 AM, Godson Gera wrote: > Twisted has some feature like that implemented using pickles or some thing. It meant to save the state of the program during restart. I am not sure if that's what you are after. http://twistedmatrix.com > Actually, the Twisted developers also found this to be a terrible idea, and doesn't really do it any more. I definitely understand the appeal of such a system, but it has far too many problems to work well in Python, and even in … [View More]

2 1

truncate sequences in pretty-print ?
by Steven Samuel Cole Sept. 18, 2011

Sept. 18, 2011

hello, i use pprint quite a bit during development to give me quick insight into what is going on inside my application. however, when there's any sequences involved, the output becomes less useful the longer these sequences are - i often find myself scrolling around (or even searching) in the terminal window, trying to find the bit of output i am interested in. imo, it would be great if pprint had a parameter 'max_len' or so that reduces output of every sequence to a maximum and inserts … [View More]

3 2

Re: [Python-ideas] allow line break at operators
by MRAB Sept. 18, 2011

Sept. 18, 2011

On 04/09/2011 00:22, Yingjie Lan wrote: > On 04/09/2011 03:04, MRAB wrote: >> I think that the rules would be: >> >> If a line ends with a colon and the next line is indented, then >> it's the start of a block, and the following lines which belong to >> that block have the same indent. >> >> If a line doesn't end with a colon but the next line is indented, >> then it's the start of a continuation, and the following lines >> which belong … [View More]

7 13

Re: [Python-ideas] [Python-Dev] Persistent Python - a la Smalltalk
by Guido van Rossum Sept. 17, 2011

Sept. 17, 2011

[BCC python-dev, +python-ideas] Funny you should mention this. ABC, Python's predecessor, worked like this. However, it didn't work out very well. So, I'd say you're about 30 years too late with your idea... :-( --Guido On Sat, Sep 17, 2011 at 8:05 AM, Albert Zeyer <albzey(a)googlemail.com> wrote: > Hi, > > I was thinking about a persistent Python interpreter system. I.e. you > start a Python interpreter instance and you load and create all your > objects, classes and … [View More]

5 4