type checking

[Alex Martelli]

Ah - I think I've just had one of those subtle but important paradigm
shifts. Resource management (for resources other than memory) simply
rests on slightly different language mechanisms in Python and Java
than it does in C++.

Yes, this is a good way to put it, I think.

Oddly enough, I think my Python code has reflected this for some time
without me noticing the issue.

Interesting indeed! This kind of "you're smarter than you know" effect
IS observed time and again, admittedly...


Alex

 

[Cameron Laird]

Stephen Horne wrote: .
.
.

Interesting indeed! This kind of "you're smarter than you know" effect
IS observed time and again, admittedly...


Alex

The aptness of jokes about Guido's time-machine hints at
real quality in the language. More often than not, or
more often than with other languages, Python seems to
treat ignorance gently. This is a dimension of craftsman-
ship: to do the right thing, degrees of freedom remain.

Python Does It Right. No, better than that, Python makes
it easy to do it right.

 

[Anand Pillai]

I was not exagerrating when I wrote it. I find python one of the
most 'expressive' languages out there among the crop of higher-level
languages like Perl, Tcl, Ruby etc. It kind of tends to be very
intuitive and the code follows your brain pretty well. Recently
in the wing IDE mailing list there was a suggestion of the slogan
"Python - Fits Your Brain" with many threads. It really does fit
the brain, and I find no exaggeration in the slogan, not even a bit.

For someone who is still coding C++ for a living, I find the hobby
stuff I do in python to be pretty soothing for my brain. I dont
use any debugger, never once so far, and I find the occasional
'print' statements sprinkled here and there is more than enough.

I am not trying to impress anyone. Give me a problem and I can
lay a wager I can do it in python and deliver you the beta code in
two weeks. Let that be a fresh problem btw. Give me another two
weeks and I can deliver you commercial quality code without using
a debugger.

Try me.

-Anand

 

[Stephen Horne]

I am not trying to impress anyone. Give me a problem and I can
lay a wager I can do it in python and deliver you the beta code in
two weeks. Let that be a fresh problem btw. Give me another two
weeks and I can deliver you commercial quality code without using
a debugger.

Try me.

OK - how about the Turing test?

Ah - I see - that's not a fresh problem, having been proposed some 50
years ago ;-)


Some problems are complex in any language.

 

[Alexander Schmolck]

I'm a Python newbie. I have been using c++ for 5 years and before that I was
programming in Pascal. The one thing that annoys me about python is dynamic
typing because I find myself making typographical errors of the sort that
would under C++ be picked up by the compiler at compiler time. With Python I
have to wait for the error to appear at runtime in order for me to correct
it. I find this inefficient. Any advice about how to get around this would
be appreciated.

Try C-cC-w in emacs.

'as

 

[Carlo v. Dango]

I am not trying to impress anyone. Give me a problem and I can

lay a wager I can do it in python and deliver you the beta code in
two weeks. Let that be a fresh problem btw. Give me another two
weeks and I can deliver you commercial quality code without using
a debugger.
Try me.

-Anand

please show me a solution where pythons inner class instances has an
'outer scope' where it can access the fields and methods of its outer
class instance. Similar to inner classes in java, and similarly to methods
inside methods in python..


-carlo

 

[Alex Martelli]

please show me a solution where pythons inner class instances has an
'outer scope' where it can access the fields and methods of its outer
class instance. Similar to inner classes in java, and similarly to methods
inside methods in python..

It seems to me you keep confusing ACCESS with RE-BIND.

"methods inside methods", in Python, cannot re-bind variables in the
outer scope. If you really want to be similar to THAT, it's trivial:
having just __getattr__ and no __setattr__ at all should suffice.

If what you want is something extremely intricate and non-obvious
such as:

in the inner classe, self.x = y means self.outer.x = y IF it
so happens that self.outer had an attribute x already defined
at that specific point in time; but it changes meaning to a
normal self.x = y if self.outer did NOT have that attribute
at that precise instant

(which may be a caricature of how somebody, who just doesn't get
the _dynamic_ nature of binding and attributes in Python, and is
dead set on kludging up something that would only make sense if
that nature was static instead, might "reason"), that' easy:

def __setattr__(self, name, value):
if hasattr(self.outer, name): setattr(self.outer, name, value)
else: object.__setattr__(self, name, value)

(and use object.__setattr__(self, 'outer', outer) in __init__ --
also inherit your inner class from object, obviously).

The problem is not how to implement ANY precise specification:
it's coming up with a specification of what exactly you want to
happen, that makes sense and provides SOME usefulness within the
rest of how Python works. I can't see the above spec and its
implementation meeting this common-sense test (but then, I cannot
see any spec that vaguely resembles any of your several descriptions
of what you want that does it, either).

E.g., say the two objects are outer and inner, with inner delegating
to outer as above. With the above specs:

inner.x = 23 # say outer has no x attribute at this instant
outer.x = 45 # but now of course it has acquired it
inner.x = 67 # and so THIS assignment delegates

now a "print inner.x, outer.x" would print 23, 67 -- the inner.x
remains "stuck" at the last value you assigned for it BEFORE
outer.x sprung into existence, any further assignment to inner.x
affects outer.x instead. A "del outer.x" would suddenly make
further assignments to inner.x sensible again (until something
else assigns to outer.x, when assignments to inner.x become crazy
again, as per specs).

There may be application usefulness in this behavior, maybe, but
if so I'm definitely failing to SEE it...


Alex