Re: [MLUG] guess what

[EMAIL:PROTECTED]

> On Thu, Apr 01, 2004 at 07:42:13PM +0000, EMAIL:PROTECTED 
> wrote:
> >
> > Oh, and did they ever fix the following?
> >
> > i=1
> > def f():
> >   print "i=",i
> >   i = i + 1
> >
> > f()
> >
> > Hint: It does not print "i=2".
> >
> 
> I don't get it.  Why would you expect it to?  If you don't understand
> Python's scoping rules you might expect "i= 1" but whence 2?

I inverted the print and increment lines. Sorry.

> Of course you need to define i as global to see outside the function
> scope.

Why? That goes against every other language definition where functions have
variable name visibility outside their scope /by default/, and any values
explicitly defined within the scope are just that - defined explcitly within the
scope.

If that's such a great idea, why hasn't any other language adopted it in the
30-or-so years we've had high-level programming languages around?

> If this was PHP you would see "i=0" and no error.  Is that the desired
> behaviour?

The point is that there is no indication in the code that there is a syntactic
error. But Python insists that it is a *run-time* error. You can rationalize all
you want about "the programmer should know better". It still doesn't change the
fact that this is clearly a compile-time error that isn't flagged immediately
upon compilation (i.e. after I close off the function).

> One of Python's biggest strengths, to me, is its explicit scoping.  If
> you import library foo, you use functions out of it thusly:
> 
> foo.function(args)

No different than Perl or Java. However, both Perl and Java have syntactical
sugar to eliminate that by providing a default context for name resolution.
Strangely, Perl calls that "exporting" and Java calls it "importing". I don't
see this as some huge "win" for Python over the other languages.

> Python's other strengh is that it avoids needless punctuation like {
> or } or ; at the end of every statement or $ in front of every
> variable.  Of course, this means you need a real editor to work with
> blocks of code

Meaning an editor capable of parsing Python source code. I like my editors to be
useful for other types of text documents, thank you very much. You might as well
be making a case that VisualStudio is a "real" editor for VB, C#, J#, and .NET,
and that all other editors that cannot parse your programming language du jour
source code are somehow not "real" editors.

> for normal people it makes reading and writing the code much easier.

That's exactly how MS sold VisualBasic to those millions of now .NET
programmers. Are you sure you think Python benefits from such a strategy?

As for the argument that Perl is "hard to read" due to the native type
signatures, given your above statement, and compared to the amount of Perl code
around the internet, still in use, doing lots of important things for lots of
people, either there are some very small number of insanely prolific Perl coders
out there, or *gasp* it is easy to read and write Perl code. QED.

> Also, Python has list datatypes nicely integrated into the language.

How are they distinguished syntactically from other native datatypes?
I don't see the difference between the '[]' and '{}' "decorations" for lists and
dictionaries being any different than Perl or Java. There will always be some
syntactical indicators for associative datatypes.

And I don't consider it a beneficial feature of Python to eliminate statement
terminators. Even our written languages have a syntactical end-of-statement
marker. Not having one is unusual, and of questionable benefit.

> Python is easy to develop algorithms on because of its interactive
> command-line.

So what? Every other language has interactive command-line debuggers. Even Java
(BeanShell and Groovy). This is not a unique attribute that Python programmers
enjoy and other language programmers are bereft of. Whether either /avails/
themselves of this feature is another story altogether.

> Maybe because I leaned to program on the Commodore
> (Microsoft Basic V2.0), but the fastest way for me to choose a test
> case, develop something by interacting with the interpreter until I
> get something working, then paste the successful code into my script.

I see. You were using Test-Driven-Development on your Commodore with MS-Basic
V2.0 back in what? 1992 or so? Wow, that's some resume you must have. Maybe you
could teach Ward Cunningham, Bob Martin, or Mike Clark a thing or two, no?

> Even when I need execution speed (e.g. MPEG processing) I prefer to
> develop my algorithm in Python, then convert to C later.

This is simple in Perl as well. Try 'man perlcc'. Or integrate third-party C
libraries into Perl. And then there's the strange beast that is JavaPerl and the
even more magical beast that is the Inline module.

In Perl, with Inline, I don't even *have* to convert it to C. I can *write* it
in C. Inline. No separate compilation and linkage mumbo-jumbo necessary.

See http://search.cpan.org/~ingy/Inline-0.44/Inline.pod for more about Inline.

C++ is OK, too. http://search.cpan.org/~neilw/Inline-CPP-0.25/lib/Inline/CPP.pod

Oh, and some sick bastage has gone and written Inline::Java.
http://search.cpan.org/~patl/Inline-Java-0.47/Java.pod

Not to be outdone, we have Inline::PERL. That's right, you can print the power
of PERL to your perl programs.

http://search.cpan.org/~jmcnamara/Acme-Inline-PERL-0.01/PERL.pm

There's also Inline::Guile and Inline::Octave too.

And last, but not least, there's Inline::Python:

http://search.cpan.org/~neilw/Inline-Python-0.20/Python.pod

There's even a way to write Perl code inline inside your Python programs, which
have been inlined into Perl. :=)

> It's _that_ much easier to debug and try different ways of doing something.

That's funny. Python is about there being only *one* way to do something, the
"right" way, or "Guido's Way", and that giving developers choices is bad. And I
would think more people have said exactly that about *Perl*, not Python. Ever
hear of TIMTOWTDI? (There Is More Than One Way To Do It).

It's practically a mantra for Perl. And a cross to bear from other language
zealots that disparage exactly that freedom - to do what you need to do with the
tools you know how to use. Don't know OO, but you do know C? Write your Perl
programs to look like C code. Use OO exclusively? Write your Perl programs to
look like OO programs. Know poetry? Write your perl programs to be haikus.

   no less can I say;
   require strict, close attention
   while you ... write haiku

-- James Tilley 

http://aspn.activestate.com/ASPN/Perl/Haiku/InPerl

Mike/

---------------------------------------------
http://www.valuenet.net


_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members