Mailman 3 December 2015 - Python-ideas

Re: [Python-ideas] Optimizing global names via dict references
by Franklin? Lee Dec. 20, 2015

Dec. 20, 2015

(You sent this as private?) On Dec 19, 2015 7:09 PM, "Victor Stinner" <victor.stinner(a)gmail.com> wrote: > > Le 19 déc. 2015 21:07, "Franklin? Lee" <leewangzhong+python(a)gmail.com> a > écrit : > > Tim Peters points out how it might be more expensive than a lookup. > > Your whole idea rely on the assumption than a dict lookup (two lookups for > builtins) is slow. Remember that a dict lookup has a complexity of O(1)! > That's why I suggested you to start to benchmark, especially know the time > in nanoseconds of a dict lookup. > > > He ended up using versioning, because the notification was expensive. > > Yeah I also began with notification with a registry of functions before > moving to versionning: > http://faster-cpython.readthedocs.org/readonly.html > > Versionning is simple to implement and doesn't make dict operations slower. > > Victor >

1 0

Optimizing global names via dict references
by Franklin? Lee Dec. 19, 2015

Dec. 19, 2015

(Previous threads from python-dev: "Re: [Python-Dev] Third milestone of FAT Python" https://mail.python.org/pipermail/python-dev/2015-December/142437.html "[Python-Dev] Idea: Dictionary references" (Forked from above thread.) https://mail.python.org/pipermail/python-dev/2015-December/142490.html ) Dictionary References: An Idea in Three Emails Act 1: Stuff Table of Contents: Act 1: Stuff https://mail.python.org/pipermail/python-ideas/2015-December/037511.html - Definitions - Problem statement - The idea - The benefits - The costs - What will hold a RefCell? - Add `getref` to `dict` - Implementation issues - Interpreters other than CPython Act 2: More stuff https://mail.python.org/pipermail/python-ideas/2015-December/037512.html - Extension: Scope ancestry - Aside: Classes and scopes do not have the same rules - Extension: Read/write refs - Extension: Read-only refs - Option: Alternative RefCell structure - Option: Replace the methods when detaching a RefCell - Extension: Dynamic scoping - Extension: Thread safety Act 3: Sample pseudocode https://mail.python.org/pipermail/python-ideas/2015-December/037513.html - ScopeDict - Scope ancestry - Alternative RefCell structure - Thread safety == Definitions == "lookup" A dictionary lookup. "exposed RefCell" A RefCell with a PyRef other than by its owner. A RefCell with a refcount > 1. "pyreference" A CPython ref-counted reference. == Problem statement == I propose a CPython interpreter optimization for global name lookups. When a function uses a global name, it requires a lookup during execution. def maxlen(lists): return sum(len(lst) #globals['len'] for lst in lists) This is necessary because: 1. The name might not exist yet. 2. The value might change. Repeated dict lookups are more expensive than, uh, not doing that. Local variables are indexed by array, rather than lookups. (See http://stackoverflow.com/questions/12590058/python-performance-with-global-…) Pythonistas often get around this lookup by saving the name in a local variable. def maxlen(lists): len_ = len return sum(len_(lst) #globals['len'] for lst in lists) They also use a default argument for that variable, which would prevent the lookup during each call. def maxlen(lists, len=len): return sum(len_(lst) #globals['len'] for lst in lists) I think these tricks are theoretically unnecessary. We only need a single lookup, at compile-time. There should be no change to Python's semantics. In fact, this should reinforce the semantics, because the above tricks don't allow for `len` to change, so if this idea is implemented, the tricks would only be used to explicitly disallow changes. == The idea == We use a level of indirection, and allow empty values in the internal dict (scope.__inner__[key] = NULL). Let ScopeDict be a subclass of dict. (It doesn't have to be a subclass. See "ScopeDict should replace dict".) ScopeDict owns a second dict of RefCells. A normal dict owns pyreference to its values. A RefCell will have a pointer to that reference. This means that a RefCell does not need to be notified when a value is set, since it knows where the dict stores its pointer to the value. Instead, when the dict resizes, the dict has to update all of its RefCells. Upon deletion of the dict, ScopeDict will pass ownership of the value pyreferences to the RefCells. That was a simplified view. We can make these optimizations: 1. The RefCells will be held in an array, not a dict. This array will be synced with the dict's internal hash table, and resizes with it. This allows a single lookup for both the value and its RefCell (or lack thereof), because they will be at the same index in different arrays. 2. RefCells won't be created unless they're requested. Obviously. 2a. The array doesn't need to be created unless a RefCell is created. 3. Any time a ScopeDict would touch a RefCell, it would first check that it's not exposed (that is, that the RefCell has no outside references). If it isn't exposed, that Refcell can be safely deleted. 3a. The refs array can also be deleted at this time if it doesn't hold anything. 4. If a key has no corresponding RefCells, it doesn't need to be saved. This can be checked on resize and ScopeDict.__del__, and also can be checked on __delitem__. [See "Pseudocode: ScopeDict"] == The benefits == Every global lookup is done at compile-time. No need to save a local copy of a global variable. Guaranteed to have the most updated value. Even if it didn't exist at compile-time. In particular, it works even for recursive functions and wrapped functions, such as from functools import lru_cache @lru_cache() def fib(n): if n < 2: return n return fib(n-1) + fib(n-2) Access to a global variable during a call is a few C dereferences, plus a few checks and C function calls. No change to the semantics of the language. Possible change in the semantics of CPython: There might be cases where keys live longer than they used to, given the following: 1. `del scope[key]` was called. 2. There was an exposed RefCell for that key. 3. Later, the RefCell stopped being exposed 4. `scope` has not resized since then (and thus didn't clean up its dead cells yet). The above is already possible in garbage-collected interpreter. We can make ScopeDict weakref its RefCells, and have RefCells remove keys with no value when they die, but it would mean extra overhead by wrapping a RefCell with a weakref. Is that worth it? (`getref` will return a strong reference.) == The costs == Memory: - An extra pointer to the refs table in each ScopeDict, and an extra function pointer for the new function. - An extra array for each ScopeDict, 1/3 to 1/4 the size of the internal dict table (depends on how big pointers are on the platform). Note: Since the refs table is the same size as the internal hash table, Raymond Hettinger's compact dict idea will also decrease the size of the refs table. (compact dict idea: https://mail.python.org/pipermail/python-dev/2012-December/123028.html) - Extra memory for each RefCell (a Python object). (There will be at most one RefCell per dict per key.) - The dict will be bigger because it holds empty entries. Execution: - Extra compile time. Functions will do lookups when they're compiled. But we're saving lookups during execution, so it's only extra if the function never gets called or never uses the RefCell. - `getitem`: Must check if the value is NULL. Currently, it only checks the key. - `delitem`: Instead of removing the key, just set the value to NULL. In fact, this is probably cheaper. - Resizing the dict: It will have to copy over all the RefCells (and delete the unused ones) to a new array, too, and update them. - Deleting the dict: The dict will have to DecRef its RefCells, and pass on its value pyreferences to the ones that survive. Python Refs: - We're potentially holding keys even when values have been deleted. This is okay, because most pyreferences to a refcell replace a pyreference to a key. == What will hold a RefCell? == Functions will request RefCells for each global variable they use. They will hold them until they die. Code not in functions (e.g. in module scope), or using eval/exec, will request RefCells during compilation, and they will be used during execution. They will discard the RefCells when they are done executing. == Add `getref` to `dict` == I propose that all dicts should have the ability to return RefCells. As Victor Stinner pointed out in his FAT Python message, using a subclass for scopes would disallow regular dicts being used as scopes by eval and exec. (See end of https://mail.python.org/pipermail/python-dev/2015-December/142397.html) But I think refs can be useful enough that it could be added to the dict interface. Meaning `getref` (via another name... `item`?) can be a new dict method. Upon first use, the dict will generate an empty refs table, and replace its methods with ones that know how to deal with refs. This prevents O(n) memory overhead for dicts that don't need it. == Implementation issues == There are performance _concerns_. I think it can be done with only a few performance _issues_. In my experience in arguing out the idea, the overhead for both memory and execution will be better than what they replace.[*] So while I'm not promising a free lunch, I'm believing in it. There are potential issues with dict subclasses that also change the C function pointers, since I'm proposing that we replace those functions dynamically. I think these issues are solvable, but it would require understanding what's allowed so I would know how to properly wrap that functionality. [*] (Except that there's a tricky case in deep multiple inheritance of scope, which I'd have to figure out. But I don't think it's possible to do that except in classes, and I don't wanna touch class MRO until I understand how the resolution works in C.) [*] (And you can pay a lot of lookups if you keep creating functions that won't get executed, but it's impossible to do such a thing in a loop since the lookups will be done once by the parent. Unless you loop an eval/exec to keep making functions that will never be called, in which case you're a bad person.) == Interpreters other than CPython == It should be possible to use the same idea in IronPython, Jython, and PyPy. I think it's a simple enough idea that I am surprised that it's not already there. In fact, I would not be surprised if PyPy already uses it. In fact, I would not be (very) surprised if I had gotten the idea from PyPy.

4 7

Dict literal use for custom dict classes
by Jelte Fennema Dec. 17, 2015

Dec. 17, 2015

I really like the OrderedDict class. But there is one thing that has always bothered me about it. Quite often I want to initialize a small ordered dict. When the keys are all strings this is pretty easy, since you can just use the keyword arguments. But when some, or all of the keys are other things this is an issue. In that case there are two options (as far as I know). If you want an ordered dict of this form for instance: {1: 'a', 4: int, 2: (3, 3)}, you would either have to use: OrderedDict([(1, 'a'), (4, int), (2, (3, 3))]) or you could use: d = OrderedDict() d[1] = 'a' d[4] = int d[2] = (3, 3) In my opinion both are quite verbose and the first is pretty unreadable because of all the nested tuples. That is why I have two suggestions for language additions that fix that. The first one is the normal dict literal syntax available to custom dict classes like this: OrderedDict{1: 'a', 4: int, 2: (3, 3)} This looks much cleaner in my opinion. As far as I can tell it could simply be implemented as if the either of the two above options was used. This would make it available to all custom dict types that implement the two options above. A second very similar option, which might be cleaner and more useful, is to make this syntax available (only) after initialization. So it could be used like this: d = OrderedDict(){1: 'a', 4: int, 2: (3, 3)} d{3: 4, 'a': 'c'} *>>> *OrderedDict(){1: 'a', 4: int, 2: (3, 3), 3: 4, 'a': 'c'} This would allow arguments to the __init__ method as well. And this way it could simply be a shorthand for setting multiple attributes. It might even be used to change multiple values in a list if that is a feature that is wanted. Lastly I think either of the two sugested options could be used to allow dict comprehensions for custom dict types. But this might require a bit more work (although not much I think). I'm interested to hear what you guys think. Jelte PS. I read part of this thread https://mail.python.org/pipermail/python-ideas/2009-June/thread.html#4916, but that seemed more about making OrderedDict itself a literal. Which is not what I'm suggesting here.

19 35

Contiguous-array-based ordering for OrderedDict
by Franklin? Lee Dec. 17, 2015

Dec. 17, 2015

Here's Tim Peters's 2013 explanation of OrderedDict: http://stackoverflow.com/a/18951209/2963903 He said: > But if [the order list] were a Python list, deleting a key would take O(n) time twice over: O(n) time to find the key in the list, and O(n) time to remove the key from the list. I didn't see why this would need to be the case. 1. If you start searching from the front, then each element would be inspected or shifted, never both. This would mean only one full iteration. 2. You don't have to shift for each deletion. You can wait until some threshold is reached before shifting, and maybe that will spread out the cost of shift among deletions enough to make an impact. 3. He then mentions that the linkedlist implementation uses a second dict to map keys to their list nodes. Well, that would solve the cost of lookup for lists, too. So I ended up taking 3.5.0's OrderedDict and implemented the idea. I'm not really sure what to do next, in terms of testing and comparing it against the existing implementation, and whether it's worth pushing for such a design for OrderedDict (current Python version or future C cersion). It's enough for me if I can figure out how this compares in performance, both algorithmically and actually, to the current implementation. -------------------------------------------------------------------- First idea: (link: http://pastebin.com/LESRktJw) Data members (with ListDict() as od): - super() : dict[key] => value - od.__map : dict[key] => index where od.__list[index] = key - od.__list : list[index] => key or `_sentinel` - od.__size : int - number of non-sentinel elements in list (aka len(dict)) - This might be replaceable by len(self). Some algorithms to note: - .__setitem__: Add it to the end of __list if it's new. - .__delitem__: Replace the __list entry with `sentinel`, and attempt to compact the list. - .__compact: Called when items are removed. Naive threshold: If the list is 50% empty, then make a new list and update the indices for each key. - (iterator views): Simply yield things that aren't `sentinel`. - .move_to_end(last=False): The biggest loss. Adding to the front of the list will shift potentially many things up. Maybe if the list were a dequeue, this would be faster. The actual length of __list will slow down iteration through the list, but the factor of O(n) is dependent on the threshold value. And the code itself MIGHT be faster per-element, and maybe (big maybe) easier for the hardware. Needs special review: - __sizeof__: I have no idea if I did this right. - (iterators): Can they be made to sometimes detect additions/removals during iteration? - Exception safety: E.g. in __setitem__, the order of updates for the metadata might leave the dict in an invalid state. Also needs review: - I put a lot of global calls as default args, but the existing use of default args for static name lookup seemed inconsistent. -------------------------------------------------------------------- Second idea: thicker wrapper. Store a key,value,index triple in the internal dictionary, instead of just the value. This will have a wrapper cost on __getitem__ (have to get the value from the triple), but will save many lookups for adding and removing elements (which is probably the less-common use). (At the C level, it should be possible to keep multiple storage dictionaries in lockstep. Also, the triple doesn't need to be exposed to the Python interface, right?) Type: class _DictStorage(object): __slots__ = ['key', 'value', 'index'] Members: (external): ListDict[key] => value super() : dict[key] => [key, value, index] .__list : list[i] => [key, value, index] (same as above) or None .__size : as in the other implementation. Probably just as unnecessary. .__map : (removed; unneeded) Some method implementations: .__getitem__: Grab the [k,v,i] from the inner dict and unwrap it. .__setitem__: If the triple exists, update its value. If it doesn't exist, add in [k, v, len(__list)-1] and append it to __list. (This saves a lookup in the internal dict.) .__delitem__: inner.pop(key), and use the index to None it on the list. (iteration): Same as the first ListDict implementation, except using None instead of _sentinel. .move_to_end, .__compact: Same as the first ListDict, except I won't have to dict.get the keys to update their indices. Third idea: Well, I have to learn PyPy's implementation of OrderedDict.

10 25

Trailing-based state restoration
by SAVEANT Pierre Dec. 17, 2015

Dec. 17, 2015

Hi, I got a proposal for a new feature in Python in order to perform hypothetical reasoning in a very simple way. Hypothetical reasoning is mainly used in problem solving search algorithms. In such a process, variables are temporally assigned and later restored to their preceding value. With the assumption that only a small fraction of the variables changes at the same time, it is more efficient to store undo information instead of copying the entire state. The basic data structure to handle these moves efficiently is called a trail which is mainly a stack with markers. Potentially this mechanism can be provided to any object type of Python. Only few lines are needed to implement the mechanism using the reflexive power of Python. A deeper implementation could hide the process in the internal data representation in order to offer this new feature in a seamless way. This new feature is activated with the specification of thee primitives: - push() - back() - assign(object, attribute, value) push : declare a new hypothetical state. back : restore the previous state. assign(object, attribute, value) : assign the value to the attribute of the object in the current state. In addition a primitive can be provided to go back to a specific state: backtrack(n): restore the state number n. EXAMPLES class Var: def __init__(self, value): self.value = value def __str__(self): return"{}".format(self.value) def test1(): V1 = Var(10) assert V1.value == 10 push() assign(V1, 'value', 100) assert V1.value == 100 back() assert V1.value == 10 def test2(): V1 = Var(0) for i in range(8): push() for j in range(5): assign(V1, 'value',(j+1)+i*5-1) assert V1.value == 39 assert current() == 8 backtrack(6) assert V1.value == 29 assert current() == 6 backtrack(4) assert V1.value == 19 assert current() == 4 backtrack(0) assert V1.value == 0 assert current() == 0 The assign procedure is used in place of the standard assignment denoted by the "=" operator. In a seamless integration the "=" assignment operator could be overridden when the variable has been previously declared as "recordable" (require a declaration primitive or a type declaration). Is anybody interested by this new feature? Pierre Savéant

2 2

generic Liftable abc-mixin breaks at MRO
by Stephan Sahm Dec. 11, 2015

Dec. 11, 2015

Dear all, I think I found a crucial usecase where the standard MRO does not work out. I would appreciate your help to still solve this usecase, or might MRO even be adapted? The idea is to build a generic Lift-type which I call this way because the derived classes should be able to easily lift from subclasses. So for example if I have an instance *a* from *class A* and a *class B(A)* I want to make *a* an instance of *B* in a straightforward way. My implementation (Python 2.7): import abc import inspect def use_as_needed(func, kwargs): meta = inspect.getargspec(func) if meta.keywords is not None: return meta(**kwargs) else: # not generic super-constructor - pick only the relevant subentries: return func(**{k:kwargs[k] for k in kwargs if k in meta.args}) class Liftable(object): __metaclass__ = abc.ABCMeta def __init__(self, **kwargs): use_as_needed(super(Liftable,self).__init__, kwargs) use_as_needed(self.__initialize__, kwargs) @abc.abstractmethod def __initialize__(self, **kwargs): return NotImplemented() class NoMatchingAncestor(RuntimeError): pass class NotLiftable(RuntimeError): pass def lift(self, new_class, **kwargs): # Stop Conditions: if self.__class__ is new_class: return # nothing to do elif new_class is object: # Base Case # break recursion at once: raise NoMatchingAncestor() elif new_class.__base__ is not Liftable: #to ensure this is save raise NotLiftable("Class {} is not Liftable (must be first parent)".format(new_class.__name__)) # recursive case: if not self.__class__ is new_class.__bases__[1]: lift(self, new_class.__bases__[1], **kwargs) # own case: self.__class__ = new_class use_as_needed(self.__initialize__, kwargs) and the example usecase: class A(object): def __init__(self, a): self.a = a class B(Liftable, A): def __initialize__(self, b): self.b = b a = A(1) print a.a, a.__class__ # 1 <class '__main__.A'> lift(a, B, b=2) print a.a, a.b, a.__class__ # 1 2 <class '__main__.B'> this works so far, however if I now put a further level of Liftable (which in principal already works with the generic definition class C(Liftable, B): def __initialize__(self, c): self.c = c I get the error TypeError: Error when calling the metaclass bases Cannot create a consistent method resolution order (MRO) for bases Liftable, B I read about MRO, and it seems to be the case that this setting somehow raises this generic Error, however I really think having such a Lifting is save and extremely useful - how can I make it work in python? (one further comment: switching the order of inheritance, i.e. class B(A, Liftable) will call A.__init__ before Liftable.__init__ which makes the whole idea senseless) Any constructive help is appreciated! best, Stephan

4 9

MRO local precedence ordering revisited
by Stephan Sahm Dec. 10, 2015

Dec. 10, 2015

Dear all, I just pushed a very specific question which as I now recognized is far more general: It concerns python MRO (method resolution order). As reference I take https://www.python.org/download/releases/2.3/mro/ There the section "Bad Method Resolution Orders" starts with an example which behaviour in the current python 2.7 is rather unintuitive to me. I rename the example slightly to illustrate its usecase. class Mixin(object): > pass class A(Mixin): > pass > class B(Mixin, A): > pass this unfortunately throws "TypeError: Error when calling the metaclass bases Cannot create a consistent method resolution order (MRO) for bases A, Mixin" The reference name above comments this case similar to the following (adapted to the easier example above): > We see that class > B > inherits from > Mixin > and > A > , with > Mixin > before > A > : therefore we would expect attribute > s of > B > to be inherited > first > by > Mixin > and > then > by > A > : nevertheless Python 2.2 > was giving the opposite behaviour. > ... > As a general rule, hierarchies such as the previous one should be avoided, > since it is unclear if > Mixin > should override > A > or viceversa While it might be the case that in Python 2.2 things where different, I cannot agree that the expected order of Method resolution is ambiguous (at least as far I see at this stage). The reference itself says that we would expect B to be inherited first by Mixin and then by A. There is no ambiguity any longer. *Therefore I would like to propose to make this MRO again a valid one.* The usecase should be obvious: If you want a Mixin to be the first thing overwriting functions, but still want to inherit as normal. (I myself want for instance a Mixin to overwrite the __init__ method, which is simply not impossible when choosing class B(A, Mixin)) best, Stephan

8 13

ExitStack: Allow exiting individual context managers
by Ram Rachum Dec. 9, 2015

Dec. 9, 2015

Hi guys, I'm using `contextlib.ExitStack` today, and pushing context managers into it. I find myself wanting to exit specific context managers that I've pushed into it, while still inside the `with` suite of the `ExitStack`. In other words, I want to exit one of the context managers but still keep the `ExitStack`, and all other context managers, acquired. This isn't currently possible, right? What do you think about implementing this? Thanks, Ram.

4 7

Using functools.lru_cache only on some arguments of a function
by Bill Winslow Dec. 7, 2015

Dec. 7, 2015

This is a question I posed to reddit, with no real resolution: https://www.reddit.com/r/learnpython/comments/3v75g4/using_functoolslru_cac… The summary for people here is the following: Here's a pattern I'm using for my code: def deterministic_recursive_calculation(input, partial_state=None): condition = do_some_calculations(input) if condition: return deterministic_recursive_calculation(reduced_input, some_state) Basically, in calculating the results of the subproblem, the subproblem can be calculated quicker by including/sharing some partial results from the superproblem. (Calling the subproblem without the partial state still gives the same result, but takes substantially longer.) I want to memoize this function for obvious reasons, but I need the lru_cache to ignore the partial_state argument, for its value does not affect the output, only the computation expense. Is there any reasonable way to do this? Things such as memoizing a wrapper don't actually solve the problem. About the only way I can think of with current technology is either to have a hidden singleton class which maintains state, or a hidden global variable, which amount to the same thing of storing the partial state outside the function. But those strike me as unwieldy and unpythonic. What I'd really like to do is to have some way to tell functools.lru_cache to ignore some arguments of a function it's memoizing for the purposes of caching. One way would be to add an "arg_filter" argument, which for purposes of this example would be used like so: @lru_cache(arg_filter=lambda args, kwargs: args[:1], {}) def deterministic_recursive_calculation(input, partial_state=None): condition = do_some_calculations(input) if condition: return deterministic_recursive_calculation(reduced_input, some_state) This effectively ignores all arguments except the first positional one for the purposes of caching. Such an option could be implemented as in the diff below (provided only for discussion purposes). So what I want to know is: 1) Am I sane? Is there no particularly good way currently to go about caching functions following the given pattern? 2) Assuming the answer to 1) is "Yes I am sane, and there's no good way currently", is my proposal a reasonable one? Mostly on philosophical grounds, not necessarily specifics of how it works. Thank you for your time and consideration. Bill ---------------------------------------------------------------------------------------------------------------------------------- https://hg.python.org/cpython/file/3.5/Lib/functools.py diff functools.py functools.py.orig 363c363 < def _make_key(args, kwds, typed, arg_filter, --- > def _make_key(args, kwds, typed, 377,378d376 < if arg_filter is not None: < args, kwds = arg_filter(args, kwds) 393c391 < def lru_cache(maxsize=128, typed=False, arg_filter=None): --- > def lru_cache(maxsize=128, typed=False): 403,406d400 < *arg_filter* is an optional function which filters user-speicified portions < of the arguments from the caching key (e.g. if an argument affects the < computation but not the final result). < 428,430d421 < if arg_filter is not None and not callable(arg_filter): < raise TypeError('Expected arg_filter to be a callable') < 432,433c423 < wrapper = _lru_cache_wrapper(user_function, maxsize, typed, arg_filter, < _CacheInfo) --- > wrapper = _lru_cache_wrapper(user_function, maxsize, typed, _CacheInfo) 438c428 < def _lru_cache_wrapper(user_function, maxsize, typed, arg_filter, _CacheInfo): --- > def _lru_cache_wrapper(user_function, maxsize, typed, _CacheInfo): 466c456 < key = make_key(args, kwds, typed, arg_filter) --- > key = make_key(args, kwds, typed) 481c471 < key = make_key(args, kwds, typed, arg_filter) --- > key = make_key(args, kwds, typed)

6 9

Multiple arguments for decorators
by Emanuel Barry Dec. 2, 2015

Dec. 2, 2015

An idea that I had a couple of times was to have a syntactic way to define multiple arguments for a @decorator. This would be good if you want to, for example, define a property with a getter and a setter. I had a few ideas, but none of them seem to be "the obvious way to do it". I'm including them anyway, but I'd rather see if people are interested in the idea or if it's just something that's not worth it. I'll gladly write a PEP if it gains a lot of interest. Method 1: Add parens around all arguments class Foo: def __init__(self): self._x = 42 @property( def x(self): # getter return self._x def x(self, value): # setter self._x = value def x(self): # deleter del self._x ) This one was my first idea, but with long methods you might very well miss the closing paren, or even wonder "how does the code even run?" Good for small properties like this, bad with longer methods. -1 from me Method 2: Specify how many arguments in the decorator class Foo: def __init__(self): self._x = 42 @3:property def x(self): # getter return self._x def x(self, value): # setter self._x = value def x(self): # deleter del self._x This one would get all three following methods defined (or should it get any value defined -- for example, a None in place of the setter there, would set the setter to None). Implementation-wise, I believe the order is kept while the class is first evaluated, and then often thrown away when it's inserted into the class' __dict__ (I could be wrong, though). This has the advantage of not breaking code already written, as it cannot possibly conflict with an existing name. I'm neutral here. Method 3: Specify arguments using the parameters' names class Foo: def __init__(self): self._x = 42 @property def x:fget(self): return self._x def x:fset(self, value): self._x = value def x:fdel(self): del self._x This has the advantage of being explicit (and the arguments can be swapped since they're named), but the disadvantage that some builtins don't accept kwargs (this would be a good occasion to fix that, though, but that is besides my point). I've got mixed feelings on this one. I'm neutral as well here. What do you guys think? Is this a good idea, or is it not? Thank you for your time!-Emanuel

18 39