On Thu, 06 Jan 2011 09:03:02 -0800, Ian wrote:
> On Jan 6, 9:32 am, Tim Harig <user...@ilthio.net> wrote:
>> 2. Your so-called PEP probably clashes with Python's use of @ for
>> decorators.
>>
>> 3. Do you really expect a language holding the mantra that there should
>> be
>> a single way of doing things to embrace a language bloating
>> feature for what is effectively already possible with the
>> language as it exists?
>
> Isn't "Python's use of @ for decorators" a "language bloating feature
> for what [was] effectively already possible with the language as it
> [existed]?" ;-)
Yes. The difference is that the invention of decorator syntax was a huge
success, encouraging people to write code in a new way that added great
power and expressiveness to their code. Guido's intuition as a language
designer got decorator syntax right.
Although function decorators of a sort have been possible since Python
1.5 or older (functions have always been first class objects), it needed
good syntax that puts the wrapper function up near the function def to
get people to see their potential. Decorator syntax isn't merely a time-
saver, or to reduce the number of keystrokes needed from this:
def spam():
pass
spam = wrapper(spam)
to this:
@wrapper
def spam():
pass
While the two are functionally equivalent, the two are not mentally
equivalent to the reader and writer. Decorators are significantly
enhanced by the new syntax: it means you no longer have to use the
function name three times, which is a code smell. More importantly, it
puts the wrapper up with the function signature, where it belongs,
instead of obscurely down the bottom past the definition. The end result
has been to take a powerful design pattern that was always possible but
hardly ever used, and make it friendly and far more common. This has been
a huge win.
So @ loses two points for being obscure and bringing nothing new to the
language, while gaining ten thousand points for being one of the most
successful examples of syntactic sugars since people realised they could
use assembly language op codes instead of writing in hex.
The use of syntax to turn:
import module
module.function()
into something like:
@module.function()
is unlikely to give any such win. Its utility is fairly narrow: it
doesn't encourage any new design patterns. It does save a few characters
of typing, which may be a small win, but the use of this will be a code
smell. Python doesn't require all imports to be at the beginning of your
module, but it is recommended, and this inlining of imports encourages
the anti-pattern of scattering imports all throughout your code base.
Let me put it this way. The suggested syntactic sugar will encourage code
that is functionally the equivalent of this:
import math
math.sin(1.2)
# ...
# much later
import math
math.cos(2.5)
# ...
# much later
import math
math.sqrt(24)
Yes, the subsequent imports are relatively fast, but even so, we
shouldn't *encourage* that sort of thing with special syntax for it.
If you don't like this code pattern:
import function from module
# ...
# much code goes here
# ...
function(x)
then instead of creating new syntax, the conventional solution is the
best:
import module
# ...
# much code goes here
# ...
module.function(x)
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
