Patrick Thomson wrote:
I personally don't like wxPython because the way it works is very
counter intuitive for me and appear to me somehow non-Pythonic
While Claudio has a point (wxPython is a C++ library at heart), I
believe that wxPython is the best solution for Python GUI's out there.
TK
Patrick Thomson:
After all, GvR said that
wxPython is the best and most mature cross-platform GUI toolkit,
given a number of constraints. The only reason wxPython isn't the
standard Python GUI toolkit is that Tkinter was there first.
The Wax toolkit (http://zephyrfalcon.org/labs/wax.html)
Claudio Grondi ha scritto:
(megasnip)
I caught your point of view. I start reading a book on wxpython to
understand if it can help to solve my problems. At the same time I will
port my program to Python/Tk in order to have a faster first beta
release.
Thanks for your explanation.
Filippo
--
filippo wrote:
Hello,
I coded my +10k lines app using Perl/Tk. It is something like a hotel
software manager, it has a bunch of windows to manage the arrivals,
bills etc etc. I want to port this on Python/WxPython but I'd like to
get benefit of python, not just doing a row by row raw
I personally don't like wxPython because the way it works is very
counter intuitive for me and appear to me somehow non-Pythonic
While Claudio has a point (wxPython is a C++ library at heart), I
believe that wxPython is the best solution for Python GUI's out there.
TK may be a lot easier, but
filippo wrote:
Claudio Grondi ha scritto:
(megasnip)
I caught your point of view. I start reading a book on wxpython to
understand if it can help to solve my problems. At the same time I will
port my program to Python/Tk in order to have a faster first beta
release.
Thanks for your
Hello,
I coded my +10k lines app using Perl/Tk. It is something like a hotel
software manager, it has a bunch of windows to manage the arrivals,
bills etc etc. I want to port this on Python/WxPython but I'd like to
get benefit of python, not just doing a row by row raw porting.
My problem is
filippo wrote:
I coded my +10k lines app using Perl/Tk. It is something like a hotel
software manager, it has a bunch of windows to manage the arrivals,
bills etc etc. I want to port this on Python/WxPython but I'd like to
get benefit of python, not just doing a row by row raw porting.
My
filippo wrote:
Hello,
I coded my +10k lines app using Perl/Tk. It is something like a hotel
software manager, it has a bunch of windows to manage the arrivals,
bills etc etc. I want to port this on Python/WxPython but I'd like to
get benefit of python, not just doing a row by row raw
thanks Fredrik and Claudio,
probably structured coding paradigm is what I need. Claudio, could you
explain better your sentence below?
Claudio Grondi ha scritto:
Python/Tk for it in order to avoid programming in wxPython if not really
necessary (wxPython has its strengths with growing project
Fredrik Lundh ha scritto:
How many do you need ? ;-)
(snip)
thanks Fredrik,
I know there are plenty of tutorials and manuals. I know what classes,
inheritance and polymorphism are. My problem is that I cannot figure
out how they can help me in my practical problem (my software). The
only things
filippo schrieb:
thanks Fredrik and Claudio,
probably structured coding paradigm is what I need. Claudio, could you
explain better your sentence below?
Claudio Grondi ha scritto:
Python/Tk for it in order to avoid programming in wxPython if not really
necessary (wxPython has its
Diez B. Roggisch ha scritto:
I've been doing an online hotel reservation system, btw, and I assure
you: OO was very helpful, even in its crappy PHP incarnation.
thanks Diez,
I'll keep trying OO paradigm. Probably the advantages will be clearer
to me porting to python my app.
Best regards,
filippo wrote:
thanks Fredrik and Claudio,
probably structured coding paradigm is what I need. Claudio, could you
explain better your sentence below?
Claudio Grondi ha scritto:
Python/Tk for it in order to avoid programming in wxPython if not really
necessary (wxPython has its strengths
Matthias Kaeppler wrote:
Hi,
sorry for my ignorance, but after reading the Python tutorial on
python.org, I'm sort of, well surprised about the lack of OOP
capabilities in python. Honestly, I don't even see the point at all of
how OO actually works in Python.
For one, is there any
Op 2005-12-14, Christopher Subich schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Suppose we would add type declarations in python.
So we could do things like
int: a
object: b
Some people seem to think that this would introduce static
typing, but the only effect those staments need
Op 2005-12-14, Magnus Lycka schreef [EMAIL PROTECTED]:
Christopher Subich wrote:
Doesn't work; duck typing is emphatically not subclass-typing. For this
system to still work and be as general as Python is now (without having
to make all variables 'object's), we'd need true interface
Antoon Pardon wrote:
Op 2005-12-14, Christopher Subich schreef
Doesn't work; duck typing is emphatically not subclass-typing.
I don't see how that is relevant.
For this
system to still work and be as general as Python is now (without having
to make all variables 'object's),
But the
Op 2005-12-15, Ben Sizer schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-12-14, Christopher Subich schreef
Doesn't work; duck typing is emphatically not subclass-typing.
I don't see how that is relevant.
For this
system to still work and be as general as Python is now (without
Antoon Pardon wrote:
Op 2005-12-15, Ben Sizer schreef [EMAIL PROTECTED]:
So? I answered a question. That my answer is not usefull for
a specific purpose is very well prosible but is AFAIC irrelevant.
The point being made was that your declarations such as these:
int: a
object: b
would
Op 2005-12-15, Ben Sizer schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-12-15, Ben Sizer schreef [EMAIL PROTECTED]:
So? I answered a question. That my answer is not usefull for
a specific purpose is very well prosible but is AFAIC irrelevant.
The point being made was that your
In article [EMAIL PROTECTED],
Alex Martelli [EMAIL PROTECTED] wrote:
Right, you can get good genericity with Haskell's typeclasses (I've
posted about that often in the past, and desperately and so far
unsuccessfully tried to convince Guido to use something close to
typeclasses rather than
[EMAIL PROTECTED] wrote:
...
[protocol adaptation]); it's the state of _templates_ in Haskell,
specifically, which I was rather dubious about (it may be that I just
haven't dug into them deep enough yet, but they do seem not a little
convoluted to me, so far).
Yup, the templates is
sorry for my ignorance, but after reading the Python tutorial on
python.org, I'm sort of, well surprised about the lack of OOP
capabilities in python. Honestly, I don't even see the point at all of
how OO actually works in Python.
For one, is there any good reason why I should ever inherit
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Aahz)
wrote:
In article [EMAIL PROTECTED],
Alex Martelli [EMAIL PROTECTED] wrote:
Right, you can get good genericity with Haskell's typeclasses (I've
posted about that often in the past, and desperately and so far
unsuccessfully tried to
[EMAIL PROTECTED] wrote:
Magnus Lycka wrote:
The static typing means that you either have to make several
implementations of many algorithms, or you need to work with
those convoluted templates that were added to the language as
an afterthought.
I don't see this in Haskell.
No, I was
Magnus Lycka wrote:
I don't really know Haskell, so I can't really compare it
to Python. A smarter compiler can certainly infer types from
the code and assemble several implementations of an
algorithm, but unless I'm confused, this makes it difficult
to do the kind of dynamic linking / late
[EMAIL PROTECTED] wrote:
Magnus Lycka wrote:
I don't really know Haskell, so I can't really compare it
to Python. A smarter compiler can certainly infer types from
the code and assemble several implementations of an
algorithm, but unless I'm confused, this makes it difficult
to do the kind of
Magnus Lycka wrote:
[EMAIL PROTECTED] wrote:
Magnus Lycka wrote:
I don't really know Haskell, so I can't really compare it
to Python. A smarter compiler can certainly infer types from
the code and assemble several implementations of an
algorithm, but unless I'm confused, this makes it
Magnus Lycka wrote:
Assume that you didn't use Python, but rather something with
static typing. How could you make a module such as my_module.py,
which is capable of working with any type that supports some
standard copy functionality and the +-operator?
The following is a very short Haskell
Op 2005-12-14, Magnus Lycka schreef [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
Magnus Lycka wrote:
I don't really know Haskell, so I can't really compare it
to Python. A smarter compiler can certainly infer types from
the code and assemble several implementations of an
algorithm, but unless
Antoon Pardon wrote:
Suppose we would add type declarations in python.
So we could do things like
int: a
object: b
Some people seem to think that this would introduce static
typing, but the only effect those staments need to have
is that each time a variable is rebound an assert
Christopher Subich wrote:
Doesn't work; duck typing is emphatically not subclass-typing. For this
system to still work and be as general as Python is now (without having
to make all variables 'object's), we'd need true interface checking.
That is, we'd have to be able to say:
implements
Magnus Lycka [EMAIL PROTECTED] writes:
Huh? I must have expressed my thoughts badly. This is trivial to
use in Python. You could for instance write a module like this:
### my_module.py ###
import copy
def sum(*args):
result = copy.copy(args[0])
for arg in args[1:]:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Magnus Lycka wrote:
Assume that you didn't use Python, but rather something with
static typing. How could you make a module such as my_module.py,
which is capable of working with any type that supports some
standard copy
Donn Cave wrote:
Really, this kind of abstraction of data types is not only well
supported in Haskell, it can be almost a curse, at least for
someone like myself who has fairly superficial experience with
this kind of programming. After all the functions have been
zealously scrubbed clean
[EMAIL PROTECTED] wrote:
those convoluted templates that were added to the language as
an afterthought.
I don't see this in Haskell.
Well, historically templates HAVE been added to Haskell as an
afterthought (well after the rest of the language was done), and
judging mostly from
Alex Martelli wrote:
[EMAIL PROTECTED] wrote:
those convoluted templates that were added to the language as
an afterthought.
I don't see this in Haskell.
Well, historically templates HAVE been added to Haskell as an
afterthought (well after the rest of the language was done), and
[EMAIL PROTECTED] wrote:
Alex Martelli wrote:
[EMAIL PROTECTED] wrote:
those convoluted templates that were added to the language as
an afterthought.
I don't see this in Haskell.
Well, historically templates HAVE been added to Haskell as an
afterthought (well after the rest
Alex Martelli wrote:
[EMAIL PROTECTED] wrote:
Alex Martelli wrote:
[EMAIL PROTECTED] wrote:
those convoluted templates that were added to the language as
an afterthought.
I don't see this in Haskell.
Well, historically templates HAVE been added to Haskell as an
Welcome to Python Matthias. I hope you will enjoy it!
Matthias Kaeppler wrote:
Another thing which is really bugging me about this whole dynamically
typing thing is that it seems very error prone to me:
foo = some string!
# ...
if (something_fubar):
fo = another string
Oops,
Magnus Lycka wrote:
The static typing means that you either have to make several
implementations of many algorithms, or you need to work with
those convoluted templates that were added to the language as
an afterthought.
I don't see this in Haskell.
While feature-by-feature comparisions of
Mike Meyer wrote:
Bruno Desthuilliers [EMAIL PROTECTED] writes:
^^ There is no functionality to check if a subclass correctly
implements an inherited interface
I don't know of any language that provide such a thing. At least for
my definition of correctly.
Well, since your definition of
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Alex Martelli) wrote:
Tom Anderson [EMAIL PROTECTED] wrote:
...
Haskell is strongly and statically typed - very strongly and very
statically!
Sure.
However, what it's not is manifestly typed - you don't have to put the
types
On Mon, 12 Dec 2005, Bengt Richter wrote:
On Mon, 12 Dec 2005 01:12:26 +, Tom Anderson [EMAIL PROTECTED] wrote:
--
ø¤º°`°º¤øø¤º°`°º¤øø¤º°`°º¤øø¤º°`°º¤ø
[OT} (just taking liberties with your sig ;-)
,@
On Mon, 12 Dec 2005, Donn Cave wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Alex Martelli) wrote:
Tom Anderson [EMAIL PROTECTED] wrote:
...
For example, if i wrote code like this (using python syntax):
def f(x):
return 1 + x
The compiler would think well, he takes
Tom Anderson wrote:
While we're on the subject of Haskell - if you think python's
syntactically significant whitespace is icky, have a look at Haskell's
'layout' - i almost wet myself in terror when i saw that!
Though one doesn't need to use indentation and write everything using
{} in
Quoth Tom Anderson [EMAIL PROTECTED]:
...
| While we're on the subject of Haskell - if you think python's
| syntactically significant whitespace is icky, have a look at Haskell's
| 'layout' - i almost wet myself in terror when i saw that!
That's funny. I don't think I ever bothered to acquaint
Heiko Wundram wrote:
Brian Beck wrote:
class D1(Base):
def foo(self):
print D1
class D2(Base):
def foo(self):
print D2
obj = Base() # I want a base class reference which is polymorphic
if (need D1):
obj = D1()
else:
obj = D2()
I have no idea what you're trying to do
Brian Beck wrote:
def foo(self):
raise NotImplementedError(Subclasses must implement foo)
That's actually a good idea, though not as nice as a check at
compile-time (jesus, I'm probably talking in C++ speech again, is
there such a thing as compile-time in Python at all?!)
Another thing
That was quite insightful Martin, thanks.
Regards,
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Hallöchen!
Matthias Kaeppler [EMAIL PROTECTED] writes:
[...]
Another thing which is really bugging me about this whole
dynamically typing thing is that it seems very error prone to me:
foo = some string!
# ...
if (something_fubar):
fo = another string
Oops, the last 'o' slipped,
Matthias Kaeppler wrote:
Brian Beck wrote:
def foo(self):
raise NotImplementedError(Subclasses must implement foo)
That's actually a good idea, though not as nice as a check at
compile-time (jesus, I'm probably talking in C++ speech again, is
there such a thing as compile-time in
Matthias Kaeppler wrote:
That was quite insightful Martin, thanks.
Regards,
Matthias
(Disclaimer: i didn't read thru whole thread, but i didn't see these
links trotted out either, which're germane:
http://naeblis.cx/rtomayko/2004/12/15/the-static-method-thing
On Sun, 11 Dec 2005 10:02:31 +0100, Matthias Kaeppler wrote:
Brian Beck wrote:
def foo(self):
raise NotImplementedError(Subclasses must implement foo)
That's actually a good idea, though not as nice as a check at
compile-time (jesus, I'm probably talking in C++ speech again, is
Steven D'Aprano wrote:
Python works well with test-driven development. Test-driven development
will pick up this sort of error, and many other errors too, with less
effort and more certainty than compile-time checking. The problem with
static typed languages is that they make the programmer
On 12/11/05, Matthias Kaeppler [EMAIL PROTECTED] wrote:
Brian Beck wrote:
def foo(self):
raise NotImplementedError(Subclasses must implement foo)
That's actually a good idea, though not as nice as a check at
compile-time (jesus, I'm probably talking in C++ speech again, is
there such
Matthias Kaeppler wrote:
I really see issues with this, can anyone comment on this who has been
working with Python more than just a day (like me)?
Maybe you should work with Python more than one day before you
start looking for potential problems? ;-)
(I suggest reimplementing some portion
In article [EMAIL PROTECTED],
Matthias Kaeppler matthias at finitestate dot org wrote:
Another thing which is really bugging me about this whole dynamically
typing thing is that it seems very error prone to me:
foo = some string!
# ...
if (something_fubar):
fo = another string
Oops, the
On Sun, 11 Dec 2005 05:48:00 -0800, bonono wrote:
Steven D'Aprano wrote:
Python works well with test-driven development. Test-driven development
will pick up this sort of error, and many other errors too, with less
effort and more certainty than compile-time checking. The problem with
Steven D'Aprano wrote:
And I don't think Haskell make the programmer do a lot of work(just
because of its static type checking at compile time).
I could be wrong, but I think Haskell is *strongly* typed (just like
Python), not *statically* typed. At least the What Is Haskell? page at
Fredrik Lundh wrote:
Write code, not usenet posts.
QOTW!
--
http://mail.python.org/mailman/listinfo/python-list
Ernst Noch wrote:
Matthias Kaeppler wrote:
Brian Beck wrote:
def foo(self):
raise NotImplementedError(Subclasses must implement foo)
That's actually a good idea, though not as nice as a check at
compile-time (jesus, I'm probably talking in C++ speech again, is
there such a
gene tani wrote:
http://naeblis.cx/rtomayko/2004/12/15/the-static-method-thing
http://dirtsimple.org/2004/12/java-is-not-python-either.html
http://dirtsimple.org/2004/12/python-is-not-java.html
http://idevnews.com/PrintVersion_CaseStudies.asp?Search3=web+servicesGo2=GoID=118
[EMAIL PROTECTED] wrote:
Just follow the links.
I'll try ;-)
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, 11 Dec 2005 07:10:27 -0800, bonono wrote:
Steven D'Aprano wrote:
And I don't think Haskell make the programmer do a lot of work(just
because of its static type checking at compile time).
I could be wrong, but I think Haskell is *strongly* typed (just like
Python), not
Heiko Wundram wrote:
Maybe I'm assuming things by thinking that others also follow my line of
thought, but I've actually had very positive responses so far when telling
people that a certain feature is a certain way and then pointing them to
the ZoP, they all pretty much told me after a
Steven D'Aprano wrote:
On Sun, 11 Dec 2005 07:10:27 -0800, bonono wrote:
Steven D'Aprano wrote:
And I don't think Haskell make the programmer do a lot of work(just
because of its static type checking at compile time).
I could be wrong, but I think Haskell is *strongly* typed (just
Steven D'Aprano wrote:
Weakly typed languages do not prevent you performing operations on
mismatched types, e.g. something like 1 + 1 is allowed in languages like
Basic and Perl.
Actually, Perl and at least the version of BASIC that I previously used
are not weakly-typed languages either. The
On Sun, 11 Dec 2005 17:05:16 +0100, Matthias Kaeppler wrote:
Why would I want to use an attribute in Python, where I would use
getters and setters in Java?
Oh boy! I've just come out of a rather long thread about that very issue.
If you care enough to read a bunch of people arguing past each
In article [EMAIL PROTECTED],
Matthias Kaeppler matthias at finitestate dot org wrote:
Why would I want to use an attribute in Python, where I would use
getters and setters in Java? I know that encapsulation is actually just
a hack in Python (common, hiding an implementation detail by
Matthias Kaeppler [EMAIL PROTECTED] wrote:
...
I stumbled over this paragraph in Python is not Java, can anyone
elaborate on it:
In Java, you have to use getters and setters because using public
fields gives you no opportunity to go back and change your mind later to
using getters and
Matthias Kaeppler [EMAIL PROTECTED] wrote:
...
I'm so used to statically typed languages that the shift is very
confusing. Looks as if it isn't as easy to learn Python afterall, for
the mere reason of unlearning rules which don't apply in the world of
Python anymore (which seem to be quite
Steven D'Aprano [EMAIL PROTECTED] wrote:
On Sun, 11 Dec 2005 17:05:16 +0100, Matthias Kaeppler wrote:
Why would I want to use an attribute in Python, where I would use
getters and setters in Java?
Oh boy! I've just come out of a rather long thread about that very issue.
If you care
Matthias Kaeppler wrote:
Why would I want to use an attribute in Python, where I would use
getters and setters in Java? I know that encapsulation is actually just
a hack in Python (common, hiding an implementation detail by prefixing
it with the classname so you can't access it by its name
Steven D'Aprano wrote:
I look at it this way: as the class designer, I have ZERO idea what
attributes and methods of my class will be just the perfect thing to solve
somebody's problem, so it is rude of me to lock them up as private --
especially since they *will* find a way to hack my class
that some patterns
only exists as workarounds for the restrictions enforced by statically
typed languages.
[1] should say : for *a certain class of* statically typed languages.
There are also languages like OCaml that relies on type inference.
And how do I formulate polymorphism in Python
Paul Boddie [EMAIL PROTECTED] wrote:
...
offer some kind of solution to that problem. Moreover, Python also lets
you define double-underscore attribute names which behave give instance
attributes privacy in all respects, being invisible to users of the
instances concerned, accessible only
Matthias Kaeppler a écrit :
(snip)
I stumbled over this paragraph in Python is not Java, can anyone
elaborate on it:
In Java, you have to use getters and setters because using public
fields gives you no opportunity to go back and change your mind later to
using getters and setters. So
Paul Boddie [EMAIL PROTECTED] writes:
One classic example of a
weakly-typed language is BCPL, apparently, but hardly anyone has any
familiarity with it any more.
Actually, BCPL is what Stevenn D'Aprano called untyped. Except his
definition is suitable for after everyone followed IBM's
Steven D'Aprano [EMAIL PROTECTED] writes:
Of course, the IT world is full of people writing code and not testing
it, or at least not testing it correctly. That's why there are frequent
updates or upgrades to software that break features that worked in the
older version. That would be
Bruno Desthuilliers [EMAIL PROTECTED] writes:
^^ There is no functionality to check if a subclass correctly
implements an inherited interface
I don't know of any language that provide such a thing. At least for
my definition of correctly.
Well, since your definition of correclty is uknown,
On Mon, 12 Dec 2005, Steven D'Aprano wrote:
On Sun, 11 Dec 2005 05:48:00 -0800, bonono wrote:
And I don't think Haskell make the programmer do a lot of work(just
because of its static type checking at compile time).
I could be wrong, but I think Haskell is *strongly* typed (just like
Mike Meyer [EMAIL PROTECTED] wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Of course, the IT world is full of people writing code and not testing
it, or at least not testing it correctly. That's why there are frequent
updates or upgrades to software that break features that worked in
Tom Anderson [EMAIL PROTECTED] wrote:
...
Haskell is strongly and statically typed - very strongly and very
statically!
Sure.
However, what it's not is manifestly typed - you don't have to put the
types in yourself; rather, the compiler works it out. For example, if i
wrote code like
On Mon, 12 Dec 2005 01:12:26 +, Tom Anderson [EMAIL PROTECTED] wrote:
tom
--
ø¤º°`°º¤øø¤º°`°º¤øø¤º°`°º¤øø¤º°`°º¤ø
---910079544-1780890058-1134349946=:30272--
[OT} (just taking liberties with your sig ;-)
,@
Hi,
sorry for my ignorance, but after reading the Python tutorial on
python.org, I'm sort of, well surprised about the lack of OOP
capabilities in python. Honestly, I don't even see the point at all of
how OO actually works in Python.
For one, is there any good reason why I should ever
Matthias Kaeppler wrote:
snip a whole lot of talk of someone still thinking in terms of C
Let this enlighten your way, young padawan:
[EMAIL PROTECTED] ~/gtk-gnutella-downloads $ python
Python 2.4.2 (#1, Oct 31 2005, 17:45:13)
[GCC 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)] on linux2
Matthias Kaeppler wrote:
polymorphism seems to be missing in Python
QOTW!
/F
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh wrote:
Matthias Kaeppler wrote:
polymorphism seems to be missing in Python
QOTW!
Let's have some UQOTW: the un-quote of the week! ;-)
--- Heiko.
--
http://mail.python.org/mailman/listinfo/python-list
Matthias Kaeppler wrote:
class Base:
def foo(self): # I'd like to say that children must implement foo
pass
def foo(self):
raise NotImplementedError(Subclasses must implement foo)
Now calling foo on a child instance will fail if it hasn't implemented foo.
And how do I
Brian Beck wrote:
class D1(Base):
def foo(self):
print D1
class D2(Base):
def foo(self):
print D2
obj = Base() # I want a base class reference which is polymorphic
if (need D1):
obj = D1()
else:
obj = D2()
I have no idea what you're trying to do here and
In article [EMAIL PROTECTED],
Matthias Kaeppler [EMAIL PROTECTED] wrote:
...
obj = Base() # I want a base class reference which is polymorphic
obj now refers to an instance of Base.
if (need D1):
obj = D1()
obj now refers to an instance of D1(). The Base instance is
unreferenced.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthias == Matthias Kaeppler [EMAIL PROTECTED] writes:
Matthias sorry for my ignorance, but after reading the Python
Matthias tutorial on python.org, I'm sort of, well surprised about
Matthias the lack of OOP capabilities in python. Honestly, I
Heiko Wundram wrote:
Matthias Kaeppler wrote:
snip a whole lot of talk of someone still thinking in terms of C
Well, unless you are (or he is) in with the GNOME crowd, C probably
isn't really the object-oriented language acting as inspiration here.
[Zen of Python]
Of course the ZoP (Zen of
Heiko Wundram wrote:
Fredrik Lundh wrote:
Matthias Kaeppler wrote:
polymorphism seems to be missing in Python
QOTW!
Let's have some UQOTW: the un-quote of the week! ;-)
+1
--
http://mail.python.org/mailman/listinfo/python-list
Paul Boddie wrote:
Heiko Wundram wrote:
Matthias Kaeppler wrote:
snip a whole lot of talk of someone still thinking in terms of C
Well, unless you are (or he is) in with the GNOME crowd, C probably
isn't really the object-oriented language acting as inspiration here.
Pardon this glitch, I
?
--
http://mail.python.org/mailman/listinfo/python-list
Harlin Seritt [EMAIL PROTECTED] wrote:
class Animal:
def eats(self):
print 'The animal eats.'
def walks(self):
print 'The animal walks.'
#the self keyword means that this function will be a class
function
Mike Meyer wrote:
First, the correct terminology is class
could ildg wrote:
I think decorator is a function which return a function, is this
right?
e.g. The decorator below if from
http://www.python.org/peps/pep-0318.html#id1.
def accepts(*types):
def check_accepts(f):
assert len(types) == f.func_code.co_argcount
def
1 - 100 of 109 matches
Mail list logo
