Mailman 3 March 2007 - Python-ideas

Mutable chars objects
by Talin 12 Mar '07

12 Mar '07

Something that I have wanted in Python for a long time is something like the Java StringBuffer class - a mutable buffer, with string-like methods, that holds characters instead of bytes. I do a lot of stuff with parsing, and its often convenient to build up long strings of text one character at a time. Doing this with strings in Python is obviously not the way to go, since each time you append a character you have to construct a new string object. Doing it with lists is better, except that you still have to pay the overhead of the dynamic typing information for each character. Also, unlike a list or an array, you'd ideally want something that has string-like methods, such as toupper() and so on. Calling str( buffer ) should create a string of the contents of the buffer, not generate a repr() of the object which is what would happen if you call str() on a list or array. Passing this buffer to 'print' should also just print the characters. Similarly, you ought to be able to comparisons between the mutable buffer and a real string; slices of the buffer should be strings, not lists, and so on. In other words - it ought to act pretty much like STL strings. Also, the class ought to be optimized for single-character appending, it should be smart enough to grow memory in the right-sized chunks; And no, there's no particular reason why the memory needs to be contiguous, although it could be. Originally, I had thought that such a class might be called 'characters' (to correspond with 'bytes' in Python 3000), but it could just as easily be called strbuffer or something else. -- Talin

3 3

Javascript Destructuring Assignment
by Talin 12 Mar '07

12 Mar '07

As you probably know, the next version of Javascript (1.7) will have a number of ideas that have been borrowed from Python. In particular, the "tuple assignment" syntax will now be supported in Javascript, which will be a pleasant addition to the language. However, I noticed that the Javascript version is, in some respects, a superset of the Python functionality. If you are interested, you might have a look at this page: http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7 Go to the section called "Destructuring assignment" to check out how the new syntax is going to work. As an example of what I mean, the Javascript unpacking syntax will allow variables to be skipped: [a,,b] = [1,2,3] In other words, a is assigned the value 1, the value 2 is thrown away, and b is assigned the value 3. In today's Python, this requires a dummy variable. I admit that this is not a particularly important feature; However, given that Javascript is being inspired by Python in this case, maybe it would be appropriate to return the favor? -- Talin

8 19

Syntax to help with currying
by Greg Ewing 10 Mar '07

10 Mar '07

Brett Cannon wrote: > def register(cls, account_id, form_id): > def inner(to_decorate): > ... > return inner Thinking the other day about how this pattern arises quite frequently when doing currying like this, and wondering what sort of syntax might make it easier, I came up with def f(): return g(): ... -- Greg

1 0

if with as
by Armin Ronacher 08 Mar '07

08 Mar '07

Hi all, Many languages allow assignment expressions in if conditions. (Perl, PHP, Ruby, C, etc..) I know that this was dismissed by guido because it can lead to mistakes. And i can support that. However in some situations it might be required because you have to nest if blocks and regular expressions for example:: while pos < text_length: if match = name_re.match(text, pos): pos = match.end() do_something(match) elif match = digit_re.match(text, pos): pos = match.end() do_something(match) else: pos += 1 Well. But that would require an assignment. Why not use the "as" keyword introduced in python2.5 with the future import:: while pos < text_length: if name_re.match(text, pos) as match: pos = match.end() do_something(match) elif digit_re.match(text, pos) as match: pos = match.end() do_something(match) else: pos += 1 Advantages: Still no assignment expression, no additional keyword, simple to understand. Regards, Armin

8 12

while with as [was: if with as]
by Jim Jewett 08 Mar '07

08 Mar '07

Scott Dial schrieb: > Talin wrote: ... >> already existing import syntax), it seems to me that we are, in fact, >> establishing a general rule that: >> <keyword> <expression> as <variable>: >> ...is a common syntactical pattern in Python, meaning 'do something >> special with expression, and then as a side effect, assign that >> expression to the named variable for this block." Rather, assign the result of the do-something. > these are all just broken versions of an infix assignment operator[1]. Not quite, because the precise do-something is implicit in the keywords. With "import", you assign the imported module (or object), rather than the name (string) that was the expression itself. With "with", you assign the result of the enter call, rather than the context object itself. With except, you assign the caught instance, rather than the tuple of classes that caught it. By strict analogy, in while expr as myvar myvar should be the result of calling bool(expr). Fortunately, that is so useless that people would understand the slight change by analogy to "and" and "or", which return the full value rather than the boolean to which it maps. while expr as myvar: # proposal foo(myvar) <==> while (myvar=expr; bool(myvar)): # except that we can't have inline statements foo(myvar) <==> # current python workaround -- though normally we use object-specific # knowlege to keep it from being quite this ugly. _indirect=[] def _test_and_set(val): _indirect[0] = val return val while _test_and_set(val): foo(_indirect[0]) > As for this particular case, it is only useful in a very restricted set > of expressions and I was only able to find a handful of cases in stdlib > where I could drop in a "if x as y". I have wanted it, though not nearly so often as I have wanted it for the "while" loop. The workarounds with break/continue or changing to a for-loop always bother me. That said, I'm still not sure it would be worth the cost, because people might start trying to write while (1,2,3) and expecting an implicit iteration; the confusion to beginners *might* outweigh the benefits. -jJ

2 2

Re: [Python-ideas] Javascript Destructuring Assignment
by Delaney, Timothy (Tim) 07 Mar '07

07 Mar '07

Brett Cannon wrote: >> Are you assuming variable-length skips, so that >> >> [a,,b] = [1,2,3,4,5] would mean a=1;b=5 ? >> > > Yep, that's how I read it. I read it differently. I'm think you need to have a comma for each skipped element: [a,,,b] = [1,2,3,4,5] Anyone with in-depth knowledge, or FireFox 2.0 available to test this? Tim Delaney

3 2

bool keyword: (was [Python-Dev] bool conversion wart?)
by Guido van Rossum 04 Mar '07

04 Mar '07

FWIW, there's zero chance that bool will change in Py3k. Well, unless I get hit by a bus before it's released. It sounds like a typical bikeshed color discussion, not worth the electrons killed to transmit the posts. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Python-ideas] [Python-Dev] bool conversion wart?
by Greg Ewing 03 Mar '07

03 Mar '07

Ron Adam wrote: > Ok, so what if... instead of bool being a type, it be a keyword that is > just a nicer way to spell 'not not'? The main benefit of having a bool type is so that its values display as "True" and "False" rather than whatever surrogate values you happen to have used to represent true and false. The fact that bool() can be used canonicalise a truth value is secondary -- the same thing could just as well be achieved by a plain function (as it was before bool became a type). It's an extremely rare thing to need to do in any case. If any change is to be made to bool in 3.0, my preference would be to keep it but make it a separate type. > Are 'and' and 'or' going to be changed in 3.0 to return bool types too? I very much hope not! Their current behaviour is very useful, and I would hate to lose it. -- Greg

4 11

priorityqueue, sortedlist in collections?
by Jason Orendorff 03 Mar '07

03 Mar '07

I wonder if anyone else finds the heapq and bisect APIs a little dated. It seems like these things could be offered in a more intuitive and featureful way by making them classes. They could go in the collections module: class priorityqueue: def __init__(self, elements=(), *, cmp=None, key=None, reversed=False) def add(self, element) def pop(self) --> remove and return the min element def __iter__(self) --> (while self: yield self.pop()) ... ... any other list methods that make sense ... for example, __len__ but not __getitem__ ... class sortedlist: def __init__(self, elements=(), *, cmp=None, key=None, reversed=False) def add(self, element) # insort # Methods involving searching are O(log N). def __contains__(self, element) def index(self, element) def remove(self, element) ... ... plus all the other read-only list methods, ... and the modifying list methods that make sense ... The point is, most of the API comes from list and sort. I think they'd be easier to use/remember than what we have. Once upon a time Tim mentioned (maybe semi-seriously) possibly adding a Fibonacci heap container. I think a plain old binary heap would be good enough for starters. I could do this. Any interest? -j

6 7