Not fully OO ?
candide
"About Python: Python is a high level scripting language with object
oriented features.
(...)
Python supports OOP and classes to an extent, but is not a full OOP
language."
Thanks for any comment.
James Mills
Everything form modules, functions to basic data types are an object.
--JamesMills
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
--
-- "Problems are solved by method"
Kay Schluehr
> Excerpt quoted fromhttp://www.astro.ufl.edu/~warner/prog/python.html:
This is somewhat true. But what is OO, really?
Answer: if you want to define an entity it has to be defined inside a
class. If you want to access an entity you have to use the dot
operator. Therefore Java is OO but Python is not.
Fredrik Lundh
> Answer: if you want to define an entity it has to be defined inside a
> class. If you want to access an entity you have to use the dot
> operator. Therefore Java is OO but Python is not.
you're satirising the quoted author's cargo-cultish view of object
orientation, right?
</F>
Carl Banks
> Excerpt quoted fromhttp://www.astro.ufl.edu/~warner/prog/python.html:
Python is what it is, whatever you call it. That page has a whole
list of features (we'll give the author the benefit of the doubt and
assume they're accurate and fairly up-to-date). Those features (more
or less) define what Python is, not trendy computer science catch
words.
Carl Banks
Colin J. Williams
"foreach: for x in array: statements
Loops over the array given by array. On
each iteration, the value of the current
element is assigned to x and the
internal array pointer is advanced by one. "
This could be a useful addition to Python.
numarray is no longer supported. It has
been supplanted by numpy.
How is OOP defined?
Colin W.
Fredrik Lundh
> "foreach: for x in array: statements
>
> Loops over the array given by array. On each iteration, the value of the
> current element is assigned to x and the internal array pointer is
> advanced by one. "
>
> This could be a useful addition to Python.
for-in could be a useful addition to Python? looks like Guido's used
his time machine again, then, since it's been around since the pre-1.0 days:
http://www.python.org/doc/ref/for.html
</F>
"Martin v. Löwis"
> his time machine again, then, since it's been around since the pre-1.0
> days:
>
> http://www.python.org/doc/ref/for.html
He somehow must have misinterpreted
http://www.astro.ufl.edu/~warner/prog/python.html
which has the exact text he quoted. Unfortunately, this text has
foreach in bold, so he might have assumed foreach to be a keyword
(despite the example to the right demonstrating the contrary).
What this has to do with OO, or with numpy, is beyond me.
Regards,
Martin
Duncan Booth
General comments about the page:
Section 2: Poor demonstration of 'global'. The declaration of 'a' as global
is unnecessary and misleading.
Section 4: "Maths: Requires import math"
The supplied examples won't work if you just "import math", they need a
"from math import ..." (either * or better an explicit list of functions).
Worse, the random number examples won't work whatever you import as they
include both 'random.seed()' which assumes 'random' is the module and 'x =
random()' which requires 'from random import random'.
Section 5: "Strings do not expand escape sequences unless it is defined as
a raw string by placing an r before the first quote" What is that supposed
to mean? Describing triple quoted strings as 'optional syntax' is a bit
weird too: the syntax is no more optional than any other form of string
literal, you can use it or not.
Another pointless example given under the heading 'String Operators':
Concatenation is done with the + operator.
Converting to numbers is done with the casting operations:
x = 1 + float(10.5)
"String functions" actually mostly describes string methods with "len"
hidden in the middle but only the example tells you that it is different
than the other examples.
Section 6 is all about numarray but bizarrely (for something purporting to
be an overview of Python) there is nothing at all about either list or dict
types.
Section 7 says "There is no switch or case statement so multiple elifs must
be used instead." omitting to mention other possibly more appropriate
options such as dicts or inheritance. This is a good indication that the
author doesn't know much about OOP.
Section 8 "for x in array: statements" shows that the author doesn't
understand things like iterators.
Section 10 has such interesting facts as "Only constant initializers for
class variables are allowed (n = 1)" or "Objects can be compared using the
== and != operators. Two objects are equal only if they are the same
instance of the same object." and an example with a completely spurious
class attributes, some pointless getter/setter methods, and contorted calls
to base class methods.
Section 11 demonstrates again that the author doesn't understand about
iterable objects.
I'd say the claim that Python isn't a full OOP language is not the most
important reason to ignore the page.
Steven D'Aprano
> This is a good indication that the
> author doesn't know much about OOP.
I think you can drop the last two words :)
Actually that's unfair -- it looks like he knows quite a bit about the
metallicity of quasers, but he's just parroting a bunch of Java concepts
as if Java was the be-all and end-all of object oriented programming,
which is clearly wrong because we all know that Python's object model is
the One True OOP.
*wink*
--
Steven
Kay Schluehr
I wonder if the OO fetish hasn't already lost much of its magic
powers. What are the most powerful fetishes these days? A year ago I
would have suspected "purely functional" but I'm not sure it has
really caught on.
Eduardo O. Padoan
I think the current fetish is paralelism and erlang's share-nothing
concurrency model. Or something like it.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Eduardo de Oliveira Padoan
http://djangopeople.net/edcrypt/
http://stopforwarding.us/etiq.html
Thomas G. Willis
> Excerpt quoted fromhttp://www.astro.ufl.edu/~warner/prog/python.html:
My comment is "Who cares?"
I was always under the impression that if any language truly was "OO"
it would be smalltalk. And I don't derive any benefit from smalltalk
at all. I do however derive substantial benefit from other languages
that "OO zealots" would likely poo poo on including python.
Colin J. Williams
for_stmt ::= "for" target_list "in"
expression_list ":" suite
["else" ":" suite]
Colin W.
Aaron "Castironpi" Brady
If you define OO as implementation inheritance, then Java is not. It
inherits interface only. Another possibility is, has a virtual
function table. The fact that Python indexes by name doesn't
disqualify it from that definition. I don't know if Java meets it.
I don't think raw C structures would be included, and you can define
function pointers in them.
Wikipedia puts it decently: "mainly for OO programming, but with some
procedural elements."
<ducks>
Paul Boddie
wrote:
>
> Wikipedia puts it decently: "mainly for OO programming, but with some
> procedural elements."
>
> <ducks>
When it comes to Python and object-oriented programming, you can't
leave out the ducks. ;-)
Paul
Bruno Desthuilliers
The following definitions are AFAIK the only commonly accepted
definitions about OO:
1/ an object is defined by identity, state and behaviour
2/ objects interacts by sending messages each other
3/ an OO program is made of interacting objects
I let you find out whether Python meets these 3 definitions - and if
Java does (hint : in Python, everything you can bind to a name is an
object - this is not true in Java or C++).
Kay Schluehr
<bdesth.quelquech...@free.quelquepart.fr> wrote:
> The following definitions are AFAIK the only commonly accepted
> definitions about OO:
>
> 1/ an object is defined by identity, state and behaviour
> 2/ objects interacts by sending messages each other
> 3/ an OO program is made of interacting objects
>
> I let you find out whether Python meets these 3 definitions - and if
> Java does (hint : in Python, everything you can bind to a name is an
> object - this is not true in Java or C++).
This is correct but it detracts from a more general problem of
language "paradigms".
Assume you type
>>> 2+2
4
Now you are free to interpret this as a simple, primitive arithmetic
operation but you can also claim that 2 sends an __add__ message to 2.
Hereby the state of the 2 objects are not altered but a new 4 object
is created. OO babble is more impressive isn't it?
Actually it is simply wrong in the mentioned case and here is the
proof:
def foo():
return 2+2
import dis
dis.dis(foo)
2 0 LOAD_CONST 2 (4)
3 RETURN_VALUE
OO is a heuristic method used to understand the semantics of a
programming language. It can also inspire language design but as
you've rightly said: jugde yourself and see how far you get with it.
Applying OO on interpreter level is by no means a sign of a high
quality implementation whereas structuring programs in the large will
likely benefit from class based organization and encapsulation. Of
course one can also reverse the value hierarchy and find perverse joy
in having a pure OO language but apply monkey patching everywhere. I
suppose you know which language I'm talking about...
Aaron "Castironpi" Brady
It sounds like you think that you -can- write OO programs in Python,
but you don't have to. I agree.
Christian Heimes
> Actually it is simply wrong in the mentioned case and here is the
> proof:
>
> def foo():
> return 2+2
>
> import dis
> dis.dis(foo)
>
> 2 0 LOAD_CONST 2 (4)
> 3 RETURN_VALUE
>
> OO is a heuristic method used to understand the semantics of a
> programming language. It can also inspire language design but as
> you've rightly said: jugde yourself and see how far you get with it.
It's not wrong. You have found a simple optimization. Lot's of compilers
for lots of languages optimize code by code folding.
Python's peephole optimizer replaces code like 2+2 with 4.
Christian
Aaron "Castironpi" Brady
> Kay Schluehr wrote:
> > Actually it is simply wrong in the mentioned case and here is the
> > proof:
>
> > def foo():
> > return 2+2
>
> > import dis
> > dis.dis(foo)
>
> > 2 0 LOAD_CONST 2 (4)
> > 3 RETURN_VALUE
>
> > OO is a heuristic method used to understand the semantics of a
> > programming language. It can also inspire language design but as
> > you've rightly said: jugde yourself and see how far you get with it.
>
> It's not wrong.
The meaning of the Python program is, internally, on a cycle-by-cycle
basis, "Object 2; send add( Object 2 ) to Object 2; Return object 4."
CPython doesn't do this, but due to the fact that there are no cases
in which that distinction affects the output, it's still an
implementation of Python.
Or at least, a practical implementation.
Aahz
Thomas G. Willis <tom.w...@gmail.com> wrote:
"...some experts might say a C++ program is not object-oriented without
inheritance and virtual functions. As one of the early Smalltalk
implementors myself, I can say they are full of themselves." --zconcept
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"Argue for your limitations, and sure enough they're yours." --Richard Bach
Kay Schluehr
wrote:
The whole point of OO is providing high level ( system level ) not low
level ( interpreter level ) semantics. Partitioning a system into
isolated and communicating objects is a strong and important metaphor.
Recently there were some comments on the web that mentioned Erlang to
be pretty much OO in this respect although Erlang is functional and
has no base level notion of an "object". It's even well known that Joe
Armstrong holds low opinions about the entire object business.
Notice that I believe that the popular meme that OO is "bolted on"
Python has little if nothing to do with OO itself but with API
consistency. When people have to type len(x) instead of x.len() this
breaks their expectations on how the language has to behave.
Méta-MCI (MVP)
> Everything ... are an object.
It's true ; but a language built around the objects, and OOP, are two
different concepts.
@-salutations
--
Michel Claveau
Méta-MCI (MVP)
AMHA, ceux qui ont écrit ce texte ont une mauvaise idée de ce que sont
les variables en Python.
Ils ont sans doute trop en tête les notions des variables en C ou en
Basic, et ne se sont pas penchés sur les spécificités de Python.
@-salutations
--
Michel Claveau
"Martin v. Löwis"
> Kay Schluehr wrote:
>> Actually it is simply wrong in the mentioned case
>
> It's not wrong. You have found a simple optimization. Lot's of compilers
> for lots of languages optimize code by code folding.
I don't think he meant that Python is wrong somehow, but that the OO
babble of what happens for 2+2 is wrong. The babble said that, when the
code is executed, an __add__ message is sent to the 2 object, with
another 2 object as the parameter. That statement is incorrect: no
message is sent at all, but the result is available even before the
program starts.
FWIW, "2+2" is not a good case for OO in Smalltalk, either. In a typical
implementation, SmallInteger is not a real class, in the sense that 2 is
not a real object. Instead, it lives in a tagged pointer, i.e. it has no
identity.
Regards,
Martin
Fredrik Lundh
> I don't think he meant that Python is wrong somehow, but that the OO
> babble of what happens for 2+2 is wrong. The babble said that, when the
> code is executed, an __add__ message is sent to the 2 object, with
> another 2 object as the parameter. That statement is incorrect: no
> message is sent at all, but the result is available even before the
> program starts.
On the other hand, the inability to distinguish between "as if" and
"hah, I've looked under the covers" isn't necessarily a good trait for a
programmer. If he bases his mental model on concrete implementation
details of a production quality software product, he's bound to end up
with a cargo-cultish understanding of fundamental issues. If he uses it
to win arguments, people will flip his bozo bit pretty quickly.
</F>
Ricardo Aráoz
x.__len__()
Craig Allen
language. It is clearly possible to write procedural code... that is,
Python does not force object oriented syntax or concepts on you and
insist you define everything in such a structure. Is the OO it allows
full OO, I think so, and the only way to argue otherwise I think is to
point out that the "main" function is just the module level itself,
and is not part of an object... which is just the sort of pedantic
things purists like to hang their hat on.
personally I am very much the sort that believe in "trust the
programmer" and likes languages that provide a freedom to use various
complementary paradigms, in the style of C++. Compared to that, it's
clear that Python is quite object oriented even in the sense of
drawing you to build things in object oriented ways... just not
strictly requiring it. Which is good, it allows some interesting
patterns which play quite well with object oriented desirgn (i.e.
module as singleton)... in fact, that plays so well as a singleton,
some would say the module is just an object anyway, and indeed, the
intepreter tends to agree.
So python may turn out to be pure OO, where Objects SIMULATE
procedural programming paradigms and allow that paradigm as a result,
on top of OO.
cheers.
Tim Rowe
> So python may turn out to be pure OO
I think that's the sort of thing the pedants would hang that hats on,
too. Python isn't *pure* OO, in that it lets the programmers do non-OO
if they want to, but it is *fully* OO in that it includes everything
required to do OO. But maybe the original blogger meant by "fully OO"
what I mean by "Pure OO"?
The question I usually ask is "Does this language help me get the job
done?" Python often does. That's all that really matters, isn't it?
--
Tim Rowe
Craig Allen
> required to do OO. But maybe the original blogger meant by "fully OO"
> what I mean by "Pure OO"?
it seems to me this is what was meant... pure OO, AND forced to use
it.
My personal feeling is that python is multiparadigmed and I'm more
than fine with that.
BUT, I am going to hold onto what I've noticed which is that Python
seems to use OO deeply, well into the interpreter, and that the
procedural styles available at the Python source level pretty much are
built on top of this OO model, given you accept a module as an object,
which it seems to be within the source code... but in the end, it's
just words and the most important thing is that python is a tool you
can use to make a computer do what you want, and whatever you call it
may just be a distraction. cheers.
Lawrence D'Oliveiro
<24ac4a18-049f-4ae0...@a18g2000pra.googlegroups.com>, Craig
Allen wrote:
> It is clearly possible to write procedural code... that is,
> Python does not force object oriented syntax or concepts on you ...
Object orientation IS procedural.
Lawrence D'Oliveiro
> "... Python supports OOP and classes to an extent, but is not a full OOP
> language."
Python allows you to use OO-style constructs, but doesn't force you to have
inheritance and subclasses if you don't want to. Duck typing is usually a
much more flexible approach.
James Mills
<l...@geek-central.gen.new_zealand> wrote:
> Object orientation IS procedural.
Correction: OOP is Imperative.
--JamesMills
--
--
-- "Problems are solved by method"
Lawrence D'Oliveiro
<ee99e813-97e0-404c...@b1g2000hsg.googlegroups.com>,
Aaron "Castironpi" Brady wrote:
> Wikipedia puts it decently: "mainly for OO programming, but with some
> procedural elements."
"Procedural" is the opposite of "functional", not "object-oriented".
Bruno Desthuilliers
AFAIK, the "opposite" if functional is imperative, not procedural. But
let's not waste too much time on terminology arguments...
Steven D'Aprano
>> "Procedural" is the opposite of "functional", not "object-oriented".
>
> AFAIK, the "opposite" if functional is imperative, not procedural. But
> let's not waste too much time on terminology arguments...
We're not wasting time on terminology arguments, we're wasting time on
definitional debates.
--
Steven
Tino Wildenhain
Tim Rowe wrote:
> 2008/9/23 Craig Allen <call...@gmail.com>:
>
>> So python may turn out to be pure OO
...
> The question I usually ask is "Does this language help me get the job
> done?" Python often does. That's all that really matters, isn't it?
Well then it still depends on the perception of "job done". For example
PHP programmers would bet their soul that their language of choice is
exactly the right one to "get the job done." :-)
You and me would indeed see a different picture on the level of doneness
of such jobs ;-)
T.
Patrick Mullen
about editing it in the future, and how much I just want to get
something up, I will occasionally use php. And I am a self confessed
php hater :) But it's generally the fastest way I know to get
something up. So even terrible languages can have their uses!
Bruno Desthuilliers
Sorry but I fail to see how it relates to the current thread ???
Steven D'Aprano
I think Patrick is responding to a comment from Tino Wildenhain:
[quote]
Well then it still depends on the perception of "job done". For example
PHP programmers would bet their soul that their language of choice is
exactly the right one to "get the job done."
[end quote]
Patrick, you will cause much less confusion if you quote relevant parts
of the text you are replying too.
--
Steven
Tim Rowe
>> The question I usually ask is "Does this language help me get the job
>> done?" Python often does. That's all that really matters, isn't it?
>
> Well then it still depends on the perception of "job done". For example
> PHP programmers would bet their soul that their language of choice is
> exactly the right one to "get the job done." :-)
> You and me would indeed see a different picture on the level of doneness
> of such jobs ;-)
Well, I did say "Often". Before now I've struggled for ages to write a
Python program to do a job, then when I've tried C# all the problems
have fallen away and the job was done in an hour or so. But other
times it has been the other way around; I've done stuff in Python that
I wouldn't know where to begin with in other languages. One of my
constant refrains is that *no* tool is ideal for *all* jobs!
--
Tim Rowe
Aaron "Castironpi" Brady
> 2008/9/26 Tino Wildenhain <t...@wildenhain.de>:
I thought procedural and imperative were the same.
"Sorry, but you forgot to phrase your expression in the form of a
command."
I'll take 'modules' for $500, Alex.
Bruno Desthuilliers
Bruno Desthuilliers
>
>> Patrick Mullen a écrit :
>>> Depending on the scale of the website I am making, how much I care
>>> about editing it in the future, and how much I just want to get
>>> something up, I will occasionally use php. And I am a self confessed
>>> php hater :) But it's generally the fastest way I know to get
>>> something up. So even terrible languages can have their uses!
>> Sorry but I fail to see how it relates to the current thread ???
>
> I think Patrick is responding to a comment from Tino Wildenhain:
That didn't showed here (reading this from c.l.py via free.fr). Sorry.
> [quote]
> Well then it still depends on the perception of "job done". For example
> PHP programmers would bet their soul that their language of choice is
> exactly the right one to "get the job done."
> [end quote]
>
> Patrick, you will cause much less confusion if you quote relevant parts
> of the text you are replying too.
Indeed. At least it would have made clear (to me) there was something
missing in the thread...
Bruno Desthuilliers
> 2008/9/26 Tino Wildenhain <ti...@wildenhain.de>:
>
>>> The question I usually ask is "Does this language help me get the job
>>> done?" Python often does. That's all that really matters, isn't it?
>> Well then it still depends on the perception of "job done". For example
>> PHP programmers would bet their soul that their language of choice is
>> exactly the right one to "get the job done." :-)
>> You and me would indeed see a different picture on the level of doneness
>> of such jobs ;-)
>
> Well, I did say "Often". Before now I've struggled for ages to write a
> Python program to do a job, then when I've tried C# all the problems
> have fallen away and the job was done in an hour or so.
Not to start a troll, but from what I've seen of C# so far I do find
this a bit surprising and really suspect more of a library issue than a
language one. Care to tell more about the problem and solution ?
(NB : I wouldn't even asked if you had mentionned say Erlang or Prolog
or OCaml - well, some mostly different language - instead of C#)
Aaron "Castironpi" Brady
> 2008/9/26 Tino Wildenhain <t...@wildenhain.de>:
>
> >> done?" Python often does. That's all that really matters, isn't it?
>
> > Well then it still depends on the perception of "job done". For example
> > PHP programmers would bet their soul that their language of choice is
> > exactly the right one to "get the job done." :-)
> > You and me would indeed see a different picture on the level of doneness
> > of such jobs ;-)
>
> Well, I did say "Often". Before now I've struggled for ages to write a
> Python program to do a job, then when I've tried C# all the problems
What problems?
> have fallen away and the job
What job?
> was done in an hour or so. But other
> times it has been the other way around; I've done stuff in Python that
> I wouldn't know where to begin with in other languages. One of my
> constant refrains is that *no* tool is ideal for *all* jobs!
>
> --
> Tim Rowe
If you have wxFormBuilder and the win32 library, it's pretty fast.
Python's philosophy is to make common things easy and everything
possible.
Tim Rowe
> Not to start a troll, but from what I've seen of C# so far I do find this a
> bit surprising and really suspect more of a library issue than a language
> one. Care to tell more about the problem and solution ?
>
> (NB : I wouldn't even asked if you had mentionned say Erlang or Prolog or
> OCaml - well, some mostly different language - instead of C#)
IIRC it was library issues -- for one thing I still find it a lot
harder to manage an MS Windows GUI under Python than I do under .NET
(I've never succeeded in getting Iron Python to run properly). In one
sense you could argue that that's not a language issue, and you'd be
right: there's nothing in the syntax or semantics of either language
that makes it so. But in another sense I'd say it is a language issue
(and of course I think I'm right!) because Python aims to be platform
independent, and whilst that means gains in portability it means that
in return it loses the ease-of-programming of a tightly integrated
platform.
--
Tim Rowe
Tim Rowe
> If you have wxFormBuilder and the win32 library, it's pretty fast.
Speed has never been an issue for me with Python. For my masters
degree I did a project that involved a lot of number crunching, and in
my proposal I wrote that I'd use Python for most of the code and C for
any parts that were unacceptably slow. In practice, not only did I
never need to replace any parts with C, I never even needed to use
numpy; it was quite fast enough as it was.
> Python's philosophy is to make common things easy and everything
> possible.
But what's common for one person may be uncommon for another. And
sometimes "possible" isn't enough, or we'd all be using INTERCAL!
Another, quite different example to the one I was referring to earlier
is the fact that I often work with safety critical systems. I don't
think formal proof of program behaviour would be at all
straightforward in Python (or C# for that matter, and although Spec#
gets closer, it really needs a language like Spark Ada).
--
Tim Rowe
Aaron "Castironpi" Brady
> 2008/9/26 Aaron Castironpi Brady <castiro...@gmail.com>:
No. I understand that formal proof systems, as well as automated
theorem provers, have been difficult to develop. When I took ML, the
homeworks were to prove the correctness of an interpretation of a
program, and the unique existence of a meaning by induction.
But I, and I imagine I'm not the only one, would love to know the
example that C# developed faster than Python. I suppose the fact that
the line of wx specification that has two identifiers where C# has one
is more of a drain on programmer resources than may commonly be
recognized--- not the same as the cost of one extra word in a paper or
in an editorial. Similarly, maybe the program that has one extra
identifier in a line takes a lot more time to develop. Perhaps it's
the "7 +/- 1" trend in attention span that makes the difference large
in that case. 8 identifiers would in that theory be a big deal, so
the example in C# could make the case for it.
Tim Rowe
> But I, and I imagine I'm not the only one, would love to know the
> example that C# developed faster than Python. I suppose the fact that
> the line of wx specification that has two identifiers where C# has one
> is more of a drain on programmer resources than may commonly be
> recognized--- not the same as the cost of one extra word in a paper or
> in an editorial. Similarly, maybe the program that has one extra
> identifier in a line takes a lot more time to develop.
But I didn't use wx -- that's rather the point. Long before the days
of Python, I kept wanting to use Modula2 but kept getting driven back
to C because in Modula2 I kept having to write stuff that was already
in C libraries. Modula2 was a far better language, but C usually was
far more productive because of what went around it. C#'s tight
integration with .net and VS mean that it's not a question of one
identifier instead of two, it's *zero* identifiers instead of two
because the tool does it all for me. Does that mean that C# is a
better language than Python? No, of course not. Does it mean that what
I was doing was not possible in Python? No, of course not. Does it
mean that C# was more productive than Python for me doing that
particular job? Yes it does. (FWIW, I also found the .net XML handling
easier to cope with on that same job).
One day Iron Python plus the VS integration might wean me off C# but
last time I looked it wasn't close. Maybe I should take another look
and see how it's coming on.
--
Tim Rowe
Aaron "Castironpi" Brady
> 2008/9/27 Aaron Castironpi Brady <castiro...@gmail.com>:
No way. It's *zero* instead of one, if so, because the only thing C#
has is a bunch of handcuffs and implicit 'self'. You have a line
like:
n= aTree.ExpandedCount
What in 'wx', which I -am- using, <avoids insubordinate tone>, takes
more identifiers:
n= self.aTree.ExpandedCount
or if you're 'inlining', for lack of better words, everything, outside
a class,
n= aForm.aTree.ExpandedCount.
For a grand total of 1 'aForm' identifier that C# infers implicitly.
Tim Rowe
> No way. It's *zero* instead of one, if so, because the only thing C#
> has is a bunch of handcuffs and implicit 'self'. You have a line
> like:
You don't follow what I said, and from your tone I get the feeling you
don't *want* to follow what I'm saying, not because I'm criticising
Python (I'm not), but because I'm guilty of the heresy of suggesting
that it's not actually simultaneoulsy optimised for every possible
use.
My point is that there are zero parameters as far as I am concerned
because I don't actually touch most of the GUI code. There could
actually be hundreds of parameters, for all I care. They're not my
concern. Most of the time I like that -- the tools are doing my work
for me.
--
Tim Rowe
Aaron "Castironpi" Brady
> 2008/9/27 Aaron Castironpi Brady <castiro...@gmail.com>:
>
flamewar.avert( ), please. Yes, I agree, I did not follow every
word. It's a fundamental disagreement about successful ways to
communicate, and, for the philosophers, successful communication,
whether I should have nitpicked first thing, or tried to go along with
the gist. I tried the latter. In your case, I guessed wrong. Sorry.
Before I tried wxFormBuilder, I imagined that C# would be vastly
faster to develop than Python, for anything requiring any non-trivial
graphical interface. I've done extensive VB, so I can attest to that
personally. It is not. The difference in dev times is about the time
it takes to write:
def onClick( event ):
...
controlA.bind( wx.MOUSEDOWN, onClick )
perhaps several times, which, <glances at watch>, is not long. You do
get the IDE, true, and that code is auto-crafted for you. But 'wx'
does give you data in an XML file, instead of a script. And talk
about a difference in identifiers:
<form>
<button>
<pos>20,30</pos>
<color>gray</color>
</button>
</form>
vs.
form.button.pos= 20, 30
form.button.color= gray
You can come up with examples that favor either. But the opposite of
statistical is anecdotal. Sorry again.
The last time I 'checked in' at your post, your claim was "an hour or
so" vs. "ages". Hence my responses. You could probably sneak by by
claiming a factor of *two*, but if you were exaggerating, please say
so at any time.
Penultimately, forgive my sarcasm--- I'm a bit feisty right now. I
was distinguishing between arguments in particular, and identifiers in
general.
And lastly, "simultaneoulsy optimised for every possible use" is a
bold claim that I didn't make, at least, to come forward, in so many
words. I do believe, and it shows, as of today, and you can quote me
on this, that it's "pretty generally applicable", though I reserve the
right to change my mind on the matter with or without notice.
Especially if I learn something. I do not believe that C# is pretty
generally applicable. I maintain that I will adjust that estimate if
I ever get any facts about C#, since I don't have very many. (In
fact, outside of my VB, COM, and MFC experience, you could say I have
no clue. Very tongue in cheek.)
In fact, do a Google for 'castironpi "every possible"'. You get a
"can't ... every possible", and your post, and something else. That's
it.
Python has a lot of things C# doesn't. Can we agree on that?
Lawrence D'Oliveiro
Mills wrote:
> On Fri, Sep 26, 2008 at 8:20 AM, Lawrence D'Oliveiro
> <l...@geek-central.gen.new_zealand> wrote:
>
>> Object orientation IS procedural.
>
> Correction: OOP is Imperative.
No, "procedural".
The functional unit is called an "expression", the encapsulation of which is
called a "function". Hence "functional".
Similarly, the procedural unit is commonly called a "statement", the
encapsulation of which is a "procedure", not an "imperator".
Hence "procedural".
Lawrence D'Oliveiro
<f9b466b0-9945-42c1...@y38g2000hsy.googlegroups.com>,
Aaron "Castironpi" Brady wrote:
> I understand that formal proof systems, as well as automated
> theorem provers, have been difficult to develop.
The basic problem is: having proved that a program satisfies certain
formally-specified criteria, how do you prove that those formal criteria
specifications actually correspond to the original problem you were trying
to solve? The proof just pushes the correctness problem back another level.
Bruno Desthuilliers
> 2008/9/26 Bruno Desthuilliers <bdesth.qu...@free.quelquepart.fr>:
>
>> Not to start a troll, but from what I've seen of C# so far I do find this a
>> bit surprising and really suspect more of a library issue than a language
>> one. Care to tell more about the problem and solution ?
>>
>> (NB : I wouldn't even asked if you had mentionned say Erlang or Prolog or
>> OCaml - well, some mostly different language - instead of C#)
>
> IIRC it was library issues -- for one thing I still find it a lot
> harder to manage an MS Windows GUI under Python than I do under .NET
> (I've never succeeded in getting Iron Python to run properly). In one
> sense you could argue that that's not a language issue, and you'd be
> right: there's nothing in the syntax or semantics of either language
> that makes it so. But in another sense I'd say it is a language issue
> (and of course I think I'm right!)
And - after reading the following argument - I think you're wrong !-)
> because Python aims to be platform
> independent, and whilst that means gains in portability it means that
> in return it loses the ease-of-programming of a tightly integrated
> platform.
>
Still a library issue. Python doesn't defines "platform-independant" the
way Java does, and there are quite a couple Python packages (third-part
or even in the standard lib) that are clearly platform-specific -
including MS Windows COM stuff, which was a major PITA using VB6.
Tim Rowe
> Before I tried wxFormBuilder, I imagined that C# would be vastly
> faster to develop than Python, for anything requiring any non-trivial
> graphical interface. I've done extensive VB, so I can attest to that
> personally. It is not.
I'm confused about where VB comes in -- I find VB just *slightly*
harder than INTERCAL. C# I find fairly easy.
> You can come up with examples that favor either. But the opposite of
> statistical is anecdotal. Sorry again.
Yes, it's anecdotal, but development time isn't just about how fast
the program is to type (otherwise, why aren't we all using APL?)
> The last time I 'checked in' at your post, your claim was "an hour or
> so" vs. "ages". Hence my responses. You could probably sneak by by
> claiming a factor of *two*, but if you were exaggerating, please say
> so at any time.
Ok. I was exaggerating when I said that VB was harder than INTERCAL.
It's marginally easier.
As for the program I was working on, I worked for over a day on it in
Python, and did it in about an hour in C#, although in fairness I
didn't forget all the thinking I'd done on the previous day. I have a
lot more Python experience than C# experience, but don't claim to be a
guru in either. And no, I don't work two hour days (unfortunately). I
have indicated that the GUI wasn't the only issue; in C# it was just
easy in that case to find all the library bits I needed to in order to
accomplish the task. It isn't always so.
> on this, that it's "pretty generally applicable"
I'm with you on that.
> I do not believe that C# is pretty generally applicable.
I agree on that, but *only* because it's a proprietary language with
imperfect support once you move away from the .net platform. It's a
generally applicable language to .net, but .net is not a general
platform.
> fact, outside of my VB, COM, and MFC experience, you could say I have
> no clue. Very tongue in cheek.)
If you see C# as being in any way related to VB, it's no wonder you're
down on it!
> Python has a lot of things C# doesn't. Can we agree on that?
And C# has things that Python doesn't (such as static typing). Can we
agree on that, too?
--
Tim Rowe
Patrick Mullen
> http://mail.python.org/mailman/listinfo/python-list
Whoops, sorry for the confusion everyone. Usually I do keep the
comments, don't know what happened there.
Aaron "Castironpi" Brady
> 2008/9/28 Aaron Castironpi Brady <castiro...@gmail.com>:
Maybe too much of my personal life is affecting my judgment of C#.
You mention tools (that are doing the work for you) and I think
incompatibility. Maybe that part is just because I feel like tools
are like 'excuses'. And maybe that part is just because... awkward.
I'm going to have to bow out of the dispute, sorry, because I am not a
person that knows both of them. (How you decide who knows a language
isn't exactly clear, by the way. It's been stated, for example, that
I don't know Python, as well as that I don't know English.)
You said C# = 1 hour, Python = ages. I said I could see that if it
came to developing a GUI with a draw-on tool in one and not in the
other. (Write that C# GUI spec by hand or position your controls from
scratch.)
You could make a case that you can get bad habits from developing in a
tightly-coupled ("tightly-integrated") framework, as you suggested C#
was. I would agree to it.
I do not find that the Python library is particularly lacking, and the
VB6 library was.
If you're referring to documentation, though, I really like the win32
API docs. They're precise and thorough. The Python docs leave some
stuff unsaid; there's a lot of stuff you can do in Python that people
have to tell you or you have to discover on your own. Which one are
the C# docs like?
Not to reopen the wound, or rather to reopen it patiently: I classify
'static-typing' as handcuffs. C# has handcuffs and lots of kinds of
them. "But static-typing lets you do <fill in the blank>." ? Other
than that, I don't know of any examples, from which I won't infer that
there aren't any. (That was -won't- infer.) "Call," I guess; I'll
bite. What?
If you're referring to library depth, there's a lot of stuff that
probably classifies as wheel reinvention that shouldn't necessarily go
in the library. There was a good example today. 'Return a string of
5 random digits.' You could put that in the library, and call it
'RandomDigitString( int length )'. Doing it by hand only takes one
line though: '"%05i"%random.randint(0,99999)'. Does it belong in the
library? Otherwise you're technically reinventing the wheel, right?
If you want to talk about your application, the day-to-hour ratio
example, please do.
Bruno Desthuilliers
> Mills wrote:
>
>> On Fri, Sep 26, 2008 at 8:20 AM, Lawrence D'Oliveiro
>> <l...@geek-central.gen.new_zealand> wrote:
>>
>>> Object orientation IS procedural.
>> Correction: OOP is Imperative.
>
> No, "procedural".
Nope, "imperative" !-)
> The functional unit is called an "expression", the encapsulation of which is
> called a "function". Hence "functional".
>
> Similarly, the procedural unit is commonly called a "statement", the
> encapsulation of which is a "procedure", not an "imperator".
> Hence "procedural".
"imperative" means that the computation is done through statements that
modify the program's state.
"procedural" means that these statements are organized in "procedures",
that group a serie of statements.
OO is based on objects (that carry and manage internal state) and
messages. A message can happen to trigger a serie of statements that
modifies a program state, so you could say (and this wouldn't be totally
false) that an OO method can be seen as a procedure (or at least some
methods...), but the whole program's organization is still not the same
as one seen in procedural programming. IOW, it's more a matter of how
you design / organize your (otherwise imperative) program than anything
else.