Mailman 3 September 2011 - Python-ideas

Proposed additions to inspect module for function and generator state introspection
by Nick Coghlan 01 Oct '11

01 Oct '11

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 with the cell references on the function object, while the latter would be equivalent to doing generator.gi_frame.f_locals with some nice error checking for when the generator's frame is already gone (or the supplied object isn't a generator iterator). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 1

Before and after the colon in funciton defs.
by Ron Adam 24 Sep '11

24 Sep '11

(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 could become ... def foo(...) """ doc string """ # foo.__doc__ = """ doc string """ : <function body> I think this represents what is actually happening a bit better. One possibility for define time code is to have decorators listed that read in the order they are applied instead of bottom up. def foo(n) """ function to be decorated. """ @deco1 # foo = deco1(foo) The '@' notation still works. @deco2 # foo = deco2(foo) : <function body> Note, that putting the doc string after the decorators may be better as it would put the doc string on the decorated function instead of the original. I think there may be more things possible with this idea than the simple cases above. Cheers, Ron

24 82

static vs atdef, etc
by Jim Jewett 23 Sep '11

23 Sep '11

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 22 Sep '11

22 Sep '11

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 22 Sep '11

22 Sep '11

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 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()".

25 81

Re: [Python-ideas] [Python-Dev] Persistent Python - a la Smalltalk
by Glyph Lefkowitz 20 Sep '11

20 Sep '11

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 systematic problems with the ecosystem. > > I willfully leftout the detail that Twisted is not doing it any more :) . So that the person who asked this won't get discouraged, if he has time and energy to pursue it and make some thing new, I thought all the Python community may have another battery called persistance included. Yes, and I put it in in the hopes that they are discouraged :-). There's a staggering number of really good ideas out there for people to work on; why get stuck re-hashing the bad ones? Of course, maybe they've got a really fantastic idea about how a persistent python might work, but they'll have to face more obstacles than this one comment in order to get it done, so it shouldn't make that much of a difference. I think it's my responsibility, as someone who has tried this idea, to make sure that others attempting it know that it's problematic. As Clay Shirky put it: "... learning from experience is the worst possible way to learn something. Learning from experience is one up from remembering. That's not great. The best way to learn something is when someone else figures it out and tells you: 'Don't go in that swamp. There are alligators in there.'" So, trust me: there are alligators in that pickle. -glyph

4 3

Re: [Python-ideas] [Python-Dev] Persistent Python - a la Smalltalk
by Glyph Lefkowitz 19 Sep '11

19 Sep '11

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 Smalltalk (which was built from the start to work like this) it was the source of a number of long-term systematic problems with the ecosystem. -glyph

2 1

truncate sequences in pretty-print ?
by Steven Samuel Cole 18 Sep '11

18 Sep '11

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 something like '...' to indicate truncation, e.g. {'my key': ['my list item 01', 'my list item 02', 'my list item 03', 'my list item 04', 'my list item 05', 'my list item 06', 'my list item 07', 'my list item 08', '...', 'my list item 10',]} somewhat comparable to the '...' already printed when a structure is more deeply nested than you want to know right now. what do you think ? cheers, ssc

3 2

Re: [Python-ideas] allow line break at operators
by MRAB 18 Sep '11

18 Sep '11

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 to that continuation have the same indent. >> >> In both cases there could be blocks nested in blocks and possibly >> continuations nested in continuations, as well as blocks nested in >> continuations and continuations nested in blocks. >> >> I'm not sure what the effect would be if you had mis-indented >> lines. For example, if a line was accidentally indented after a >> comment, then it would be treated as part of the comment. It's in >> cases like those that syntax colouring would be helpful. It would >> be a good idea to use an editor which could indicate in some way >> when a line is a continuation. >> > Thanks, I think that's the rule described in its full glory. > Currently I am not quite sure of the use case for continuation > nested in continuation -- it seems to be still a single continuation, > but it allows for some additional freedom in formatting the continued > line. Do you have other use cases for that? > I don't have a use-case, I was just wondering whether in this: first second third fourth "third" is a continuation, giving this: first second third fourth which has 2 continuations, leading to this: first second third fourth > For the case of mis-indentation, as demonstrated in your scenario, I > think it is better that the rule is not applied to a comment > continued onto the next line. The effect of a '#' only carries to > the end of a line, if one would like the next line to be a comment, > just use another '#'. It remains to consider a mis-indentation that > only involves code lines. However, that is not a new problem, so we > should not worry (it is like a sunken cost). > As well as still limiting a comment to a line, I'd also still limit a string literal (except a triple-quoted string literal) to a line.

7 13

Re: [Python-ideas] [Python-Dev] Persistent Python - a la Smalltalk
by Guido van Rossum 18 Sep '11

18 Sep '11

[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 code in there (or load it in there from other > files). > > The basic idea is that you wont restart your Python script, you would > always modify it on-the-fly. Or a bit less extreme: You would at least > have the possibility with this to do this (like just doing minor > changes). Also, if your PC halts for whatever reason, you can continue > your Python script after a restart. > > This goes along my other recent proposal to store the AST of > statements in the related code objects > (http://thread.gmane.org/gmane.comp.python.devel/126754). An internal > editor could then edit this AST and recompile the code object. > > For the persistance, there would be an image file containing all the > Python objects. > > All in all, much like most Smalltalk systems. > > --- > > Has anyone done something like this already? > > --- > > There are a few implementation details which are not trivial and there > doesn't seem to be straight forward solutions, e.g. most generally: > > * How to implement the persistance? > * How to handle image compatibility between CPython updates? Even possible? > > Regards, > Albert > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido)

5 4