A startup puzzle

[Edward K. Ream]

Re: A startup puzzle

> > I don't want to discuss whether this is good style: it is simple and it[color=blue][color=green]
> > works well for me :-)[/color][/color]
[color=blue]
> Okay, I won't discuss, I'll just tell you that this is a recipe for
> giving yourself a headache.[/color]

I could agree with you if using "from leoGlobals import *" had ever caused
me the slightest ache. Aside from this startup problem, now completely
solved, it never has.

As suggested in another reply, replacing every reference to x in leoGlobals
by g.x might be considered better style, but this is precisely what I want
to avoid. It is always perfectly obvious in the code that a reference to a
"bare" function is a reference to a function in leoGlobals. What could be
clearer?

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo@chart er.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Edward K. Ream]

Re: A startup puzzle

> In short, the following pattern appears like it will work in all my
modules:[color=blue]
>
> from leoGlobals import *
> app = leoProxy() # leoProxy defined in leoGlobals
> # Now the code can reference either app.x or app().x.[/color]

Actually, app = leoProxy() can be done in leoGlobals, so the pattern is
just:

from leoGlobals import *
# Now the code can reference either app.x or app().x.

I have installed the new code in leoGlobals.py and everything "just works".

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo@chart er.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Bengt Richter]

Re: A startup puzzle

On Mon, 29 Sep 2003 23:24:51 GMT, "Steve Holden" <sholden@holden web.com> wrote:
[...][color=blue]
>
>I've followed this thread, and I'm having trouble understanding why nobody's
>suggested using Alex martelli's "borg" pattern, which he originally called a[/color]

I think because (IIUC) the OP wants to import * to avoid naming a container,
and he's willing to live read-only for the resulting bindings (though the
bindings can of course be to mutable things).
[color=blue]
>"statel;ess proxy", where all objects of a given type share the same state
>information. Sounds to me that's what you really want, no?
>[/color]
[color=blue]
>This would mean that in leo_global you would have something like this:
>
>leo_global.p y:
>-------------
>class Borg(object):
> _state = {}
> def __new__(cls, *p, **k):
> self = object.__new__( cls, *p, **k)
> self.__dict__ = cls._state
> return self
>
>
>module1.py
>-------------
>from leo_global import Borg
>
>myborg = Borg()
>myborg.var1 = "This is var 1"
>
>import module2
>
>print "Module 1's borg has var1 =", myborg.var1, id(myborg.var1)
>print "Module 1's borg has var2 =", myborg.var2, id(myborg.var2)
>
>
> module2.py:
>-------------
>from leo_global import Borg
>
>myborg = Borg()
>myborg.var2 = "This is var 2"
>
>print "Module 2's borg has var1 =", myborg.var1, id(myborg.var1)
>print "Module 2's borg has var2 =", myborg.var2, id(myborg.var2)
>
>The result of all this appears to be what you want: a simple way of creating
>an easily-referenced shared state. Vide:
>
>C:\Steve\Proje cts\Python>pyth on module1.py
>Module 2's borg has var1 = This is var 1 7766584
>Module 2's borg has var2 = This is var 2 8008928
>Module 1's borg has var1 = This is var 1 7766584
>Module 1's borg has var2 = This is var 2 8008928
>[/color]
Yes, but UIAM [1]

import leo_global as myborg # leo_global.py being an empty file for this example

instead of

from leo_global import Borg
myborg = Borg()

would let you do what you are showing in the above ;-)

[1] Got a little nervous about that, so I tried it:

=============== =============== =============== ===============
[ 6:43] C:\pywk\clp\leo \SteveHolden>di r leo_global.py
Volume in drive C is System
Volume Serial Number is 14CF-C4B9

Directory of C:\pywk\clp\leo \SteveHolden

03-09-30 06:35 0 leo_global.py
1 File(s) 0 bytes
56,197,120 bytes free

[ 6:43] C:\pywk\clp\leo \SteveHolden>ty pe module1.py
#module1.py
#-------------
#from leo_global import Borg
#
#myborg = Borg()
import leo_global as myborg
myborg.var1 = "This is var 1"

import module2

print "Module 1's borg has var1 =", myborg.var1, id(myborg.var1)
print "Module 1's borg has var2 =", myborg.var2, id(myborg.var2)




[ 6:44] C:\pywk\clp\leo \SteveHolden>ty pe module2.py
# module2.py:
#-------------
#from leo_global import Borg
#
#myborg = Borg()
import leo_global as myborg
myborg.var2 = "This is var 2"

print "Module 2's borg has var1 =", myborg.var1, id(myborg.var1)
print "Module 2's borg has var2 =", myborg.var2, id(myborg.var2)


[ 6:44] C:\pywk\clp\leo \SteveHolden>py thon module1.py
Module 2's borg has var1 = This is var 1 9439256
Module 2's borg has var2 = This is var 2 9439496
Module 1's borg has var1 = This is var 1 9439256
Module 1's borg has var2 = This is var 2 9439496

=============== =============== =============== =============== =============== ======
Regards,
Bengt Richter

[Edward K. Ream]

Re: A startup puzzle

> Okay, I won't discuss, I'll just tell you that this is a recipe for[color=blue]
> giving yourself a headache.[/color]

The more I think about this remark, the more I tend to agree with you. What
I said about not having trouble with "from leoGlobals import *" is true, and
yet...

The problem isn't so much the present namespace pollution, the problem is
that the technique doesn't extend well. There comes a point at which there
are just too many names to keep track of. So if I were managing a group of
programmers (thank goodness I'm not :-) I would tend to disapprove of what I
have done.

Still, I don't see a perfect alternative. For sure I wouldn't like to put a
g. in front of hundreds or thousands of function calls. I suppose that this
is the kind of thing one would be forced to do in slightly larger
projects...Any other ideas?

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo@chart er.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Peter Hansen]

Re: A startup puzzle

"Edward K. Ream" wrote:[color=blue]
>[color=green]
> > Okay, I won't discuss, I'll just tell you that this is a recipe for
> > giving yourself a headache.[/color]
>
> The more I think about this remark, the more I tend to agree with you. What
> I said about not having trouble with "from leoGlobals import *" is true, and
> yet...
>
> The problem isn't so much the present namespace pollution, the problem is
> that the technique doesn't extend well. There comes a point at which there
> are just too many names to keep track of. So if I were managing a group of
> programmers (thank goodness I'm not :-) I would tend to disapprove of what I
> have done.
>
> Still, I don't see a perfect alternative. For sure I wouldn't like to put a
> g. in front of hundreds or thousands of function calls. I suppose that this
> is the kind of thing one would be forced to do in slightly larger
> projects...Any other ideas?[/color]

The wxPython project recently switched from using "from wx.wxPython import *"
to a nice simple "import wx" at the top. All calls and constants are now of
course prefixed with "wx." where before they were unadorned.

The change seems identical to what you are proposing, and we can probably
assume it was done for very good reasons. The resulting code, after I've
made changes to my own, already seems more readable. I encourage you to
make the same switch.

-Peter

[Erik Max Francis]

Re: A startup puzzle

"Edward K. Ream" wrote:
[color=blue]
> I could agree with you if using "from leoGlobals import *" had ever
> caused
> me the slightest ache. Aside from this startup problem, now
> completely
> solved, it never has.[/color]

Anyone else detect a whiff of irony? "It's never caused me a problem!
Well, except for the problem I just had, but that doesn't count."

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Love is the selfishness of two persons.
\__/ Antoine de la Salle

[John J. Lee]

Re: A startup puzzle

"Edward K. Ream" <edreamleo@char ter.net> writes:[color=blue]
> The problem isn't so much the present namespace pollution, the problem is
> that the technique doesn't extend well. There comes a point at which there
> are just too many names to keep track of. So if I were managing a group of[/color]
[...]

Um, that *is* a form of namespace pollution, isn't it, Edward?

[color=blue]
> Still, I don't see a perfect alternative. For sure I wouldn't like to put a
> g. in front of hundreds or thousands of function calls. I suppose that this
> is the kind of thing one would be forced to do in slightly larger
> projects...Any other ideas?[/color]

Qt names everything with an initial Q (QWidget, QObject, QLineEdit,
....), so from qt import * with PyQt works very well. Only one saved
character, I know, and it doesn't help you given that you've already
named everything without such a convention...


John

[Albert Hofkamp]

Re: A startup puzzle

On Thu, 2 Oct 2003 10:59:06 -0500, Edward K. Ream <edreamleo@char ter.net> wrote:[color=blue][color=green]
>> Okay, I won't discuss, I'll just tell you that this is a recipe for
>> giving yourself a headache.[/color]
>
> The more I think about this remark, the more I tend to agree with you. What
> I said about not having trouble with "from leoGlobals import *" is true, and
> yet...
>
> The problem isn't so much the present namespace pollution, the problem is
> that the technique doesn't extend well. There comes a point at which there
> are just too many names to keep track of. So if I were managing a group of
> programmers (thank goodness I'm not :-) I would tend to disapprove of what I
> have done.
>
> Still, I don't see a perfect alternative. For sure I wouldn't like to put a
> g. in front of hundreds or thousands of function calls. I suppose that this[/color]

Afterwards, yes I agree, it is not fun to do. The lesson is thus don't
get there :-)

While writing code I don't see why adding a module-prefix is a problem,
I do that as standard coding practice. In my experience, typing is not
the problem, the design of the code, and reading code afterwards (by
others!) is the real problem.

I think the benefits of prefixing with module-names are:
- I will NEVER have to search for duplicate function-names imported from
different modules (this alone is reason enough for me, if I can
prevent this search once, I have already saved more time than I have
spent typing a few characters extra).
- In my mind, I don't have a very large collection of function names
without ordering, I have a collection of modules, and within modules a
collection of function names, ie in my mind, I use the module structure.
This is a better scalable structure for remembering functions and what
they do.
- The module name helps understanding what the code is doing.
ie timer.start() is much more helpful than start()
- I have a clear seperation between function calls to my own code and
other people's code, ie the system/module boundaries are very clearly
visible.

However, if you think these benefits do not exist, or are too small,
then by all means, use the "from .... import *" form.


Albert
--
Unlike popular belief, the .doc format is not an open publically available format.

[Aahz]

Re: A startup puzzle

In article <vnoiqbjg3hhrc8 @corp.supernews .com>,
Edward K. Ream <edreamleo@char ter.net> wrote:[color=blue]
>
>Still, I don't see a perfect alternative. For sure I wouldn't like
>to put a g. in front of hundreds or thousands of function calls. I
>suppose that this is the kind of thing one would be forced to do in
>slightly larger projects...Any other ideas?[/color]

Note that it is certainly reasonable to do this:

def foo():
dialog = g.dialog
d1 = dialog()
d2 = dialog()
d3 = dialog()
d4 = dialog()

OTOH, it's a Bad Idea to do this:

def bar():
dialog = g.dialog
d = dialog()

There's plenty of wiggle room for judgement calls of elision while still
keeping the purity of the namespace.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan