Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > PEP: possibility of inline using of a symbol instead of "import"

Reply
Thread Tools

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

 
 
dmitrey
Guest
Posts: n/a
 
      01-06-2011
hi all,
I have th PEP (I'm not sure something like that hadn't been proposed
although):
very often in a Python file header the following lines are present,
like:
from MyModule1 import myFunc1
import MyModule2 as mm2
from MyModule3 import myFunc3 as mf3
etc

and after several pages of code they are using somewhere, maybe only
one time, e.g.
r1 = myFunc1(...)
r2 = mm2.myFunc2(...)
r3 = mf3(...)
It makes programs less clear, you have to scroll several pages of code
in IDE to understand what it refers to.

I propose to add possibility of using a symbol instead (for simplicity
I use @ here, that is already reserved for decorators, thus it should
be other symbol, maybe from Unicode although for simplicity to type it
I would prefer something ordinary like $ or ` or !).

e.g. instead of

import MyModule
(...lots of code...)
r = MyModule.myFunc(...)

someone could just type in the single place

r = @MyModule.myFunc(...)

Also, "import MyModule2 as mm2" could be replaced to mere
mm2 = @MyModule2
and "from MyModule3 import myFunc3 as mf3" could be replaced to mere
"mf3 = @MyModule3.myFunc3".

As for __import__(ModuleTextName), it could be replaced to something
like @(ModuleTextName) or @{ModuleTextName} or @[ModuleTextName].

Regards, D.
 
Reply With Quote
 
 
 
 
Tim Harig
Guest
Posts: n/a
 
      01-06-2011
On 2011-01-06, dmitrey <(E-Mail Removed)> wrote:
> and after several pages of code they are using somewhere, maybe only
> one time, e.g.

[SNIP]
> It makes programs less clear, you have to scroll several pages of code
> in IDE to understand what it refers to.


Python doesn't require imports to be at the top of a file. They can be
imported at any time.

> import MyModule
> (...lots of code...)
> r = MyModule.myFunc(...)


(...lots of code...)
import MyModule
r = MyModule.myFunc(...)
 
Reply With Quote
 
 
 
 
dmitrey
Guest
Posts: n/a
 
      01-06-2011
Yes, I know, still usually it is placed in file header
On Jan 6, 5:57*pm, Tim Harig <(E-Mail Removed)> wrote:

> Python doesn't require imports to be at the top of a file. *They can be
> imported at any time.
>
> > import MyModule
> > (...lots of code...)
> > r = MyModule.myFunc(...)

>
> (...lots of code...)
> import MyModule
> r = MyModule.myFunc(...)


 
Reply With Quote
 
Tim Harig
Guest
Posts: n/a
 
      01-06-2011
On 2011-01-06, dmitrey <(E-Mail Removed)> wrote:
[re-ordered]
> On Jan 6, 5:57*pm, Tim Harig <(E-Mail Removed)> wrote:
>> Python doesn't require imports to be at the top of a file. *They can be
>> imported at any time.
>>
>> > import MyModule
>> > (...lots of code...)
>> > r = MyModule.myFunc(...)

>>
>> (...lots of code...)
>> import MyModule
>> r = MyModule.myFunc(...)

>
> Yes, I know, still usually it is placed in file header


1. Don't top post.

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?
 
Reply With Quote
 
Mike Kent
Guest
Posts: n/a
 
      01-06-2011
On Jan 6, 11:02*am, Duncan Booth <(E-Mail Removed)> wrote:

> Your complaint seems to be that:
>
> * *r1 = myFunc1(...)
>
> is unclear when you don't know where myfunc1 originates, so why don't
> you write:
>
> * *r1 = MyModule1.myFunc1(...)
>
> --
> Duncan Boothhttp://kupuguy.blogspot.com


My interpretation of his proposal is a bit different. I thought he
meant that '@MyModule.myFunc' (yes, using '@' here is bad, but for
conversation sake...) would cause MyModule to be imported if this was
the first time '@MyModule' was encountered in the current module.
Sort of an implied 'import MyModule', which would eliminate the need
to actually use the explicit import.

My reaction to his proposal is 'Meh.' Explicit is better than
implicit. Python is not Perl.
 
Reply With Quote
 
Ian
Guest
Posts: n/a
 
      01-06-2011
On Jan 6, 9:32*am, Tim Harig <(E-Mail Removed)> 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]?"

Cheers,
Ian
 
Reply With Quote
 
Tim Chase
Guest
Posts: n/a
 
      01-06-2011
On 01/06/2011 10:32 AM, Tim Harig 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?


Just as a side note, decorators (your #2, and an approved PEP) do
exactly what you mention in #3, as

@my_decorator
def my_func(...): pass

could just as well be written as

def my_func(...): pass
my_func = my_decorator(my_func)

so you #3 point is counterargued by your #2 point :-/

So the powers-that-be have certainly deemed *some* level of
syntactic sugar worthwhile.

That said, I'm -1 (okay, -0.5) on the OP's suggestion, both in
terms of the syntax clashing with decorators, and the need for
syntactic sugar in this case.

-tkc



 
Reply With Quote
 
Erwin Mueller
Guest
Posts: n/a
 
      01-06-2011
On Thursday 06 January 2011 16:28:49 dmitrey wrote:
> hi all,
> I have th PEP (I'm not sure something like that hadn't been proposed
> although):
> very often in a Python file header the following lines are present,
> like:
> from MyModule1 import myFunc1
> import MyModule2 as mm2
> from MyModule3 import myFunc3 as mf3
> etc
>
> and after several pages of code they are using somewhere, maybe only
> one time, e.g.
> r1 = myFunc1(...)
> r2 = mm2.myFunc2(...)
> r3 = mf3(...)
> It makes programs less clear, you have to scroll several pages of code
> in IDE to understand what it refers to.
>
> Regards, D.


Why you have several pages of code in the first place? Don't you know that you
can split your code in files? Just a suggestion.

--
Erwin Mueller, http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.global-scaling-institute.de/
 
Reply With Quote
 
dmitrey
Guest
Posts: n/a
 
      01-06-2011
On Jan 6, 8:43*pm, Erwin Mueller <(E-Mail Removed)> wrote:
>
> Why you have several pages of code in the first place? Don't you know that you
> can split your code in files? Just a suggestion.
>
> --
> Erwin Mueller, (E-Mail Removed)://www.global-scaling-institute.de/


Erwin, take a look at Python language developers source code and see
how many files have *tens* of pages. Or any other mature soft, e.g.
numpy or scipy.
Also, possibility of splitting *my* files doesn't matter I can split
other files I deal with, e.g. written by other programmers.
D.
 
Reply With Quote
 
Robert Kern
Guest
Posts: n/a
 
      01-06-2011
On 1/6/11 12:43 PM, Erwin Mueller wrote:
> On Thursday 06 January 2011 16:28:49 dmitrey wrote:
>> hi all,
>> I have th PEP (I'm not sure something like that hadn't been proposed
>> although):
>> very often in a Python file header the following lines are present,
>> like:
>> from MyModule1 import myFunc1
>> import MyModule2 as mm2
>> from MyModule3 import myFunc3 as mf3
>> etc
>>
>> and after several pages of code they are using somewhere, maybe only
>> one time, e.g.
>> r1 = myFunc1(...)
>> r2 = mm2.myFunc2(...)
>> r3 = mf3(...)
>> It makes programs less clear, you have to scroll several pages of code
>> in IDE to understand what it refers to.
>>
>> Regards, D.

>
> Why you have several pages of code in the first place? Don't you know that you
> can split your code in files? Just a suggestion.


Modules *should* have several pages of code. *Functions* should be limited to
about a page of code at maximum.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(Encryption Package) error: cannot find symbol symbol: class BaseNCode clusardi2k@aol.com Java 6 08-29-2012 08:33 PM
Why ":symbol" failed but 'symbol' successed with JRuby 1.0.3? Song Ma Ruby 2 07-20-2008 04:08 AM
Possibility using win32ole? gregarican Ruby 5 07-08-2005 04:02 PM
what's differnece between #ifdef symbol and #if defined(symbol) baumann@pan C Programming 1 04-15-2005 08:25 AM
Re: Dynamic Configuration Possibility in Modelsim ? Allan Herriman VHDL 4 08-29-2003 10:33 AM



Advertisments