Mailman 3 May 2007 - Python-ideas

Re: [Python-ideas] [Python-Dev] nodef
by Collin Winter 27 May '07

27 May '07

[moving to python-ideas, where it belongs] On 5/23/07, Martin Blais <blais(a)furius.ca> wrote: > I often have the need for a generic object to use as the default value > for a function parameter, where 'None' is a valid value for the > parameter. For example: > > _sentinel = object() > > def first(iterable, default=_sentinel): > """Return the first element of the iterable, otherwise the default value (if > specified). > """ > for elem in iterable: # thx to rhettinger for optim. > return elem > if default is _sentinel: > raise StopIteration > return default > > Here, 'default' could legally accept None, so I cannot use that as the > default value, nor anything else as far as I'm concerned (I don't know > what lives in the iterable, so why should I make assumptions?). > Sometimes in the past I've create generic objects, declared a class, > e.g.: > > class NoDef: pass > def foo(default=NoDef): > ... > > and lately I've even started using the names of builtin functions (it > bothers me a little bit though, that I do that). > > I think Python needs a builtin for this very purpose. I propose > 'nodef', a unique object whose sole purpose is to serve as a default > value. It should be unique, in the same sense that 'None' is unique. I've run into this situation several times before, and I've never felt that defining my own sentinel was unduly taxing. Having a built-in would only save a single line, the initial "sentinel = object()". Collin Winter

4 3

Re: [Python-ideas] [Python-Dev] nodef
by Terry Jones 24 May '07

24 May '07

Adding nodef would be another step on the road to anarchy and nihilism. It wouldn't be long before people began using nodef as a possible value for a function, and then where would we be? Besides, using xxx = object() seems like a safer bet. Your code is unlikely to be accidentally called by someone else using your semi-private xxx object. If there were a documented official nodef object, someone would eventually call you with nodef instead of None. Terry

1 0

crazy ideas
by Aaron Brady 23 May '07

23 May '07

Annotated list callers: q = d[a,b,c] is deque simple sugar for from collections import deque q = deque( a, b, c ) might also do s = s[a,b,c] for s = set([a,b,c])

10 17

Re: [Python-ideas] Positional only arguments
by Ron Adam 23 May '07

23 May '07

Aaron Brady wrote: >> -----Original Message----- >> From: python-ideas-bounces(a)python.org [mailto:python-ideas- >> bounces(a)python.org] On Behalf Of Ron Adam >> >> def f(; a, b=2, c=3;): No positional only, no keyword only > > Do you prohibit defaults in type 1, the pos-only? No > Not necc. Does this look right? > >>>> def f( a=0; b=1 ): > ... print a, b >>>> f() > 0, 1 That's fine. 'a' is positional only and 'b' is either. Having defaults and being positional only are two different things. With the above function the following would be allowed. f() f(1) f(1, 2) f(1, b=2) f(b=2) But not: (If positional only also means no assignment with keywords at call time.) f(a=1) # Keyword not allowed for 'a' at call time. f(b=2, a=1) # 'a' is positional only > Also, does this look right? > >>>> def f( a=0; b ): > ... print a, b > File "<stdin>", line 1 > SyntaxError: non-default argument follows default argument Looks ok to me. Even the error is correct. > Any more groups? So far I have pos-only, pos-or-kw, and kw-only. > > If not, a ascii character works fine to delimit, like * and **. Any character can possibly do it, but does it make sense given that they already have a meaning? I have a feeling we are trying to do too much at once. required optional with default with out default in order in order only with keyword with keyword only Can these be ordered into *any* decision tree that makes sense? > Do we want to annotate each parameter individually? This could get out of > hand. But decorators won't let you do > > @f( k ) > def j( k ): > ... > > where > > @f( 'k' ) > def j( k ): > ... > > gets unwieldy and could show promise. Cf. Steven's positional only > arguments decorator. I think we should let Steven's decorator be developed further. It will at least give a way to test ideas and find more use cases. Then if there are some frequent and common use cases. Then look at what is actually needed. Cheers, Ron

3 3

Have list/deque grow a copy() method
by Ian D. Bollinger 22 May '07

22 May '07

It would be nice if containers had a more consistent interface. The standard idiom for copying a list has been L[:], but this isn't polymorphic and perhaps arcane. Also, deques can only be copied with the copy module's copy function (or calling the __copy__ wrapper directly); thus using copy.copy is the only polymorphic way to copy a mutable container. Additionally, having a consistent interface for mutable containers may dovetail with the ABC PEP. An alternate proposal would be to move copy.copy (and perhaps copy.deepcopy) into __builtins__. (Though this might be nice regardless.) As an aside, in addition to the copy method, list is the only mutable container not to have a clear method. Of course, del L[:] is the standard idiom for doing so, but this has the same problem of not being polymorphic. Perhaps having both del L[:] and L.clear() would violate the TOOWTDI principle, but L.reverse() can also be done with L = L[::-1] (maybe not the best example since they have different semantics.) Nevertheless, one is a lot easier to read. As for a use case, one might be a class that generalizes how it stores elements. For instance... class MutableUnorderedTree(AbstractTree): _storage_class = set class MutableOrderedTree(AbstractTree): _storage_class = list ...the latter has to be adapted to ensure consistent interface for methods like copy/clear. Well, that's my crackpot idea for today. - Ian D. Bolligner

5 11

Positional only arguments
by George Sakkis 22 May '07

22 May '07

This was posted on python-dev two weeks ago [1] but didn't get very far; probably python-ideas is a more appropriate list if this is to be taken any further. In short, PEP 3102 enables the declaration of keyword-only arguments, making it easier for an API to grow in a backwards compatible way. As Benji York, I see the utility of positional-only arguments, not just for the sake of symmetry but for pragmatic reasons; in fact the same reasons that serve as rationale to the keywords-only PEP. I don't have any concrete proposal (syntactic or otherwise) at this point, but I'd like to see this feature in Py3K even if I dislike the specific syntax or other machinery that implements it (just like decorators). For now it's worth just getting an idea of whether the feature itself is deemed useful enough or the current status quo is adequate. George [1] http://mail.python.org/pipermail/python-dev/2006-May/064790.html -- "If I have been able to see further, it was only because I stood on the shoulders of million monkeys." Unknown

15 46

Re: [Python-ideas] Positional only arguments
by Steven Bethard 21 May '07

21 May '07

On 5/21/07, Aaron Brady <castironpi(a)comcast.net> wrote: > Question on it, the example. Is this not a feature of all UserDict > subclasses? Yet we have that anyway. > > >>> from UserDict import * > >>> class C(UserDict): > ... pass > ... > >>> c= C( a=1, b=2 ) > >>> print c > {'a': 1, 'b': 2} > >>> c.update( self=3 ) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: update() got multiple values for keyword argument 'self' Yes, it's a bug still present in UserDict. Using the @positional_only decorator I posted in a separate thread, we can make it work correctly:: >>> class C(object): ... @positional_only ... def __init__(self, container=None, _kwargs=None): ... print container, _kwargs ... >>> C(self=1, container=2) None {'self': 1, 'container': 2} STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

1 0

Re: [Python-ideas] Positional only arguments
by Steven Bethard 21 May '07

21 May '07

On 5/18/07, Aaron Brady <castironpi(a)comcast.net> wrote: > Steven Bethard wrote: > > On 5/18/07, Jim Jewett <jimjjewett(a)gmail.com> wrote: > > > How could there ever be an argument that *needs* to be positional? > > > > As I've mentioned before, a great example of this is the dict() > > signature. It takes an optional "container" argument, followed by > > arbitrary keywords. If you write this in the naive way:: > > > > def __init__(self, container=None, **kwargs) > > ... > > for key, value in kwargs.items(): > > self[key] = value > > > > then you get TypeErrors for the following code:: > > > > d.update(sequence=1, container=2) > > d.update(other=1, self=2) > > > > That is, the **kwargs can never include anything named 'self' or > > 'container'. If you could declare these two arguments as > > positional-only, you'd never run into this problem. > > Might you use d.update(container=2, sequence=1)? 'Can never' caught me up. Not sure I understand the question. My point was only that you'll never reproduce this behavior:: >>> dict(self=1, other=2) {'self': 1, 'other': 2} >>> d = {} >>> d.update(container=2, sequence=1) >>> d {'container': 2, 'sequence': 1} Of course, you can rename the 'self' and 'container' parameters to something else, but that just means that you can't use whatever new names you choose. The only way to solve this is to use real positional-only arguments, which currently means using *args and parsing out things within the function body. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

6 10

Implementing PEP 3130 using decorators
by Arnaud Delobelle 20 May '07

20 May '07

Hi PEP 3130, 'Access to Current Module/Class/Function', proposed the introduction of new keywords (__class__, __function__, and __module__) to refer to what lexical unit theses names were in. It was rejected, but I have thought about a way to produce the same functionality without the need of new keywords, by using decorators instead. It would go like this: class Foo(object): # some defs... @bindclass def bar(thisclass, self): # Within this method the name 'thiclass' refers to class Foo # ... @bindclass def bar(Foo, self): # The name of 'thisclass' can be chosen, just like 'self' can. # Within this method the name 'Foo' refers to class Foo, even # after Foo is bound to another object # ... # More defs... @bindfunction def factorial(thisfunction, n): # Within this function the name 'thisfunction' refers to the factorial # function (with only one argument), even after 'factorial' is bound # to another object if n > 0: return n * thisfunction(n - 1) else: return 1 Here is an implementation: class bindclass(object): def __init__(self, f): self.f = f def bind(self, cls, attr): def bound_m(*args, **kwargs): return self.f(cls, *args, **kwargs) bound_m.__name__ = attr self.m = bound_m def __get__(self, obj, objtype=None): return self.m.__get__(obj, objtype) class Type(type): def __init__(self, name, bases, attrs): for attr, val in attrs.iteritems(): if isinstance(val, bindclass): val.bind(self, attr) class Object(object): __metaclass__ = Type def bindfunction(f): def bound_f(*args, **kwargs): return f(bound_f, *args, **kwargs) bound_f.__name__ = f.__name__ return bound_f And an example: class Foo(Object): @bindclass def foo(this_class, self): return this_class, self class Bar(Foo): @bindclass def bar(this_class, self): return this_class, self f = Foo() b = Bar() f.foo() # -> Foo, Foo object b.foo() # -> Foo, Foo object f.bar() # -> Bar, Foo object -- Arnaud

1 0

Re: [Python-ideas] Positional only arguments
by Arnaud Delobelle 20 May '07

20 May '07

On Wed, May 16, 2007 5:25 pm, George Sakkis wrote: [...] > > What's the future of "private" attributes in Py3K ? I remember Raymond > Hettinger bringing up a challenge on c.l.py about a decorator that > could replace the double underscore mangling and Michele Simionato > caming up with a bytecode hack that showed it is possible. IIRC Michele Simionato made a 'CurrentClass' name available to methods, which contains the class that the method is defined in. While interesting, this doesn't help create 'private' attribute, as name mangling does. In fact it is possible to implement this in pure Python using decorators and metaclasses. I tried to take up the challenge (without bytecode hackery, which I am not capable of) but it turned out you need to chase around the call stack a lot! -- Arnaud

1 0