Obviously, the user-attr proposal is not so "simple" as it looks like.
I wish we all realize what's really going on here.
In all cited use cases for this proposal, functions are no more
perceived as functions per se, but as data structures (objects)
which are the target of the computation. IOW, functions are just
considered as *instances* of a class (inheriting from the builtin
"PyFunction" class) with user-attributes, having a state, and
eventually a set of operations bound to them.
I guess that everybody realized that with this proposal, one could
bind not only doc strings, but also functions to the function.
def func(): pass
def serialize(): ...
func.pack = serialize
func.pack()
What is this? This is manual instance customization.
Since nobody said that this would be done 'exceptionally', but rather
on a regular basis for all functions (and generally, for all objects)
in a program, the way to customize instances after the fact, makes
those instances singletons of user-defined classes.
You may say "so what?". Well, this is fine if it were part of the
object model from the start. And there's no reason why only functions
and methods can have this functionality. Stick the __dict__ slot in
the object header and let me bind user-attributes to all objects.
I have a favorite number, 7, so I want to label it Vlad's number.
seven = 7; seven.fanclub = ['Vlad']. I want to add a boolean func
to all numbers, n.is_prime(). I want to have a s.zip() method for a
set of strings in my particular application, not only the builtin ones.
Why is it not allowed to have this today? Think about it!
How would you solve your app needs today? Through classes and instances.
That's the prescribed `legal' way to do customized objects; no shortcuts.
Saying that mucking with functions' __doc__ strings is the only way to
implement some functionality is simply not true.
In short, there's no way I can accept this proposal in its current
state and make the distingo between functions/methods and other kinds
of objects (including 3rd party ones). If we're to go down this road,
treat all objects as equal citizens in this regard. None or all.
The object model must remain consistent. This proposal opens a breach in it.
And not the lightest!
And this is only part of the reasons why I'm still firmly -1 until P3K.
Glad to see that Barry exposed some of the truth about it, after preserving
our throats, i.e. he understood that we understood that he fully understood
the power of namespaces, but eventually decided to propose a fraction of
a significant change reserved for the next major Python release... wink
<wink object at 80c5f30>
>>> wink.fraction = 1e+-1
>>> wink.fraction.precision = 1e-+1
>>> wink.compute()
0.0
--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4