Very, Very Green Python User

[hanumizzle]

I have used Perl for a long time, but I am something of an experimental
person and mean to try something new. Most of my 'work' with Vector
Linux entails the use of Perl (a bit of a misnomer as it is not now a
paid position -- I am not yet even out of K-12), and there a lot of
things I love about it. I can look past a number of misfeatures in
Perl, but I am surprised to see that Python has very few (that I know
of). Most of them are documented here, it would seem:
http://www.c2.com/cgi/wiki?PythonProblems. Is the Python debugger
fairly stable? The one you get with Perl stinks on ice. More than
anything else, I would like to have a powerful OO environment where I
do not have to worry about the debugger sucking ass.

A couple blemishes I'm concerned about, though:

Python closures are apparently very poor, but from what I can surmise
of the PyGTK2 page, instances of objects are dynamic enough to add new
methods, so you get your callbacks, at least.

Double-underscore methods are rewritten with the class name? That's an
ugly hack, but remember I'm coming from Perl. If the language doesn't
pull many other hijinks, that's OK.

I have plenty of docs and stuff, now I'm just looking for wisdom. As a
seasoned Python user, what do you have to impart?

[Scott David Daniels]

ha********@gmai l.com wrote:

... Is the Python debugger fairly stable? Yes, but it is not massively featured. The "Pythonic" way is to
rarely use a debugger (test first and straightforward code should
lead to "shallow" bugs). Often for most of us judiciously placed
print statements suffice.
The one you get with Perl stinks on ice. More than
anything else, I would like to have a powerful OO environment where I
do not have to worry about the debugger sucking .... Do watch your language on this newsgroup. Lots of people read this
group and there is no good reason to offend them. In turn, you will be
cut some slack.
A couple blemishes I'm concerned about, though:

Python closures are apparently very poor, but from what I can surmise
of the PyGTK2 page, instances of objects are dynamic enough to add new
methods, so you get your callbacks, at least.
What do you mean by "very poor"? Python prefers you to use functions
defined with a suitable name in places other languages provide stronger
lambda expressions, if that's what you mean. Also, there is no easy way
to affect the variables of an encasing function, if that is what you
mean.
Double-underscore methods are rewritten with the class name? That's an
ugly hack, but remember I'm coming from Perl. If the language doesn't
pull many other hijinks, that's OK.
Double-underscore is a strong language convention and warning. Names
both beginning and ending with double-underscore may be "magic" in
that interacting with them affects more behavior than the same code
using a different name. Instance variables with double-underscore as
a leading convention get "mangled" just so that when you are designing
"mixin" classes you can easily choose names that should not collide
with the instance variable names of classes using your "mixin" classes.
I have plenty of docs and stuff, now I'm just looking for wisdom. As a
seasoned Python user, what do you have to impart?

I think if you spend the effort to learn to use Python you'll have a
wonderful experience. Welcome to the newsgroup.
--Scott David Daniels
sc***********@a cm.org

[Fredrik Lundh]

Scott David Daniels wrote:

... Is the Python debugger fairly stable?

Yes, but it is not massively featured. The "Pythonic" way is to
rarely use a debugger (test first and straightforward code should
lead to "shallow" bugs). Often for most of us judiciously placed
print statements suffice.

combined with a modular design, so you can make sure that individual
functions, classes, and modules work as expected before you use them
to build larger stuff...

</F>

[Lonnie Princehouse]

> Python closures are apparently very poor, but from what I can surmise

of the PyGTK2 page, instances of objects are dynamic enough to add new
methods, so you get your callbacks, at least.
It's true that Python's "lambda" is somewhat limited, but this is
rarely a problem because you can define named functions on-the-fly.
Double-underscore methods are rewritten with the class name? That's an ugly hack

Yes, it is. But in practice, you will rarely need to pay attention to
this. I'd been using Python for two years before I noticed this odd
behavior.

I heartily applaud shopping around for new languages. Coming from
Perl, I think you'll find Python to be a figurative breath of fresh
air, but you might also want to look at languages like Ruby, Haskell,
etc.

[Terry Hancock]

On 12 Mar 2006 17:58:43 -0800
ha********@gmai l.com wrote:

Double-underscore methods are rewritten with the class
name? That's an ugly hack, but remember I'm coming from
Perl. If the language doesn't pull many other hijinks,
that's OK.

This is GvR's way of saying "do not use double-underscore
methods". ;-)

You shouldn't ever see the mangled _<classname>__< method>
form, unless you've been very, very naughty.

And if you have been, well, we promise not to tell anybody,
but it's Your Problem [TM].

Seriously, truly private methods are generally not something
you want to mess with in Python. Quite frequently, people
with a C++ or Java background come here and ask for them. A
Frequently Repeated Thread ensues:

0) I want private methods in Python

1) you don't need 'em

2) C++ and Java have 'em and the book says you have to
have 'em, or you aren't doin' OOP

3) total hogwash -- I can use compiler directives to
defeat C++/Java "private" variables anyday, so it
doesn't accomplish anything that isn't easier to
do by putting "__" in front of it to tell the client
programmer not to use it.

Then we all go back to coding.

Cheers and good luck with your project, ;-)
Terry

--
Terry Hancock (ha*****@Anansi Spaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[jalanb]

Scott David Daniels wrote:

ha********@gmai l.com wrote:

> The one you get with Perl stinks on ice. More than
anything else, I would like to have a powerful OO environment where I
do not have to worry about the debugger sucking ....

Do watch your language on this newsgroup. Lots of people read this
group and there is no good reason to offend them. In turn, you will be
cut some slack.

What exactly is your problem with the language used here ?

"Suck" rhymes too closely ?

Are "luck", "ruck", and "puck" offensive too?
And who gets to decide how easily offended "lots of people" are ?

Why do you think *anyone* else is as offended by hanumizzle's language
as others are by your sanctimoniousne ss ?

--
Alan
http://aivipi.blogspot.com

[bruno at modulix]

Scott David Daniels wrote:

ha********@gmai l.com wrote:

... Is the Python debugger fairly stable?

Yes, but it is not massively featured. The "Pythonic" way is to
rarely use a debugger (test first and straightforward code should
lead to "shallow" bugs). Often for most of us judiciously placed
print statements suffice.

Well, the fact is that I haven't used pdb on more than two or three
occasions, and I'm using Python since the 1.5.x.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[bruno at modulix]

ha********@gmai l.com wrote:

I have used Perl for a long time, but I am something of an experimental
person and mean to try something new. Most of my 'work' with Vector
Linux entails the use of Perl (a bit of a misnomer as it is not now a
paid position -- I am not yet even out of K-12), and there a lot of
things I love about it. I can look past a number of misfeatures in
Perl, but I am surprised to see that Python has very few (that I know
of). Most of them are documented here, it would seem:
http://www.c2.com/cgi/wiki?PythonProblems.
Seems that this page is sometimes just plain wrong and somewhat
outdated. Let's see some of them:

1/Memory Management The reference implementation uses reference
counting, the worst-performing memory management scheme there is

Actually, Python uses *both* reference-counting and a garbage collector.

2/ No Ternary If
Well... actually true, but not such a major annoyance.
NB : the "tuple_dispatch " option works well if you know how-to python.
IOW, you can avoid useless evaluation with a simple lambda :

result = (lambda: action_if_true, lambda : action_if_false )[test]()

3/ Dynamic Typing
Err... Actually, this is not a problem, Sir, it's a feature.

4/ Speed
Never been a problem for me so far.

5/ Ugly mechanism for privates
This is *not* a mechanism for "privates". This is a mechanism to protect
some crucial implementation attributes from being *accidentally*
overriden in a child class.

6/ SelfDotSyndrome
As for 3, this is definitively a feature. I've always used the implicit
'this' in Java and C++ anyway.

Is the Python debugger
fairly stable?
can't tell, almost never had a use for it.
More than
anything else, I would like to have a powerful OO environment where I
do not have to worry about the debugger sucking ass.
What makes you think you have such a need for a debugger ?
A couple blemishes I'm concerned about, though:

Python closures are apparently very poor,
In Python, encapsuling state is better done with objects. Once you'll
get a better understanding of Python's object model, you'll find out
that there's not such a need for more powerfull closures (well, that's
MHO at least). Amongst other things, functions and methods are objects,
and any other class can be made callable if you implement a method for
the call operator...
but from what I can surmise
of the PyGTK2 page, instances of objects are dynamic enough to add new
methods, so you get your callbacks, at least.
You don't even need this to use callbacks. Remember, functions and
methods are objects, and other objects can be callable too...
Double-underscore methods are rewritten with the class name? That's an
ugly hack,
Ever looked at what a C++ compiler do to symbols ?-)
but remember I'm coming from Perl.

Talking about ugky hacks... !-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[hanumizzle]

Scott David Daniels wrote:

ha********@gmai l.com wrote:

... Is the Python debugger fairly stable?

Yes, but it is not massively featured. The "Pythonic" way is to
rarely use a debugger (test first and straightforward code should
lead to "shallow" bugs). Often for most of us judiciously placed
print statements suffice.

> The one you get with Perl stinks on ice. More than
anything else, I would like to have a powerful OO environment where I
do not have to worry about the debugger sucking ....

Do watch your language on this newsgroup. Lots of people read this
group and there is no good reason to offend them. In turn, you will be
cut some slack.

As one who avidly studies language, I have observed that the meaning of
a word slip out of its original context through idiomatic usage. If I
had included the implicit object of 'sucks', then you would have more
grounds for complaint. However, 'sucks', used in the intransitive
sense, is no worse than 'bites the bag'.

Think about the word 'mogul'. Like 'oil mogul' or 'software mogul'.
Well, the **Mughals**, whence comes the word, were mass-murderers:

http://www.geocities.com/hindoo_humanist/mughal.html

If you were a Hindu in those times, saying 'oil mogul', would be
equivalent to saying 'oil Stalin' or 'oil Hitler' today. But this isn't
about human rights so much as it is about semantics. (Nobody likes
long-winded, abstract philosophical discussions on a technology NG.)
'Sucks' doesn't mean what it used to, at least how I used it there.

Unless one is willing to investigate the etymology of every word he
uses (like mogul, Christian, or juggernaut), there needs to be a more
lenient attitude towards use of language.

[hanumizzle]

Exactly...this is how most of my Perl modules are written and tested,
actually.