Re: PEP: possibility of inline using of a symbol instead of import
On Jan 6, 7:28 am, dmitrey dmitrey.kros...@scipy.org 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.
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].
I actually wouldn't mind this; in fact Python's importing mechanism is
bad enough that a complete overhaul might not be a bad thing.
But, first of all, one can already do in-line imports in Python with
the __import__ built-in function (and I used to do this frequently in
throwaway scripts before list comprehensions were added). For
instance, a one-liner to generate a password would be this:
python -c 'for i in xrange(8):
__import__(sys).stdout.write(__import__(random).choice(__import__(string).letters))'
Today a better way to do it would be like this:
python -c 'import random,string; print
.join(random.choice(string.letters) for i in xrange(8))'
But that's a digression.
The problem with in-line imports is that it can lead to deadlock in
multithreaded programs, so for the most part it's a good idea to avoid
importing within functions.
Therefore, a syntax for it would really be needed to gain full
benefit. This would allow the compiler to scan the file to collect a
list of prerequisite modules. In my mind, the module itself wouldn't
import the dependencies itself, it simply lists prerequisites and
leaves it to the runtime to ensure that they've been imported.
A side benefit to this is to keep module namespaces clean.
Main drawback is that it makes accessing symbols in deepely nested
packages unwieldy (since presumably you'd have to write out the fully-
qualified name). Meh, I pretty much avoid deeply nested packages, and
typically spell out the fully-qualified module names anyway. So not
my problem.
As for listing imports at the top of the program--I can't say I have
much use for it. Sometimes it helps to see a list of prerqequisites
in one place, but I can't say it's the most useful thing ever, and
anyway it's misleading since the imports can become stale. I'd rather
not have to stop and scroll up ten pages to add an import to the top
of the module when I suddenly need to access time.sleep or
itertools.count.
So, pending a better syntax, I'll give it a +0; and the only reason I
don't give it a +1 is it's such a drastic change.
The syntax probably would deserve a lot of thought (being such a
drastic change) but drawing from C++ a postfix operator would seem to
fit.
sys:: - evaulates to the sys module
sys::version - evaluates to sys.version
xml::etree::ElementTree:: - as expected
That has the unfortunate effect of making Python look like C++ though.
Won't ever happen though.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
On Jan 6, 8:32 am, Tim Harig user...@ilthio.net wrote: 2. Your so-called PEP probably clashes with Python's use of @ for decorators. He said it was just for simplicity's sake. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
PEP: possibility of inline using of a symbol instead of import
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
On 2011-01-06, dmitrey dmitrey.kros...@scipy.org 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(...) -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
dmitrey dmitrey.kros...@scipy.org wrote: 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. If you just import the modules at the top of the file then there's nothing to prevent you writing: mm2 = MyModule2 mf3 = MyModule3.myFunc3 without any punctuation to obscure the meaning. 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 Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
Yes, I know, still usually it is placed in file header On Jan 6, 5:57 pm, Tim Harig user...@ilthio.net 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(...) -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
On 2011-01-06, dmitrey dmitrey.kros...@scipy.org wrote: [re-ordered] On Jan 6, 5:57 pm, Tim Harig user...@ilthio.net 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
On Jan 6, 11:02 am, Duncan Booth duncan.bo...@invalid.invalid 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
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]? ;-) Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
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, dev...@deventm.org http://www.global-scaling-institute.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
On Jan 6, 8:43 pm, Erwin Mueller dev...@deventm.org 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, dev...@deventm.orghttp://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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
On 1/6/2011 10:28 AM, 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 ... Personally, I always do all of my imports at the top of every program I write and like it when others do the same. The reason is that, in a single glance, I can see all of the dependencies of the program. For similar reasons of explicit clarity I prefer this construct: import re pat = re.compile(...) To something like this one: from re import compile as cp pat = cp(...) The only benefit I can see from your proposal is that it cuts down slightly on the number of characters in a program, but I think it does so at the cost of reducing explicit clarity and increasing the learning burden for a programmer who will have to learn two techniques (if only so she can read other people's code) instead of one. Also, there are only 95 printable ASCII characters most of which are already dedicated to other uses (e.g., for use in variable names.) I would hate to reserve one to do something that can be done equally well without reserving a character. I applaud your interest in improving the language but I don't think the benefit justifies the cost in this case. Alan -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
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
Re: PEP: possibility of inline using of a symbol instead of import
On Thursday 06 January 2011 21:23:57 Robert Kern wrote: 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. I'm not quite familar with Python development, but why should modules be so big that the user is lost in the code? What is preventing you from splittin a module in several files, each file with a single responsibility? -- Erwin Mueller, erwin.muel...@deventm.org http://www.global-scaling-institute.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
On Thursday 06 January 2011 21:23:57 Robert Kern wrote: 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. I'm not quite familar with Python development, but why should modules be so big that the user is lost in the code? What is preventing you from splittin a module in several files, each file with a single responsibility? -- Erwin Mueller, dev...@deventm.org http://www.global-scaling-institute.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
On Thu, Jan 6, 2011 at 8:00 PM, Erwin Mueller erwin.muel...@deventm.org wrote: On Thursday 06 January 2011 21:23:57 Robert Kern wrote: 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. I'm not quite familar with Python development, but why should modules be so big that the user is lost in the code? They shouldn't, but due to Python's conciseness, the amount of code a module can hold before it becomes unwieldy is a good bit greater than some more verbose languages. Unlike say, Java, it is quite normal to have several classes, functions, and constants in a single Python module. Several pages is not an unreasonable upper bound for a Python module. What is preventing you from splittin a module in several files, each file with a single responsibility? Circular dependencies perhaps. Also, how a responsibility is defined and what level of module granularity is most useful is a design decision requiring skilled judgment; it's possible that just-one-module is appropriate for Dmitrey's situation. Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: possibility of inline using of a symbol instead of import
On Thu, 06 Jan 2011 21:05:10 -0800, Chris Rebert wrote: On Thu, Jan 6, 2011 at 8:00 PM, Erwin Mueller erwin.muel...@deventm.org wrote: On Thursday 06 January 2011 21:23:57 Robert Kern wrote: 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. I'm not quite familar with Python development, but why should modules be so big that the user is lost in the code? They shouldn't, but due to Python's conciseness, the amount of code a module can hold before it becomes unwieldy is a good bit greater than some more verbose languages. Unlike say, Java, it is quite normal to have several classes, functions, and constants in a single Python module. Several pages is not an unreasonable upper bound for a Python module. Have a look at the decimal.py module in the standard library. That's nearly 5800 lines, including blanks, comments and docstrings, for 18 classes and 19 top-level functions, over 88 pages. I'd call that the maximum size I'm comfortable with a single module. Several pages is nothing to fear. I recently split a module I'm working on into a package of seven modules (plus about the same again for tests). My module was about 2500 lines, for about 50 classes and functions, and I expect it to grow by another dozen or so functions over the coming months. Splitting a single module into multiples doesn't happen for free. You have to worry about imports and dependencies that simply aren't an issue in a single module. But on the plus side, I was able to rename a bunch of similar-but-different functions from: module.function module.function1 to a much more sensible: module.function module.submodule.function -- Steven -- http://mail.python.org/mailman/listinfo/python-list
