Paul Morrow wrote:
> That's a terrible way to 'think' about this kind of programming ---
> programming thru imperative mutation.
This is Pythonic. In Python, we don't have any declarations (well,
perhaps except for global). Instead, everything in a module is
executed, including class and def statements. This is an important
property, as it allows:
- conditional function definition:
if some_condition:
def foo():some_code
else:
def foo():other_code
- computed inheritance:
if some_condition:
base = B1
else:
base = B2
class D(base):
body
- and more
Decorators extend this pattern.
> So regardless of what is going on under
> the hood, it's better to think of this technique as a function
> annotation --- something additionally stated in its description --- than
> something that we *do* to the function.
No. It is best to simultaneously think of this as descriptive *and*
imperative. I.e. for most purposes, it is sufficient to consider it
descriptive, but one always needs to be aware when it is more correct
to consider it imperative. For example, you have to understand that
@foo
def bar():self
might cause bar *not* to be a function. This can only be understood
if you don't think of decorators as kind of attribute.
> *When* a feature gets added/applied to a class/function shouldn't matter
> to the programmer. We've screwed up if we make them think that hard.
Depends on the situation. In some cases, it does matter, and then the
programmer needs to think hard. However, she can only succeed in that
case if she is even *aware* that the declarative view on these things
is a simplification.
> They should simply be able to state which features they want a
> class/function to have (as they can now with __metaclass__, __lt__,
> etc.), and the system makes sure they are there when the class/function
> is called. It's magical, but its easy to think about.
Yes, it works most of the time. If this simplification is wrong, it
gets so terribly wrong that the programmer needs somebody else who
really understands it solves the problem. To avoid that, we should not
try to hide the semantics, but make it obvious - and simultaneously
explain that in most cases, the simplification will serve fine.
> That should be
> irrelevant to the programmer. It's magic.
No, no, no. In a well-designed programming language, there is no place
for magic, in the sense that what really happens is deliberately hidden
for nobody to find. Instead, people should *know* the inner workings.
Many people know the inner workings of the current language, and they
can easily extend their mental model to decorators.
Regards,
Martin
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