«

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

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

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,
http://www.global-scaling-institute.de/

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,
http://www.global-scaling-institute.de/

On Thu, Jan 6, 2011 at 8:00 PM, Erwin Mueller <> 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

On Thu, 06 Jan 2011 21:05:10 -0800, Chris Rebert wrote:

> On Thu, Jan 6, 2011 at 8:00 PM, Erwin Mueller
> <> 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

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(:
__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()'

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

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