ipy %run noob confusion

2013-10-03 Thread jshrager
I have some rather complex code that works perfectly well if I paste it in by 
hand to ipython, but if I use %run it can't find some of the libraries, but 
others it can. The confusion seems to have to do with mathplotlib. I get it in 
stream by:

   %pylab osx

and do a bunch of stuff interactively that works just fine, for example:

  clf()

But I want it to run on a %run, but %pylab is (apparently) not allowed from a 
%run script, and importing matplotlib explicitly doesn't work...I mean, it 
imports, but then clf() is only defined in the module, not interactively. 

More confusing, if I do all the setup interactively, and the try to just run my 
script, again, clf() [etc] don't work (don't appear to exist), even though I 
can do them interactively. 

There seems to be some sort of scoping problem ... or, put more correctly, my 
problem is that I don't seem to understand the scoping, like, are %run eval'ed 
in some closed context that doesn't work the same way as ipython interactive? 
Is there any way to really do what I mean, which is: Please just read in 
commands from that script (short of getting out and passing my script through 
stdin to ipython?)

Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: (non)compositionality

2006-05-07 Thread JShrager
> There are *NO* semantic advantages for named vs unnamed functions in Python.

I feel that this conversation has glanced off the point. Let me try a
new approach:

There is the Pythonic way (whatever that is), and then The Lisp Way. I
don't know what the former is, but it has something to do with
indentation, and the (meaningless to me*) phrase "It fits your mind."
The Lisp way is quite specific: Pure Compositionality. Compositionality
encompasses and defines all aspects of Lisp, from the parens to
functional style to fundamental recursion to lambda, and even the
language itself is classically composed from the bottom up, and
compositionality enables us to create new complete languages nearly
trivially.

How this concept plays into the current conversation is not subtle:
LAMBDA forms server to directly modify the forms in which they appear.
SORT is the example that comes to mind for me. If one says: (sort ...
#'(lambda (a b) ...)) [I realize that the #' is optional, I use it here
for emphasis that there is a function being formed.] the lambda form
composes, with sort, a new type of sort -- a sort of type . Thus, the semantics of this form are localized
to the sort expression, and do not leave it -- they are, indeed,
conceptually a part of the sort expression, and to require it/them to
be moved outside and given a name breaks the conceptual
compositionality -- that is, the compositional locality of the form.

Similarly, parens and the functional fact that every form returns a
value provide compositional locality and, perhaps more importantly in
practice, compositional *mobility* -- so that, pretty much anywhere in
Lisp where you need an argument, you can pick up a form and drop it in.
[Macros often break this principle, I'll get to those in a moment.]
This is something that no other language (except some dead ones, like
APL) were able to do, and these provide incredible conceptual
flexibility -- again, I'll use the term "mobility" -- one can, in most
cases, literally move code as though it were a closed concept to
anywhere that that concept is needed.

Macros, as I have said, bear a complex relationship to this concept of
composition mobility and flexibility. The iteration macro, demonstrated
elsewhere in this thread, is an excellent example.  But macros are more
subtly related to compositionality, and to the present specific
question, because, as you yourself said: All you need to do is make up
a name that isn't usedBut how is one to find a name that isn't used
if one has macros? [Actually, in Lisp, even if we didn't have lambda we
could do this by code walking, but I'll leave that aside, because
Python can't do that, nor can it do macros.]

I do not hesitate to predict that Python will someday sooner than later
recognize the value of compositional flexibility and mobility, and that
it will struggle against parentheses and lambdas, but that in the end
it will become Lisp again. They all do, or die.

===

[*] BA - Biographical Annotation: Yeah, I've programmed all those
things too for years and years and years. I also have a PhD in
cognitive psychology from CMU, where I worked on how people learn
complex skills, and specifically programming. When I say that "fits
your brain" is meaningless to me, I mean that in a technical sense:
If it had any meaning, I, of all people, would know what it means;
meaning that I know that it doesn't mean anything at all.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: "Only one obvious way..."

2006-05-07 Thread JShrager
>If I ever _DO_ find a language that *DOES* mercilessly refactor in pursuit
> of the ideal "only one obvious way", I may well jump ship, since my faith in
> Python's adherence to this principle which I cherish so intensely has
> been so badly broken ...

The phrase "only one obvious way..." is nearly the most absurd
marketing bullshit I have ever heard; topped only by "it fits your
brain". Why are so many clearly intelligent and apparently
self-respecting hard-core software engineers repeating this kind of
claptrap? It sounds more like a religious cult than a programming
language community. If one of my students answered the question: "Why
use X for Y?" with "X fits your brain." or "There's only one obvious
way to do Y in X." I'd laugh out loud before failing them.

-- 
http://mail.python.org/mailman/listinfo/python-list