PEP: possibility of inline using of a symbol instead of "import"

[Steven D'Aprano]

On Thu, 06 Jan 2011 09:03:02 -0800, Ian wrote:

> On Jan 6, 9:32 am, Tim Harig <user... at 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