Re: Encapsulation, inheritance and polymorphism

[Mark Lawrence]

On 19/08/2012 12:50, lipska the kat wrote:

On 19/08/12 09:55, Mark Lawrence wrote:

On 19/08/2012 06:21, Robert Miles wrote:

On 7/23/2012 11:18 AM, Albert van der Horst wrote:

In article <5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano  wrote:


[snip]


that functions must only have one exit?


[snip[



Surely the first check is your filing system to make sure that you've
paid the utilties bills so you've got gas and or electricity to apply
the heat. Either that or you hire Ray Mears to produce the spark needed
to light the fire :)


I was wondering how long it would be ...

lipska



Six days shalt thou labour... :)

--
Cheers.

Mark Lawrence.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[lipska the kat]

On 19/08/12 09:55, Mark Lawrence wrote:

On 19/08/2012 06:21, Robert Miles wrote:

On 7/23/2012 11:18 AM, Albert van der Horst wrote:

In article <5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano  wrote:


[snip]


that functions must only have one exit?


[snip[



Surely the first check is your filing system to make sure that you've
paid the utilties bills so you've got gas and or electricity to apply
the heat. Either that or you hire Ray Mears to produce the spark needed
to light the fire :)


I was wondering how long it would be ...

lipska

--
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Mark Lawrence]

On 19/08/2012 06:21, Robert Miles wrote:

On 7/23/2012 11:18 AM, Albert van der Horst wrote:

In article <5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano   wrote:

Even with a break, why bother continuing through the body of the
function
when you already have the result? When your calculation is done, it's
done, just return for goodness sake. You wouldn't write a search that
keeps going after you've found the value that you want, out of some
misplaced sense that you have to look at every value. Why write code
with
unnecessary guard values and temporary variables out of a misplaced
sense
that functions must only have one exit?


Example from recipee's:

Stirr until the egg white is stiff.

Alternative:
Stirr egg white for half an hour,
but if the egg white is stiff keep your spoon still.

(Cooking is not my field of expertise, so the wording may
not be quite appropriate. )


--
Steven


Groetjes Albert


Note that you forgot applying enough heat to do the cooking.




Surely the first check is your filing system to make sure that you've 
paid the utilties bills so you've got gas and or electricity to apply 
the heat.  Either that or you hire Ray Mears to produce the spark needed 
to light the fire :)


--
Cheers.

Mark Lawrence.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[John Ladasky]

On Tuesday, July 17, 2012 12:39:53 PM UTC-7, Mark Lawrence wrote:

> I would like to spend more time on this thread, but unfortunately the 44 
> ton artic carrying "Java in a Nutshell Volume 1 Part 1 Chapter 1 
> Paragraph 1 Sentence 1" has just arrived outside my abode and needs 
> unloading :-)

That reminds me of a remark I made nearly 10 years ago:

"Well, I followed one friend's advice and investigated Java, perhaps a little 
too quickly.  I purchased Ivor Horton's _Beginning_Java_2_ book.  It is 
reasonably well-written.  But how many pages did I have to read before I got 
through everything I needed to know, in order to read and write files?  Four 
hundred!  I need to keep straight detailed information about objects, 
inheritance, exceptions, buffers, and streams, just to read data from a text 
file???

I haven't actually sat down to program in Java yet.  But at first glance, it 
would seem to be a step backwards even from the procedural C programming that I 
was doing a decade ago.  I was willing to accept the complexity of the Windows 
GUI, and program with manuals open on my lap.  It is a lot harder for me to 
accept that I will need to do this in order to process plain old text, perhaps 
without even any screen output."

https://groups.google.com/d/topic/bionet.software/kk-EGGTHN1M/discussion

Some things never change!  :^)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Robert Miles]

On 7/23/2012 11:18 AM, Albert van der Horst wrote:

In article <5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano   wrote:

Even with a break, why bother continuing through the body of the function
when you already have the result? When your calculation is done, it's
done, just return for goodness sake. You wouldn't write a search that
keeps going after you've found the value that you want, out of some
misplaced sense that you have to look at every value. Why write code with
unnecessary guard values and temporary variables out of a misplaced sense
that functions must only have one exit?


Example from recipee's:

Stirr until the egg white is stiff.

Alternative:
Stirr egg white for half an hour,
but if the egg white is stiff keep your spoon still.

(Cooking is not my field of expertise, so the wording may
not be quite appropriate. )


--
Steven


Groetjes Albert


Note that you forgot applying enough heat to do the cooking.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Albert van der Horst]

In article ,
Erik Max Francis   wrote:

>Anything's trivial to "write down."  Just say "the number such that ..."
>and you've written it down.  Even "numbers" that aren't really numbers,
>such as transfinite cardinals!

Now it isn't trivial to write down.
It has been proven (of course in an anti-intuitionistic 1] ,
Cantor-universe) that there is always a larger cardinal, and that
there is no consistent way to write them down. In other ways, you
have to keep inventing new notations, hardly a trivial matter.
See also Hofstaedter: Goedel, Escher, Bach.

>
>--
>Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/

Groetjes Albert

1] The likes of Brouwer found these silly exercises.)

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Chris Angelico]

On Tue, Jul 24, 2012 at 2:18 AM, Albert van der Horst
 wrote:
> Example from recipee's:
>
> Stirr until the egg white is stiff.
>
> Alternative:
> Stirr egg white for half an hour,
> but if the egg white is stiff keep your spoon still.
>
> (Cooking is not my field of expertise, so the wording may
> not be quite appropriate. )

Method.
Take egg white from refrigerator.
Put egg white into mixing bowl.
Stir for 30 minutes.
Stir the egg white.
Stir the egg white until stirred.

That's valid code, incidentally. Not Python code, but it is
executable. And it includes a useless count-down-to-zero loop.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Albert van der Horst]

In article <5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano   wrote:
Even with a break, why bother continuing through the body of the function
>when you already have the result? When your calculation is done, it's
>done, just return for goodness sake. You wouldn't write a search that
>keeps going after you've found the value that you want, out of some
>misplaced sense that you have to look at every value. Why write code with
>unnecessary guard values and temporary variables out of a misplaced sense
>that functions must only have one exit?

Example from recipee's:

Stirr until the egg white is stiff.

Alternative:
Stirr egg white for half an hour,
but if the egg white is stiff keep your spoon still.

(Cooking is not my field of expertise, so the wording may
not be quite appropriate. )

>--
>Steven

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Erik Max Francis]

On 07/20/2012 03:28 AM, BartC wrote:

"Erik Max Francis"  wrote in message
news:gskdnwoqpkoovztnnz2dnuvz5s2dn...@giganews.com...

On 07/20/2012 01:11 AM, Steven D'Aprano wrote:

On Thu, 19 Jul 2012 13:50:36 -0500, Tim Chase wrote:



I'm reminded of Graham's Number, which is so large that there aren't
enough molecules in the universe to write it out as a power tower
a^b^c^d^..., or even in a tower of hyperpowers a^^b^^c^^d^^... It was
the
provable upper bound to a question to which experts in the field thought
the most likely answer was ... six.

(The bounds have since been reduced: the lower bound is now 13, and the
upper bound is *much* smaller than Graham's Number but still
inconceivably ginormous.)


You don't even need to go that high. Even a run-of-the-mill googol
(10^100) is far larger than the total number of elementary particles in
the observable Universe.


But you can write it down, even as a straightforward number, without any
problem. Perhaps a googolplex (10^10^100 iirc) would be difficult to
write it down in full, but I have just represented it as an exponent
with little difficulty.

These bigger numbers can't be written down, because there will never be
enough material, even using multiple systems of exponents.


But that's true for precisely the same reason as what I said.  If you're 
going to write a number down in standard format (whatever the base), 
then the number of digits needed scales as the logarithm of the number 
(again, whatever the base).  log_10 10^100 is trivially 100, so a rough 
order of magnitude in that form is easy to write down.  But the log_10 
10^10^100 is 10^100 = a googol, which is already more than the number of 
elementary particles in the observable Universe.



(A few years ago the biggest number I'd heard of was Skewes' Number
(something like 10^10^10^34), but even that is trivial to write using
conventional exponents as I've just shown. Graham's Number is in a
different
class altogether.)


Anything's trivial to "write down."  Just say "the number such that ..." 
and you've written it down.  Even "numbers" that aren't really numbers, 
such as transfinite cardinals!


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Jabber erikmaxfrancis
  She's your moon, she's your sun / She could even be the one
   -- Nik Kershaw
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Erik Max Francis]

On 07/20/2012 02:05 AM, Virgil Stokes wrote:

On 20-Jul-2012 10:27, Steven D'Aprano wrote:

The fellow looked relived and said "Oh thank god, I thought you said
*million*!"


How does this relate to the python list?


It's also a seriously old joke.

--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Jabber erikmaxfrancis
  She's your moon, she's your sun / She could even be the one
   -- Nik Kershaw
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Hans Mulder]

On 20/07/12 11:05:09, Virgil Stokes wrote:
> On 20-Jul-2012 10:27, Steven D'Aprano wrote:
>> On Fri, 20 Jul 2012 08:20:57 +1000, Chris Angelico wrote:
>>
>Since the current evidence indicates the universe will just
> keep
> expanding, it's more of a "deep freeze death..."
 Heat death means *lack* of heat.
>>> The second law of thermodynamics states that energy tends to go from
>>> higher states to lower, with heat being the very lowest. It's possible
>>> to do work using (say) kinetic energy, and in the process, some of that
>>> energy becomes heat. It's also possible to do work with any difference
>>> in temperature (eg Stirling engines), so the state of the universe in
>>> which it's no longer possible to do any work will be one in which all
>>> energy is heat and everything's at the same temperature. That doesn't
>>> mean a lack of heat; in fact, it implies that there'll be rather more
>>> heat than there now is, because we currently have a whole lot of
>>> chemical energy available to be used.
>> Yes, but the point is, that heat will be *incredibly* diffuse,
>> essentially spread over the entire universe, which will be MUCH bigger
>> than it is now, and hence the temperature will be low even though the
>> total amount of heat will be high.
>>
>> The average temperature of the universe now is about 2.7 degrees above
>> absolute zero (i.e. 2.7 K, -270.45 C or -454.81 F), with individual
>> hotspots reaching into millions of degrees or higher. By the time the
>> last of the stars burn out, the average temperature will be a minuscule
>> fraction of a degree above absolute zero, and the only hotspots will be
>> the slowly cooling neutron stars.
>>
>>
>>> But in any case, that's a long way off...
>> I once went to an astronomy lecture where the lecturer was talking about
>> the eventual death of the sun. He said, "In about 10 billion years, the
>> sun will consume almost all of its fuel. It will cool and expand into a
>> red giant, and the earth will be engulfed by the expanded sun and
>> destroyed."
>>
>> This fellow sitting next to me got all agitated, stood up and cried out,
>> "Does the government know about this? We have to do something!"
>>
>> The lecturer said "Don't worry sir, there's no need to panic, this won't
>> happen for billions of years."
>>
>> The fellow looked relived and said "Oh thank god, I thought you said
>> *million*!"
>>
> How does this relate to the python list?

This thread is as coherent as a typical episode of
Monty Python's Flying Circus :-)


-- HansM

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[BartC]

"Erik Max Francis"  wrote in message
news:gskdnwoqpkoovztnnz2dnuvz5s2dn...@giganews.com...

On 07/20/2012 01:11 AM, Steven D'Aprano wrote:

On Thu, 19 Jul 2012 13:50:36 -0500, Tim Chase wrote:



I'm reminded of Graham's Number, which is so large that there aren't
enough molecules in the universe to write it out as a power tower
a^b^c^d^..., or even in a tower of hyperpowers a^^b^^c^^d^^... It was the
provable upper bound to a question to which experts in the field thought
the most likely answer was ... six.

(The bounds have since been reduced: the lower bound is now 13, and the
upper bound is *much* smaller than Graham's Number but still
inconceivably ginormous.)


You don't even need to go that high.  Even a run-of-the-mill googol
(10^100) is far larger than the total number of elementary particles in
the observable Universe.


But you can write it down, even as a straightforward number, without any 
problem. Perhaps a googolplex (10^10^100 iirc) would be difficult to write 
it down in full, but I have just represented it as an exponent with little 
difficulty.


These bigger numbers can't be written down, because there will never be
enough material, even using multiple systems of exponents.

(A few years ago the biggest number I'd heard of was Skewes' Number
(something like 10^10^10^34), but even that is trivial to write using
conventional exponents as I've just shown. Graham's Number is in a different
class altogether.)

--
Bartc 


--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Virgil Stokes]

On 20-Jul-2012 10:27, Steven D'Aprano wrote:

On Fri, 20 Jul 2012 08:20:57 +1000, Chris Angelico wrote:


   Since the current evidence indicates the universe will just keep
expanding, it's more of a "deep freeze death..."

Heat death means *lack* of heat.

The second law of thermodynamics states that energy tends to go from
higher states to lower, with heat being the very lowest. It's possible
to do work using (say) kinetic energy, and in the process, some of that
energy becomes heat. It's also possible to do work with any difference
in temperature (eg Stirling engines), so the state of the universe in
which it's no longer possible to do any work will be one in which all
energy is heat and everything's at the same temperature. That doesn't
mean a lack of heat; in fact, it implies that there'll be rather more
heat than there now is, because we currently have a whole lot of
chemical energy available to be used.

Yes, but the point is, that heat will be *incredibly* diffuse,
essentially spread over the entire universe, which will be MUCH bigger
than it is now, and hence the temperature will be low even though the
total amount of heat will be high.

The average temperature of the universe now is about 2.7 degrees above
absolute zero (i.e. 2.7 K, -270.45 C or -454.81 F), with individual
hotspots reaching into millions of degrees or higher. By the time the
last of the stars burn out, the average temperature will be a minuscule
fraction of a degree above absolute zero, and the only hotspots will be
the slowly cooling neutron stars.



But in any case, that's a long way off...

I once went to an astronomy lecture where the lecturer was talking about
the eventual death of the sun. He said, "In about 10 billion years, the
sun will consume almost all of its fuel. It will cool and expand into a
red giant, and the earth will be engulfed by the expanded sun and
destroyed."

This fellow sitting next to me got all agitated, stood up and cried out,
"Does the government know about this? We have to do something!"

The lecturer said "Don't worry sir, there's no need to panic, this won't
happen for billions of years."

The fellow looked relived and said "Oh thank god, I thought you said
*million*!"




How does this relate to the python list?

"This mailing list is a general discussion list for the Python programming 
language." --- from http://mail.python.org/mailman/listinfo/python-list/

--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Erik Max Francis]

On 07/20/2012 01:11 AM, Steven D'Aprano wrote:

On Thu, 19 Jul 2012 13:50:36 -0500, Tim Chase wrote:


On 07/19/12 13:28, Chris Angelico wrote:

On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase
  wrote:

Sure it terminates...If you don't run out of RAM to represent the
number "i" in question, there's also this "heat death of the universe"
limit I keep hearing about ;-)


I'd be more worried about the heat death of your computer, it's likely
to be sooner. How many people have access to a computer that'll still
be running in ten years, much less a thousand?


Just putting a maximum bound on the problem, providing a time-frame in
which I can be fairly certain that the program will have terminated. :-)


I'm reminded of Graham's Number, which is so large that there aren't
enough molecules in the universe to write it out as a power tower
a^b^c^d^..., or even in a tower of hyperpowers a^^b^^c^^d^^... It was the
provable upper bound to a question to which experts in the field thought
the most likely answer was ... six.

(The bounds have since been reduced: the lower bound is now 13, and the
upper bound is *much* smaller than Graham's Number but still
inconceivably ginormous.)


You don't even need to go that high.  Even a run-of-the-mill googol 
(10^100) is far larger than the total number of elementary particles in 
the observable Universe.


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Jabber erikmaxfrancis
  I think it is safe to say that no one understands quantum mechanics.
   -- Richard P. Feynman
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Mark Lawrence]

On 19/07/2012 22:13, Ian Kelly wrote:

On Thu, Jul 19, 2012 at 3:01 PM, John Gordon  wrote:

In  Dennis Lee Bieber 
 writes:


Sure it terminates...If you don't run out of RAM to represent the
number "i" in question, there's also this "heat death of the
universe" limit I keep hearing about ;-)


   Since the current evidence indicates the universe will just keep
expanding, it's more of a "deep freeze death..."


Heat death means *lack* of heat.


Actually actually it means *uniformity* of heat, i.e. that the entire
universe is in thermodynamic equilibrium and so it is impossible to
perform work.  So heat death is expected regardless of whether the
universe ultimately collapses or expands indefinitely.



All of this will pale into complete insignificance provided that England 
beat South Africa in the current cricket test match series and retain 
their world no.1 ranking.  Of course if they lose the universe will 
collapse immediately or expand so far that it tears itself to tiny 
little pieces.  Even The Ashes won't survive, something I should perhaps 
take up with the MCC.


--
Cheers.

Mark Lawrence.



--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Fri, 20 Jul 2012 08:20:57 +1000, Chris Angelico wrote:

>>>   Since the current evidence indicates the universe will just keep
>>> expanding, it's more of a "deep freeze death..."
>>
>> Heat death means *lack* of heat.
> 
> The second law of thermodynamics states that energy tends to go from
> higher states to lower, with heat being the very lowest. It's possible
> to do work using (say) kinetic energy, and in the process, some of that
> energy becomes heat. It's also possible to do work with any difference
> in temperature (eg Stirling engines), so the state of the universe in
> which it's no longer possible to do any work will be one in which all
> energy is heat and everything's at the same temperature. That doesn't
> mean a lack of heat; in fact, it implies that there'll be rather more
> heat than there now is, because we currently have a whole lot of
> chemical energy available to be used.

Yes, but the point is, that heat will be *incredibly* diffuse, 
essentially spread over the entire universe, which will be MUCH bigger 
than it is now, and hence the temperature will be low even though the 
total amount of heat will be high.

The average temperature of the universe now is about 2.7 degrees above 
absolute zero (i.e. 2.7 K, -270.45 C or -454.81 F), with individual 
hotspots reaching into millions of degrees or higher. By the time the 
last of the stars burn out, the average temperature will be a minuscule 
fraction of a degree above absolute zero, and the only hotspots will be 
the slowly cooling neutron stars.


> But in any case, that's a long way off...

I once went to an astronomy lecture where the lecturer was talking about 
the eventual death of the sun. He said, "In about 10 billion years, the 
sun will consume almost all of its fuel. It will cool and expand into a 
red giant, and the earth will be engulfed by the expanded sun and 
destroyed."

This fellow sitting next to me got all agitated, stood up and cried out, 
"Does the government know about this? We have to do something!"

The lecturer said "Don't worry sir, there's no need to panic, this won't 
happen for billions of years."

The fellow looked relived and said "Oh thank god, I thought you said 
*million*!"



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Thu, 19 Jul 2012 13:50:36 -0500, Tim Chase wrote:

> On 07/19/12 13:28, Chris Angelico wrote:
>> On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase
>>  wrote:
>>> Sure it terminates...If you don't run out of RAM to represent the
>>> number "i" in question, there's also this "heat death of the universe"
>>> limit I keep hearing about ;-)
>> 
>> I'd be more worried about the heat death of your computer, it's likely
>> to be sooner. How many people have access to a computer that'll still
>> be running in ten years, much less a thousand?
> 
> Just putting a maximum bound on the problem, providing a time-frame in
> which I can be fairly certain that the program will have terminated. :-)

I'm reminded of Graham's Number, which is so large that there aren't 
enough molecules in the universe to write it out as a power tower 
a^b^c^d^..., or even in a tower of hyperpowers a^^b^^c^^d^^... It was the 
provable upper bound to a question to which experts in the field thought 
the most likely answer was ... six.

(The bounds have since been reduced: the lower bound is now 13, and the 
upper bound is *much* smaller than Graham's Number but still 
inconceivably ginormous.)

http://en.wikipedia.org/wiki/Graham%27s_number



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Devin Jeanpierre]

On Thu, Jul 19, 2012 at 5:01 PM, John Gordon  wrote:
>>   Since the current evidence indicates the universe will just keep
>> expanding, it's more of a "deep freeze death..."
>
> Heat death means *lack* of heat.

But it doesn't mean low temperature! The term is agnostic as to what
the temperature of the universe will be.

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Ian Kelly]

On Thu, Jul 19, 2012 at 3:01 PM, John Gordon  wrote:
> In  Dennis Lee Bieber 
>  writes:
>
>> > Sure it terminates...If you don't run out of RAM to represent the
>> > number "i" in question, there's also this "heat death of the
>> > universe" limit I keep hearing about ;-)
>> >
>>   Since the current evidence indicates the universe will just keep
>> expanding, it's more of a "deep freeze death..."
>
> Heat death means *lack* of heat.

Actually actually it means *uniformity* of heat, i.e. that the entire
universe is in thermodynamic equilibrium and so it is impossible to
perform work.  So heat death is expected regardless of whether the
universe ultimately collapses or expands indefinitely.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Thu, 19 Jul 2012 09:06:45 -0400, Roy Smith wrote:

> Heh.  This reminds me of one of my current pet peeves.  I've run across
> documentation for more than one Python project (django is the one that
> comes to mind, but I'm sure there's others) which misuse words like
> "set" and "list".  They're often used in the generic sense of "a
> collection of things", but they're also the names of specific Python
> data types.  It can sometimes get confusing trying to figure out which
> meaning they intended.

Now that is confusing!

Writing good documentation is *hard*. I often end up writing more 
documentation than code, sometimes by a factor of two. Fortunately I love 
to write. As may be obvious.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[John Gordon]

In  Chris Angelico 
 writes:

> The second law of thermodynamics states that energy tends to go from
> higher states to lower, with heat being the very lowest. It's possible
> to do work using (say) kinetic energy, and in the process, some of
> that energy becomes heat. It's also possible to do work with any
> difference in temperature (eg Stirling engines), so the state of the
> universe in which it's no longer possible to do any work will be one
> in which all energy is heat and everything's at the same temperature.
> That doesn't mean a lack of heat; in fact, it implies that there'll be
> rather more heat than there now is, because we currently have a whole
> lot of chemical energy available to be used.

*mind blown*

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Chris Angelico]

On Fri, Jul 20, 2012 at 7:01 AM, John Gordon  wrote:
> In  Dennis Lee Bieber 
>  writes:
>
>> > Sure it terminates...If you don't run out of RAM to represent the
>> > number "i" in question, there's also this "heat death of the
>> > universe" limit I keep hearing about ;-)
>> >
>>   Since the current evidence indicates the universe will just keep
>> expanding, it's more of a "deep freeze death..."
>
> Heat death means *lack* of heat.

The second law of thermodynamics states that energy tends to go from
higher states to lower, with heat being the very lowest. It's possible
to do work using (say) kinetic energy, and in the process, some of
that energy becomes heat. It's also possible to do work with any
difference in temperature (eg Stirling engines), so the state of the
universe in which it's no longer possible to do any work will be one
in which all energy is heat and everything's at the same temperature.
That doesn't mean a lack of heat; in fact, it implies that there'll be
rather more heat than there now is, because we currently have a whole
lot of chemical energy available to be used.

But in any case, that's a long way off...

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[OKB (not okblacke)]

MRAB wrote:

> """Thus spake the Lord: Thou shalt indent with four spaces. No
> more, no less.
> Four shall be the number of spaces thou shalt indent, and the
> number of thy indenting shall be four. Eight shalt thou not indent,
> nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right
> out.""" 
>   -- Georg Brandl

Yes, and the Lord was Wrong.

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
--author unknown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[John Gordon]

In  Dennis Lee Bieber 
 writes:

> > Sure it terminates...If you don't run out of RAM to represent the
> > number "i" in question, there's also this "heat death of the
> > universe" limit I keep hearing about ;-)
> >
>   Since the current evidence indicates the universe will just keep
> expanding, it's more of a "deep freeze death..."

Heat death means *lack* of heat.

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Tim Chase]

On 07/19/12 13:28, Chris Angelico wrote:
> On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase
>  wrote:
>> Sure it terminates...If you don't run out of RAM to represent the
>> number "i" in question, there's also this "heat death of the
>> universe" limit I keep hearing about ;-)
> 
> I'd be more worried about the heat death of your computer, it's likely
> to be sooner. How many people have access to a computer that'll still
> be running in ten years, much less a thousand?

Just putting a maximum bound on the problem, providing a time-frame
in which I can be fairly certain that the program will have
terminated. :-)

-tkc


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Chris Angelico]

On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase
 wrote:
> Sure it terminates...If you don't run out of RAM to represent the
> number "i" in question, there's also this "heat death of the
> universe" limit I keep hearing about ;-)

I'd be more worried about the heat death of your computer, it's likely
to be sooner. How many people have access to a computer that'll still
be running in ten years, much less a thousand? And while a thousand
years is extremely large, it still falls pitifully short of
infinity[1], or even the heat death of the universe.

ChrisA
[1] http://tools.ietf.org/html/rfc2795
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Tim Chase]

> If you think that people can routinely detect infinite loops, then 
> perhaps you would care to tell me whether this is an infinite loop or not:
> 
> i = 1
> while not is_perfect(i):
> i += 2
> print "odd perfect number discovered"
> 
> 
> where is_perfect() returns True if the integer argument is perfect, and 
> False otherwise.

Sure it terminates...If you don't run out of RAM to represent the
number "i" in question, there's also this "heat death of the
universe" limit I keep hearing about ;-)

-tkc


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Paul Rudin]

Steven D'Aprano  writes:

> For example, both ML and Haskell can, under some circumstances, report a 
> type-error for an infinite loop, *at compile time*.

... and in Charity all programs are guaranteed to terminate. Of course
it's not Turing complete.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[rusi]

On Jul 19, 1:56 pm, Lipska the Kat  wrote:
> Academic twiddling with the distorted meaning of words spun by
> vested interests is all very interesting I'm sure but doesn't really
> advance the discussion does it?

Well lets back up the discussion a bit. You coming from a Java
background have one view of what OO means. Others coming from a python
background have a different view. In particular you said:

> Python looks like an interesting language and I will certainly spend
> time getting to know it but at the moment it seems to me that calling it
> an Object Oriented language is just plain misleading.


> On 19/07/12 07:09, rusi wrote:
> > In layman-speak and object is well, a thing.
>
> But we are not talking in 'layman-speak' we are discussing concepts that
> are familiar to us in the 'language of the domain' at least I though we
> were.


> > And one of the most pervasive (and stupidist) metaphors is the parent-
> > child relation of classes.
> > Just for the record, in the normal world 'creatures/beings' reproduce
> > and therefore inherit.
>
> But we are not talking about the 'real world' are we, we are talking
> about representing complex interacting human concepts in a way that can
> be understood by humans and translated into a form that can be executed
> on a binary machine

So when multiple technical understandings are in conflict it seems
reasonable to find a frame in which the different viewpoints could
resolve.  The ultimate such frame is the completely de-jargonized
frame ie laymanspeak.  [How far one can/should go toward that ultimate
is another quesion]


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Roy Smith]

In article <500804cc$0$29978$c3e8da3$54964...@news.astraweb.com>,
 Steven D'Aprano  wrote:

> On Wed, 18 Jul 2012 23:09:13 -0700, rusi wrote:
> 
> > Its not so much a question of language as in programming as language as
> > in layman-speak.
> > One characteristic with our field is that we take ordinary words and
> > then distort them so much the original meaning is completely lost.
> 
> All technical fields have jargon. Those jargon terms are often more 
> precise than the ordinary terms they are derived from, or have a slightly 
> different meaning, or both.

Heh.  This reminds me of one of my current pet peeves.  I've run across 
documentation for more than one Python project (django is the one that 
comes to mind, but I'm sure there's others) which misuse words like 
"set" and "list".  They're often used in the generic sense of "a 
collection of things", but they're also the names of specific Python 
data types.  It can sometimes get confusing trying to figure out which 
meaning they intended.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Wed, 18 Jul 2012 23:09:13 -0700, rusi wrote:

> Its not so much a question of language as in programming as language as
> in layman-speak.
> One characteristic with our field is that we take ordinary words and
> then distort them so much the original meaning is completely lost.

All technical fields have jargon. Those jargon terms are often more 
precise than the ordinary terms they are derived from, or have a slightly 
different meaning, or both.

This is not unique to programming, nor is it anything to be disturbed by. 
Words change. What matters is whether the new meanings cause confusion or 
clarity.


> Take 'computer' for example.  For Turing a computer was a mathematician
> doing a computation with a pen and paper.  He then showed how to
> de-skill the mathematician so much that a machine could do what he was
> doing.  In trying that he also hit upon the limits of such 'de-skilling'
> -- human-computers routinely detect infinite loops, whereas
> machine-computers can never do so (in full generality).

Do they really? I doubt that. Human-computers *sometimes* detect infinite 
loops, but there's no evidence that they can detect ∞-loops in full 
generality, or even that they are better at it than electrical computers.

In fact, the sheer number of accidental ∞-loops programmed by human 
beings suggests that people *cannot* routinely detect them, at least not 
without special training, and even then not *routinely*.

Generally people detect ∞-loops with an extremely simple-minded 
heuristic: "if the loop hasn't finished by now, it will never finish".

The fact that we don't, as a general rule, program our computers to 
detect ∞-loops does not mean that they cannot do so at least as well as 
humans, and probably better, when we bother to program them to.

For example, both ML and Haskell can, under some circumstances, report a 
type-error for an infinite loop, *at compile time*.

http://static.usenix.org/publications/library/proceedings/vhll/full_papers/koenig.a

If you think that people can routinely detect infinite loops, then 
perhaps you would care to tell me whether this is an infinite loop or not:

i = 1
while not is_perfect(i):
i += 2
print "odd perfect number discovered"


where is_perfect() returns True if the integer argument is perfect, and 
False otherwise.

http://mathworld.wolfram.com/PerfectNumber.html
http://mathworld.wolfram.com/OddPerfectNumber.html


 
[...]
> 'Object' (and OO) are similar messes.
> 
> In layman-speak and object is well, a thing.

Define "thing".

Is a cloud a thing? What about a fog bank? An ocean?

A desert? The atmosphere?

Is the paint on your car a thing?

I have an axe that has been passed down for generations through my 
family, from my father, his father before him, and his father, and his 
father before him. Occasionally we replace the handle, or put on a new 
head, but that axe is almost as good as the day my great-great-
grandfather made it.

Is that axe a thing?

Just because laymen toss around a word, doesn't mean that it is a well-
defined, meaningful word.


> When it doesn't the success is poorer. eg a programmer writing math
> software in/on a OO system may for example 'clone' a matrix.  This may
> be good science-fiction; its bad math.

In what way is it bad maths?



> And one of the most pervasive (and stupidist) metaphors is the parent-
> child relation of classes.
> Just for the record, in the normal world 'creatures/beings' reproduce
> and therefore inherit.

Incorrect. In the normal world, "inherit" is used for at least four 
senses:

1) to inherit wealth, property, a title, debts etc. from an ancestor 
   upon their death;

2) to receive or take by birth, to have by nature, physical or mental
   qualities, e.g. "he inherited his tendency to melancholy from his
   father";

3) to come into possession of, e.g. "the meek shall inherit the earth";

4) to receive from a predecessor, e.g. "the Prime Minister has inherited
   an economy in dire straits".

It is clear that the sense of inheritance used in OO programming is sense 
#2, to have by nature.


> Objects dont.

Irrelevant.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 19/07/12 07:09, rusi wrote:

On Jul 19, 6:34 am, Steven D'Aprano  wrote:

On Wed, 18 Jul 2012 15:40:00 +0100, Lipska the Kat wrote:

Object Oriented programming is all about encapsulating human concepts in
a way that makes sense to human beings. Make no mistake, it is NEVER the
case that a software system is written for any other reason than to
serve human beings. OO is more than just the mechanics of writing code,
it's a state of mind.


Um, yes?



Its not so much a question of language as in programming as language
as in layman-speak.
One characteristic with our field is that we take ordinary words and
then distort them so much the original meaning is completely lost.

Take 'computer' for example.  For Turing a computer was a
mathematician doing a computation with a pen and paper.  He then
showed how to de-skill the mathematician so much that a machine could
do what he was doing.  In trying that he also hit upon the limits of
such 'de-skilling' -- human-computers routinely detect infinite loops,
whereas machine-computers can never do so (in full generality).

Ironically the important lesson is lost and today 'computer' is
synonymous with machine.

Here is Dijkstra on similar distortions with 'user' and
'intelligent':
http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD618.html

'Object' (and OO) are similar messes.


Well this is all very interesting.

The terminology is quite concise if you allow it to be
Take "An Object is an instance of a Class"

A Class describes a human concept (be it concrete like a 'Parrot' or 
more abstract like a 'Session') an Object is an actual representation of 
that concept that exists in the memory of a computer (what else should 
we call it). Objects don't exist in the mind of a human, concepts do. A 
class is a way of representing that concept so that other humans can 
understand it. That's it, really, there is no more, anything else is 
implementation.



In layman-speak and object is well, a thing.


But we are not talking in 'layman-speak' we are discussing concepts that 
are familiar to us in the 'language of the domain' at least I though we 
were. Academic twiddling with the distorted meaning of words spun by 
vested interests is all very interesting I'm sure but doesn't really 
advance the discussion does it?



- subject to space-laws like can only exist at one place at a time,
there cannot be two objects at the same place and time etc.
- subject to time-laws like coming into existence at some time and
going out at some other
- connotes inanimateness unlike other 'creatures' or 'beings'.


Well here I have to agree with you. Anyone who invents a 'Person' Class 
should be dismissed forthwith. Parrots are OK though.



When this metaphor works (for example as in guis and simulation) then
we have success-stories like smalltalk and simula.

When it doesn't the success is poorer. eg a programmer writing math
software in/on a OO system may for example 'clone' a matrix.  This may
be good science-fiction; its bad math.

And one of the most pervasive (and stupidist) metaphors is the parent-
child relation of classes.
Just for the record, in the normal world 'creatures/beings' reproduce
and therefore inherit.


But we are not talking about the 'real world' are we, we are talking 
about representing complex interacting human concepts in a way that can 
be understood by humans and translated into a form that can be executed 
on a binary machine


> Objects dont.

Well they do, it's a fact, you can call a method on a sub class that 
only exists in the super class. What else would you call it.


Well it's been fun but I have bills to pay so I suppose I'd better do 
some work. TTFN



--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Terry Reedy]

On 7/18/2012 10:40 AM, Lipska the Kat wrote:


fact ... and I have never been forced to admit that I don't know what I
wrote six months ago.


That is an explicit objective of Python's design.


Python looks like an interesting language and I will certainly spend
time getting to know it but at the moment it seems to me that calling it
an Object Oriented language is just plain misleading.


I just call it object-based and let be done with it, as I have no 
interest in arguing 'Object Oriented'.


What perhaps *you* need to know, given your background, is that nearly 
all syntax and most builtin callables wrap special method calls that can 
be defined on user classes.


'a + b' is executed as something like

try:
  return a.__add__(b)  # or the C type slot equivalent
except: # not sure what is actually caught
  try:
return b.__radd__(a)  # r(everse)add
  except: # ditto
raise TypeError("unsupported operand type(s) for +: {} and 
{}".format(a, b))


[Syntax exceptions: =, and, or]

'len(x)' calls x.__len__ and checks that the return value can be 
interpreted as an integer (I believe that means that it is an int or has 
an __index__ method, so that it can be used as a sequence index) and 
that its value is >= 0.


--
Terry Jan Reedy



--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[rusi]

On Jul 19, 6:34 am, Steven D'Aprano  wrote:
> On Wed, 18 Jul 2012 15:40:00 +0100, Lipska the Kat wrote:
> > Object Oriented programming is all about encapsulating human concepts in
> > a way that makes sense to human beings. Make no mistake, it is NEVER the
> > case that a software system is written for any other reason than to
> > serve human beings. OO is more than just the mechanics of writing code,
> > it's a state of mind.
>
> Um, yes?

Its not so much a question of language as in programming as language
as in layman-speak.
One characteristic with our field is that we take ordinary words and
then distort them so much the original meaning is completely lost.

Take 'computer' for example.  For Turing a computer was a
mathematician doing a computation with a pen and paper.  He then
showed how to de-skill the mathematician so much that a machine could
do what he was doing.  In trying that he also hit upon the limits of
such 'de-skilling' -- human-computers routinely detect infinite loops,
whereas machine-computers can never do so (in full generality).

Ironically the important lesson is lost and today 'computer' is
synonymous with machine.

Here is Dijkstra on similar distortions with 'user' and
'intelligent':
http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD618.html

'Object' (and OO) are similar messes.

In layman-speak and object is well, a thing.

- subject to space-laws like can only exist at one place at a time,
there cannot be two objects at the same place and time etc.
- subject to time-laws like coming into existence at some time and
going out at some other
- connotes inanimateness unlike other 'creatures' or 'beings'.

When this metaphor works (for example as in guis and simulation) then
we have success-stories like smalltalk and simula.

When it doesn't the success is poorer. eg a programmer writing math
software in/on a OO system may for example 'clone' a matrix.  This may
be good science-fiction; its bad math.

And one of the most pervasive (and stupidist) metaphors is the parent-
child relation of classes.
Just for the record, in the normal world 'creatures/beings' reproduce
and therefore inherit.
Objects dont.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Chris Angelico]

On Thu, Jul 19, 2012 at 11:22 AM, Steven D'Aprano
 wrote:
> On Thu, 19 Jul 2012 01:04:50 +1000, Chris Angelico wrote:
>
>> Python isn't object oriented in the way Java is ("EVERYTHING has to be
>> in a class! Look, it's all OO now!").
>
> Actually, Python is more object-oriented than Java. In Python, everything
> is an object. We have no distinction between boxed and unboxed integers,
> for example -- all integers are boxed, always.

That was my point. Less hype about OO but everything really is an object.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Wed, 18 Jul 2012 15:40:00 +0100, Lipska the Kat wrote:
[...]
>> Even with a break, why bother continuing through the body of the
>> function when you already have the result? When your calculation is
>> done, it's done, just return for goodness sake. You wouldn't write a
>> search that keeps going after you've found the value that you want, out
>> of some misplaced sense that you have to look at every value. Why write
>> code with unnecessary guard values and temporary variables out of a
>> misplaced sense that functions must only have one exit?
> 
> Object Oriented programming is all about encapsulating human concepts in
> a way that makes sense to human beings. Make no mistake, it is NEVER the
> case that a software system is written for any other reason than to
> serve human beings. OO is more than just the mechanics of writing code,
> it's a state of mind.

Um, yes?

I'm no sure what this has to do with single-exit functions/methods. You 
can just as easily write multi-exit methods in an OO language as in a non-
OO language. So long as your language has a return statement which exits 
the function, you can have more than one.

I am aware that some languages enforce a single exit point, but that 
seems to be an unnecessary restriction to me.

Of course it does require discipline and/or sense to not write crap code: 
if you have a 300 line function or method, whether it has dozens of exits 
or just one, that is crap code in any language. But if the choice is to 
write a 20 line function with three exits, or a 30 line function with a 
single exit, there would have to be a good reason to prefer the single-
exit version.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[MRAB]

On 19/07/2012 02:14, Steven D'Aprano wrote:

On Wed, 18 Jul 2012 15:48:28 +0100, Lipska the Kat wrote:


On 18/07/12 15:34, Grant Edwards wrote:



Unless you're asking about the tabs vs. spaces argument.  In that case,
people who use 4 spaces per level are 'correct'; people who use a
different number of spaces are a bit less correct; people who use tabs
are wrong;


hmm, I've been using tabs ... still, why use one key press when you can
use 4 ;-).


My editor lets me add four spaces with a single key press, and delete
them again with another single key press.

Personally, I think tabs make more sense for indents than spaces, but for
compatibility with others who are not as enlightened and insist on using
broken tools that cannot deal with tabs, I have reluctantly standardised
on spaces for indentation.

"""Thus spake the Lord: Thou shalt indent with four spaces. No more, no 
less.

Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent 
thou

two, excepting that thou then proceed to four. Tabs are right out."""
 -- Georg Brandl

--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Thu, 19 Jul 2012 01:04:50 +1000, Chris Angelico wrote:

> Python isn't object oriented in the way Java is ("EVERYTHING has to be
> in a class! Look, it's all OO now!").

Actually, Python is more object-oriented than Java. In Python, everything 
is an object. We have no distinction between boxed and unboxed integers, 
for example -- all integers are boxed, always.

(Of course, data structures written in C, for example the array type, can 
encapsulate unboxed native ints. But the array itself is still an object.)

On the other hand, Python doesn't force you to program using an object-
oriented style. If you want to write functional code like Haskell, you 
can. If you want to write Pascal-style procedural code, you can. If you 
prefer an imperative style closer to shell scripting, go right ahead. The 
only one of the major paradigms that Python doesn't naturally support is 
logic programming.

So Python is simultaneously more *and* less object-oriented than Java.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Wed, 18 Jul 2012 12:33:01 -0400, Dave Angel wrote:

> On 07/18/2012 08:58 AM, Steven D'Aprano wrote:

>> 
>> For bonus points, can you see the mistake?
[...]
>>
> There are actually two bugs in that function.  One is in the assertion,
> but more importantly, there's a typo earlier.  One that would give a
> traceback, so it would be caught quickly.
> 
> UnboundLocalError: local variable 'x' referenced before assignment

Good catch :)



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Wed, 18 Jul 2012 15:48:28 +0100, Lipska the Kat wrote:

> On 18/07/12 15:34, Grant Edwards wrote:

>> Unless you're asking about the tabs vs. spaces argument.  In that case,
>> people who use 4 spaces per level are 'correct'; people who use a
>> different number of spaces are a bit less correct; people who use tabs
>> are wrong;
> 
> hmm, I've been using tabs ... still, why use one key press when you can
> use 4 ;-).  

My editor lets me add four spaces with a single key press, and delete 
them again with another single key press.

Personally, I think tabs make more sense for indents than spaces, but for 
compatibility with others who are not as enlightened and insist on using 
broken tools that cannot deal with tabs, I have reluctantly standardised 
on spaces for indentation.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[BartC]

"Lipska the Kat"  wrote in message 
news:c76dnv778_sw4zvnnz2dnuvz8ukdn...@bt.com...

On 18/07/12 01:46, Andrew Cooper wrote:



if not (you are permitted to do this):
 return -EPERM
if not (you've given me some valid data):
 return -EFAULT
if not (you've given me some sensible data):
 return -EINVAL
return actually_try_to_do_something_with(data)

How would you program this sort of logic with a single return statement?
  This is very common logic for all routines for which there is even the
remotest possibility that some data has come from an untrusted source.




someType result = -EINVAL //or your most likely or 'safest' result

if not (you are permitted to do this):
  result = -EPERM
if not (you've given me some valid data):
  result = -EFAULT
if not (you've given me some sensible data):
  result = -EINVAL
else
  result = -EDSOMETHING

  return result
}
//cohesive, encapsulated, reusable and easy to read


But, it works differently from the above. Perhaps replace some of those "if" 
statements with "elif".


The "return" version is handy because it provides a quick escape mechanism 
without cluttering up the rest of code with extra variables.


--
Bartc 


--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Dave Angel]

On 07/18/2012 08:58 AM, Steven D'Aprano wrote:
> 
>
>
> 2) To check your internal reasoning in a function or method.
>
> For example:
>
> def foo(something):
> n = len(something)
> x = math.sqrt(x)
> # We expect that x must be less than half of n. 
> # E.g. n=100 gives 10 < 50, which is correct.
> assert x < n//2
> process(n, x)
>
>
> 
> For bonus points, can you see the mistake? The stated condition is wrong. 
> Without the assert, the process() code could go off and potentially 
> silently do the wrong thing, but the assert guards against that 
> possibility. And once I've had a bug report that my app raises an 
> AssertionError, I will go back and think more carefully about the 
> assertion that sqrt(n) is always less than half of n.
>
>

There are actually two bugs in that function.  One is in the assertion,
but more importantly, there's a typo earlier.  One that would give a
traceback, so it would be caught quickly.

UnboundLocalError: local variable 'x' referenced before assignment

Once you change the argument of sqrt() to n, then you come to the
problem you were expecting;  if n has a value of 1, 2, or 3, 4, or 5 the
assertion will fire.

-- 

DaveA


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 18/07/12 16:32, Ethan Furman wrote:

Lipska the Kat wrote:

On 18/07/12 14:05, Steven D'Aprano wrote:

Even with a break, why bother continuing through the body of the
function
when you already have the result? When your calculation is done, it's
done, just return for goodness sake. You wouldn't write a search that
keeps going after you've found the value that you want, out of some
misplaced sense that you have to look at every value. Why write code
with
unnecessary guard values and temporary variables out of a misplaced
sense
that functions must only have one exit?


Object Oriented programming is all about encapsulating human concepts
in a way that makes sense to human beings. Make no mistake, it is
NEVER the case that a software system is written for any other reason
than to serve human beings. OO is more than just the mechanics of
writing code, it's a state of mind.


I must admit I have no idea how we went from discussing Single Exit
functions to the One True Purpose of Object Oriented Programming; are
you saying that SE is one of the basic tenets of OO?


It's my fault, I get carried away sometimes. Maintainable code is one of 
the basic tenets of OO, it all seems so clear to me and I get frustrated 
when I think that others don't see the 'beauty' ... but then I come to 
my senses and realise that there is always another way to do things.



Python looks like an interesting language and I will certainly spend
time getting to know it but at the moment it seems to me that calling
it an Object Oriented language is just plain misleading.


Since *everything* in Python is an object, how can you /not/ call it an
OO language?


Obviously I can't. I can't make a call as I haven't studied the language 
yet. I just can't get my head around duck typing at the moment as it is 
just so ... different.



Sure, you don't have to use everything as an object --
plain functions exist -- kinda ;) Even functions live in some namespace:
len() lives in __builtin__, any top level function lives in its module,
etc. Oh, and namespaces are objects.

It seems to me that Python is more about providing tools, and then
staying out of your way.

That works for me. Maybe it will work for you, too.


I hope so and thank you for being so calm and reasonable in your response.



~Ethan~


Lipska


--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 18/07/12 16:09, Chris Angelico wrote:

On Thu, Jul 19, 2012 at 12:48 AM, Lipska the Kat
  wrote:

hmm, I've been using tabs ...


snip


We must meet half way, you know.


Seems reasonable to me, I'll let you suggest it ;-)


As to tab vs spaces: I'm a fan of tabs, myself. There was an argument
over the matter last year at work, and we settled on tabs because the
one guy who reckons 1-2 space indent is plenty was then able to just
set his editor to two-space tabs, and the rest of us could use a more
reasonable width. Using tab characters in the file gives this
flexibility. It separates the lexical structure ("this is three blocks
in") from the visual display ("draw these glyphs 35mm from the left
margin").


OK, I'll set my tab to 4 spaces ...

Lipska

--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Ethan Furman]

Lipska the Kat wrote:

On 18/07/12 14:05, Steven D'Aprano wrote:

Even with a break, why bother continuing through the body of the function
when you already have the result? When your calculation is done, it's
done, just return for goodness sake. You wouldn't write a search that
keeps going after you've found the value that you want, out of some
misplaced sense that you have to look at every value. Why write code with
unnecessary guard values and temporary variables out of a misplaced sense
that functions must only have one exit?


Object Oriented programming is all about encapsulating human concepts in 
a way that makes sense to human beings. Make no mistake, it is NEVER the 
case that a software system is written for any other reason than to 
serve human beings. OO is more than just the mechanics of writing code, 
it's a state of mind.


I must admit I have no idea how we went from discussing Single Exit 
functions to the One True Purpose of Object Oriented Programming;  are 
you saying that SE is one of the basic tenets of OO?



OO was 'invented' to address the many problems that beset increasingly 
complex software systems. The main problem was maintainability. 
Encapsulating a concept in a clear and concise way makes the code easier 
to understand. Sometimes this means writing code that is not 'optimal' 
for the machine. Good code should be readable as well as efficient but I 
contend that it is better to write something that is clear, concise and 
well encapsulated than always go for the 'meanest dog in the scrapyard' 
approach where a developer is determined to write unreadable code that 
shows how jolly clever he is. More often than not he is forced to admit 
six months down the line that he has no idea what his code does as he 
'forgot' to comment it.


And one of the many reasons I love Python is that it is so easy to write 
clear, readable, and sometimes concise code (nested list comps are still 
a challenge for me).


. . .

Python looks like an interesting language and I will certainly spend 
time getting to know it but at the moment it seems to me that calling it 
an Object Oriented language is just plain misleading.


Since *everything* in Python is an object, how can you /not/ call it an 
OO language?  Sure, you don't have to use everything as an object -- 
plain functions exist -- kinda ;)  Even functions live in some 
namespace: len() lives in __builtin__, any top level function lives in 
its module, etc.  Oh, and namespaces are objects.


It seems to me that Python is more about providing tools, and then 
staying out of your way.


That works for me.  Maybe it will work for you, too.

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Chris Angelico]

On Thu, Jul 19, 2012 at 12:48 AM, Lipska the Kat
 wrote:
> hmm, I've been using tabs ... still, why use one key press when you can use
> 4 ;-).  Actually I quite like this aspect of Python, it's rapidly growing on
> me. Wonder if I could introduce this in a future release of Java ... nah,
> I'd be dead within a week %-(

First let's get Python working properly. The "from __future__ import
braces" statement still doesn't work on any of the released versions.
After that, we can consider fixing Java to do the converse. We must
meet half way, you know.

As to tab vs spaces: I'm a fan of tabs, myself. There was an argument
over the matter last year at work, and we settled on tabs because the
one guy who reckons 1-2 space indent is plenty was then able to just
set his editor to two-space tabs, and the rest of us could use a more
reasonable width. Using tab characters in the file gives this
flexibility. It separates the lexical structure ("this is three blocks
in") from the visual display ("draw these glyphs 35mm from the left
margin").

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Chris Angelico]

On Thu, Jul 19, 2012 at 12:40 AM, Lipska the Kat
 wrote:
> Python looks like an interesting language and I will certainly spend time
> getting to know it but at the moment it seems to me that calling it an
> Object Oriented language is just plain misleading.

Python isn't object oriented in the way Java is ("EVERYTHING has to be
in a class! Look, it's all OO now!"). It simply says that, well,
what's the difference? That integer you're holding. That's an object.
Your function is an object. The module you're in, your "global scope",
is an object too, and can be passed around. Python doesn't care about
buzzwords, it cares about making code.

Of course, the simplicity of Python's object model has its costs too.
Every little integer has to be memory-managed and garbage-collected
(eg in CPython, they're all refcounted). That has a performance hit.
But not all that big a hit, and it is so handy when you want your
function to be able to accept, and distinguish between, different
types of object - you don't have to write one version that takes an
integer and a different one that takes a heap object.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Andrew Berg]

On 7/18/2012 9:34 AM, Grant Edwards wrote:
>  people who us tabs are wrong
Don't make me get my flamethrower!
> and people who mix spaces and tabs -- well, we don't
> talk about them in polite company.
Mixing can make sense, but not in Python.

*hides*
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 18/07/12 15:34, Grant Edwards wrote:

On 2012-07-17, Lipska the Kat  wrote:


and what's this obsession with 'correct' indentation of code ???


If you can explain to us Java's obsession with 'correct' placemnt of
curly-braces, then you've explained indentation in python.


I'm not getting into the curly braces wars. Life is just too short.


Unless you're asking about the tabs vs. spaces argument.  In that
case, people who use 4 spaces per level are 'correct'; people who use
a different number of spaces are a bit less correct; people who use
tabs are wrong;


hmm, I've been using tabs ... still, why use one key press when you can 
use 4 ;-).  Actually I quite like this aspect of Python, it's rapidly 
growing on me. Wonder if I could introduce this in a future release of 
Java ... nah, I'd be dead within a week %-(



and people who mix spaces and tabs -- well, we don't
talk about them in polite company.




--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 18/07/12 14:05, Steven D'Aprano wrote:

On Wed, 18 Jul 2012 01:46:31 +0100, Andrew Cooper wrote:


Take for example a Linux system call handler.  The general form looks a
little like (substituting C for python style pseudocode)

if not (you are permitted to do this):
 return -EPERM
if not (you've given me some valid data):
 return -EFAULT
if not (you've given me some sensible data):
 return -EINVAL
return actually_try_to_do_something_with(data)
I’m feeling a bit fed uI’m feeling a bit fed uI’m feeling a bit fed u
How would you program this sort of logic with a single return statement?


That's not terribly hard.

if not (you are permitted to do this):
 result = -EPERM
elif not (you've given me some valid data):
 result = -EFAULT
elif not (you've given me some sensible data):
 result = -EINVAL
else:
 result = actually_try_to_do_something_with(data)
return result


A better example would involve loops. I used to hate programming in some
versions of Pascal without a break statement: I needed a guard variable
to decide whether or not to do anything in the loop!

# pseudo-code
for i in 1 to 100:
 if not condition:
 do_something_useful()


Even with a break, why bother continuing through the body of the function
when you already have the result? When your calculation is done, it's
done, just return for goodness sake. You wouldn't write a search that
keeps going after you've found the value that you want, out of some
misplaced sense that you have to look at every value. Why write code with
unnecessary guard values and temporary variables out of a misplaced sense
that functions must only have one exit?


Object Oriented programming is all about encapsulating human concepts in 
a way that makes sense to human beings. Make no mistake, it is NEVER the 
case that a software system is written for any other reason than to 
serve human beings. OO is more than just the mechanics of writing code, 
it's a state of mind.


OO was 'invented' to address the many problems that beset increasingly 
complex software systems. The main problem was maintainability. 
Encapsulating a concept in a clear and concise way makes the code easier 
to understand. Sometimes this means writing code that is not 'optimal' 
for the machine. Good code should be readable as well as efficient but I 
contend that it is better to write something that is clear, concise and 
well encapsulated than always go for the 'meanest dog in the scrapyard' 
approach where a developer is determined to write unreadable code that 
shows how jolly clever he is. More often than not he is forced to admit 
six months down the line that he has no idea what his code does as he 
'forgot' to comment it.


I speak from bitter experience. This approach works for me. I have 
thousands of lines of code operating every day 'in the wild', everything 
from flight booking systems to real time odds arbitrage. Any developer 
who 'gets' OO can read and modify my code and I am very proud of this 
fact ... and I have never been forced to admit that I don't know what I 
wrote six months ago.


If you are writing embedded systems that must have a very limited memory 
footprint then there is a case for conciseness over readability but even 
then it has to be maintainable


Python looks like an interesting language and I will certainly spend 
time getting to know it but at the moment it seems to me that calling it 
an Object Oriented language is just plain misleading.


There, I've said it, trolls and flamers beware, I take no prisoners.

Lipska

--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Grant Edwards]

On 2012-07-17, Lipska the Kat  wrote:

> and what's this obsession with 'correct' indentation of code ???

If you can explain to us Java's obsession with 'correct' placemnt of
curly-braces, then you've explained indentation in python.

Unless you're asking about the tabs vs. spaces argument.  In that
case, people who use 4 spaces per level are 'correct'; people who use
a different number of spaces are a bit less correct; people who use
tabs are wrong; and people who mix spaces and tabs -- well, we don't
talk about them in polite company.

-- 
Grant Edwards   grant.b.edwardsYow! NEWARK has been
  at   REZONED!!  DES MOINES has
  gmail.combeen REZONED!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Wed, 18 Jul 2012 09:07:22 -0400, Roy Smith wrote:

>> Keep in mind that assertions are not guaranteed to run. Code like the
>> above is buggy, because if Python is run under the -O (optimize) flag,
>> assertions will be stripped out.
> 
> One could equally say that "code like the above is efficient, because if
> Python is run under the -O (optimize) flag, assertions will be stripped
> out" :-)

You seem to have missed my point. Asserts *should* be used for checks 
which are optional. In this case, the fact that assert is optimized away 
is a feature: you have the added safety of a guard against some 
programming errors, while still being able to optimize that code on 
request. This is what assert is for. You get no argument from me about 
that -- my code is bulging with assertions.

But where you *need* an explicit check to run, assert is not suitable, 
because you cannot control whether or not it will run. The caller, not 
you, controls that, by passing -O to the python interpreter.

If you have a public function or method that can be called by any other 
piece of code, and it has required pre-conditions that need to be checked 
(not necessarily a type-check), then DO NOT USE ASSERT.

If you use assert, then sometimes that pre-condition will not happen, and 
the caller can pass garbage into your function. The pre-condition will be 
violated, and your function will silently go off and do the wrong thing 
without warning.

If you're lucky, your program will fail somewhere else, probably far away 
from where the error actually occurs, and you will merely have to spend 
hours or days trying to debug it.

If you're unlucky, your program won't fail, it will just calculate 
garbage, or otherwise do the wrong thing.

Besides, there is another reason not to use assert: it gives the wrong 
exception. If the error is a type error, you should raise TypeError, not 
ValueError, or ZeroDivisionError, or IndexError, or AssertionError. Using 
assert because it saves a line of code is lazy, sloppy programming.



>> Better is to use explicit type checks and raise an exception yourself:
>> 
>> if not isinstance(x, int):
>> raise TypeError('expected an int, got %r' % x)
> 
> Maybe, but that's two lines where one does just fine.

But one line (assert) does *not* do just fine under the conditions I am 
talking about.

If you need the check to run, then assert is not suitable, because it is 
not guaranteed to run. It's as simple as that.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Roy Smith]

In article <5006b2e2$0$29978$c3e8da3$54964...@news.astraweb.com>,
 Steven D'Aprano  wrote:

> On Tue, 17 Jul 2012 09:52:59 -0400, Roy Smith wrote:
> 
> > you could write in Python:
> > 
> > # Type matching will get checked at run-time 
> > def my_function(mpf, ot):
> >assert isinstance(mpf, MassivelyParallelFrobinator) 
> >assert isinstance(ot, OtherThing)
> 
> Keep in mind that assertions are not guaranteed to run. Code like the 
> above is buggy, because if Python is run under the -O (optimize) flag, 
> assertions will be stripped out.

One could equally say that "code like the above is efficient, because if 
Python is run under the -O (optimize) flag, assertions will be stripped 
out" :-)

> Better is to use explicit type checks and raise an exception yourself:
> 
> if not isinstance(x, int):
> raise TypeError('expected an int, got %r' % x)

Maybe, but that's two lines where one does just fine.  If you're going 
to go for type-bondage, you might as well be efficient and succinct 
about it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Wed, 18 Jul 2012 01:46:31 +0100, Andrew Cooper wrote:

> Take for example a Linux system call handler.  The general form looks a
> little like (substituting C for python style pseudocode)
> 
> if not (you are permitted to do this):
> return -EPERM
> if not (you've given me some valid data):
> return -EFAULT
> if not (you've given me some sensible data):
> return -EINVAL
> return actually_try_to_do_something_with(data)
> 
> How would you program this sort of logic with a single return statement?

That's not terribly hard.

if not (you are permitted to do this):
result = -EPERM
elif not (you've given me some valid data):
result = -EFAULT
elif not (you've given me some sensible data):
result = -EINVAL
else:
result = actually_try_to_do_something_with(data)
return result


A better example would involve loops. I used to hate programming in some 
versions of Pascal without a break statement: I needed a guard variable 
to decide whether or not to do anything in the loop!

# pseudo-code
for i in 1 to 100:
if not condition:
do_something_useful()


Even with a break, why bother continuing through the body of the function 
when you already have the result? When your calculation is done, it's 
done, just return for goodness sake. You wouldn't write a search that 
keeps going after you've found the value that you want, out of some 
misplaced sense that you have to look at every value. Why write code with 
unnecessary guard values and temporary variables out of a misplaced sense 
that functions must only have one exit?



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Tue, 17 Jul 2012 09:52:59 -0400, Roy Smith wrote:

> you could write in Python:
> 
> # Type matching will get checked at run-time 
> def my_function(mpf, ot):
>assert isinstance(mpf, MassivelyParallelFrobinator) 
>assert isinstance(ot, OtherThing)

Keep in mind that assertions are not guaranteed to run. Code like the 
above is buggy, because if Python is run under the -O (optimize) flag, 
assertions will be stripped out.

Assertions are mostly useful for two things:

1) "This cannot possibly happen, but just in case it does..."

If you've ever written something like this:

if x%2 == 0:
do_spam()
elif x%2 == 1:
do_ham()
else:
# This can't happen!
print("something unexpected happened")
sys.exit()


that is better written as:

if x%2 == 0:
do_spam()
else:
assert x%2 == 1, "something unexpected happened"
do_ham()


2) To check your internal reasoning in a function or method.

For example:

def foo(something):
n = len(something)
x = math.sqrt(x)
# We expect that x must be less than half of n. 
# E.g. n=100 gives 10 < 50, which is correct.
assert x < n//2
process(n, x)


Run with the -O flag, the (hopefully!) redundant test will be stripped 
out; without the flag, the test will check your logic for you and fail if 
the stated condition is not met.

For bonus points, can you see the mistake? The stated condition is wrong. 
Without the assert, the process() code could go off and potentially 
silently do the wrong thing, but the assert guards against that 
possibility. And once I've had a bug report that my app raises an 
AssertionError, I will go back and think more carefully about the 
assertion that sqrt(n) is always less than half of n.


> but that's just not the way people write code in Python.

Better is to use explicit type checks and raise an exception yourself:

if not isinstance(x, int):
raise TypeError('expected an int, got %r' % x)

Better still is to duck-type whenever you can.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Steven D'Aprano]

On Tue, 17 Jul 2012 12:01:21 +0100, Lipska the Kat wrote:

> For the past 9 years I have been developing in Java
[...]
> Anyway, I'm looking at Python as a rapid prototyping language. I have an
> idea and just want to get it down in basic outline code as quickly as
> possible before it departs my aging brain... 

A couple of good resources for you to read, written by a top Python 
developer who also knows Java backwards:

http://dirtsimple.org/2004/12/python-is-not-java.html
http://dirtsimple.org/2004/12/java-is-not-python-either.html


You will occasionally (i.e. about sixteen times a day) read some Python 
programmer tossing out comments like "Flat is better than nested", often 
in quotes. P.J. Eby does this at least twice in the first link above. 
What the hell are they talking about?

They're talking about the Zen of Python, a list of a dozen or so slightly 
tongue in cheek mottoes meant to encapsulate the (often deliberately 
contradictory) coding philosophy that Python developers should aspire 
too. At the interactive Python prompt, enter "import this" (without the 
quotes) and be enlightened.

Keeping the Zen in mind as an ideal is incredibly useful. Arguing over 
whose opinion is more true to the Zen is a waste of time.


> I'm not used to using
> variables without declaring their type ... (well I used to do Visual
> Basic many years ago) It just seems so weird, 

Compared to Java, or Haskell, or Ada, Python may seem like an incredibly 
sloppy language. A lot of that sloppiness comes from the lack of compile-
time type-checking. And that's probably true: Haskell's type checker can 
detect infinite loops, by Jove! Python won't even warn you that you're 
about to blow away a built-in function. (Don't worry though, you can 
easily get it back again.)

(But at least Python isn't Perl, or PHP.)

While Python doesn't (can't!) check the type of data at compile-time, but 
it does check the type of data at run-time. This ain't assembly language, 
where there's only one type, bytes! I came from a Pascal background, and 
at first I found the lack of type declarations rather concerning. But 
soon I found it liberating.

Especially once I started using Python interactively, at the REPL.

Most arguments about which is better, compile-time type checking or run-
time type checking, miss the point: both have advantages, and 
disadvantages. Which is "better" depends on what you want to do.

Python is deliberately designed to be *fast to write*. It gives up a 
little bit of safety for that. But not as much as you might think. Type 
errors are less frequent than other errors (errors of logic, bad data, 
etc.). And so in the time it might take a Java programmer to satisfy the 
compiler's insistence on type correctness, a Python programmer has 
probably written the program *and* the unittests and given the customer 
the first iteration of the application.

At least, that's the theory.

But you probably already know that. After all, that's why Python is the 
rapid-application-development language, not Java.


> and what's this obsession
> with 'correct' indentation of code ???

Nearly everyone rights correctly indented code anyway. At least, those 
who don't, you don't want on your project. Python just takes it one step 
further, and makes correctly indented code mandatory rather than optional.

The plus side is, no more style wars over where the braces go, no more 
hunting for lost braces. The downside is, if you paste code into a dumb 
application (like many email clients!) that strips whitespace, your code 
will break. So don't do that.

http://stromberg.dnsalias.org/~strombrg/significant-whitespace.html



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Ulrich Eckhardt]

Am 18.07.2012 11:06, schrieb Lipska the Kat:

On 18/07/12 01:46, Andrew Cooper wrote:

Take for example a Linux system call handler.  The general form looks a
little like (substituting C for python style pseudocode)

if not (you are permitted to do this):
 return -EPERM
if not (you've given me some valid data):
 return -EFAULT
if not (you've given me some sensible data):
 return -EINVAL
return actually_try_to_do_something_with(data)

How would you program this sort of logic with a single return statement?
  This is very common logic for all routines for which there is even the
remotest possibility that some data has come from an untrusted source.


Eeek! well if you insist (type bound)

someType -EPERM
someType -EFAULT
sometype -EINVAL
someType -EDOSOMETHING

//method
someType checkSomething(data){

someType result = -EINVAL //or your most likely or 'safest' result

if not (you are permitted to do this):
   result = -EPERM
if not (you've given me some valid data):
   result = -EFAULT
if not (you've given me some sensible data):
   result = -EINVAL
else
   result = -EDSOMETHING

   return result
}
//cohesive, encapsulated, reusable and easy to read


This is a classic discussion topic, whether single exit (SE) functions 
should be used or not. There are two things I consider as problematic 
with them:
1. In the presence of exceptions, every function has at least two 
possible paths that can be taken out, one returns a value (or None, in 
Python), the other throws an exception. For that reason, trying to 
achieve SE is a dangerous illusion. The syscall handler above is C, 
which doesn't have exceptions like Java, C++ or Python, so it doesn't 
suffer those two paths.
2. The biggest problem with SE functions is that you often need to skip 
over lots of code before you finally find out that the fault at the very 
beginning causes nothing else to happen inside the function before it is 
finally returned to the caller. A typical symptom is deeply nested 
if-else structures. Another symptom is result variables that are checked 
multiple times to skip over effectively the rest of the function, which 
"unrolls" the nested if-else structures. Yet another symptom is a very 
fine granularity of microscopic functions, which is effectively a 
distributed nest of if-else structures.


Coming back to Python, this would look like this:

   if not /you are permitted to do this/:
   raise NotPermitted("go awai!")
   if not /you've given me valid data/:
   raise TypeError("unexpected input")
   if not /you're given me sensible data/:
   raise ValueError("invalid input")
   # do stuff here...

If you shoehorn this into an SE function (which you can't do if 
something in between might throw), then it probably looks like this:


   error = None
   if not /you are permitted to do this/:
   error = NotPermitted("go awai!")
   elif not /you've given me valid data/:
   raise TypeError("unexpected input")
   elif not /you're given me sensible data/:
   raise ValueError("invalid input")
   else:
   # do stuff here...
   if error:
   raise error
   else:
   return result



//later

if(checkSomething(data) == EDOSOMETHING){

 actually_try_to_do_something_with(data)
}
else{
 //who knows
}


Interestingly, you suggest to divide the original function into one that 
verifies some conditions and one that does the actual work. Using an 
early return is to me like drawing a big red line inside a function by 
which it can be split into two sections. This makes it IMHO equally 
clear, even clearer since I don't have to locate and read that other 
function. My bioware parses this so that if the first part succeeds, the 
second part can be read independently thereof, which reduces the amount 
of info to keep in mind at a time.


Also, when changing code, I don't have to locate other places where the 
utility function (checkSomething) is called (Python allows local 
functions, which can be very(!!) useful). Since the code is inline, I 
know that only this one function is affected. Yes, this is in direct 
contrast to the reusability you mentioned. Neither ease of change nor 
reusability are goals in and of themselves though, so this is not a 
black-or-white question and a compromise can be good enough. It's a 
question of taste, experience, phase of the moon, coffeination levels etc.


:)

Uli
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Arnaud Delobelle]

On 17 July 2012 13:01, Lipska the Kat  wrote:

> Well I've set myself a task.
> I have a text file containing a list of stock items
> each line contains the number in stock followed by a tab followed by the
> name of the item. I need to implement something that reads in the text file
> and outputs the stock list in ascending or descending order of quantity.
>
> Please note I am NOT asking for solutions.
>
> In bash this is laughably trivial

> sort -nr $1 | head -${2:-10}

Here's a Python translation that won't help :)

from sys import argv
print ''.join(sorted(open(argv[1]), key=lambda l:
-int(l.split('\t')[0]))[:10 if len(argv) < 3 else int(argv[2])])

Who said Python was readabl'y yours,

-- 
Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 18/07/12 01:46, Andrew Cooper wrote:

On 17/07/2012 19:36, Lipska the Kat wrote:

On 17/07/12 19:18, Mark Lawrence wrote:

On 17/07/2012 18:29, Ethan Furman wrote:

Terry Reedy wrote:

On 7/17/2012 10:23 AM, Lipska the Kat wrote:



snip



Take for example a Linux system call handler.  The general form looks a
little like (substituting C for python style pseudocode)

if not (you are permitted to do this):
 return -EPERM
if not (you've given me some valid data):
 return -EFAULT
if not (you've given me some sensible data):
 return -EINVAL
return actually_try_to_do_something_with(data)

How would you program this sort of logic with a single return statement?
  This is very common logic for all routines for which there is even the
remotest possibility that some data has come from an untrusted source.


Eeek! well if you insist (type bound)

someType -EPERM
someType -EFAULT
sometype -EINVAL
someType -EDOSOMETHING

//method
someType checkSomething(data){

someType result = -EINVAL //or your most likely or 'safest' result

if not (you are permitted to do this):
  result = -EPERM
if not (you've given me some valid data):
  result = -EFAULT
if not (you've given me some sensible data):
  result = -EINVAL
else
  result = -EDSOMETHING

  return result
}
//cohesive, encapsulated, reusable and easy to read

//later

if(checkSomething(data) == EDOSOMETHING){

actually_try_to_do_something_with(data)
}
else{
//who knows
}

What do you think ?



~Andrew

P.S. like the sig.


thanks


--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Larry Hudson]

On 07/17/2012 04:24 AM, Lipska the Kat wrote:
...

Thanks for your time and I'll try to do a bit better with the reading thing 
before asking more
questions... not sure about this obsession with code indentation though :-|



I think it's inaccurate to call this indentation an obsession, it's part of Python's defined 
syntax.  It's used INSTEAD OF punctuation or keywords (like {} or BEGIN END).  If you're already 
used to indenting your code consistently, you'll be surprised at how quickly it becomes a 
non-issue when you start using Python.


It's a bit dated, but you might find http://www.linuxjournal.com/article/3882 to be an 
interesting read.


 -=- Larry -=-
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[rusi]

On Jul 18, 5:46 am, Andrew Cooper  wrote:
> On 17/07/2012 19:36, Lipska the Kat wrote:
>
>
>
>
>
>
>
>
>
> > On 17/07/12 19:18, Mark Lawrence wrote:
> >> On 17/07/2012 18:29, Ethan Furman wrote:
> >>> Terry Reedy wrote:
>  On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>
> > Well 'type-bondage' is a strange way of thinking about compile time
> > type
> > checking and making code easier to read (and therefor debug
>
>  'type-bondage' is the requirement to restrict function inputs and
>  output to one declared type, where the type declaration mechanisms are
>  usually quite limited.
>
>  >>> def max(a, b):
>  if a <= b: return a
>  return b
>
> >>> Surely you meant 'if a >= b: . . .'
>
> >>> No worries, I'm sure your unittests would have caught it. ;)
>
> >>> ~Ethan~
>
> >> Wouldn't the compiler have caught it before the unittests? :-)
>
> > Not unless the compiler could read your mind!
> > The syntax looks fine it's the semantics that are suspect. Wrong is a
> > word that I try not to use as it tends to upset people, let's call them
> > "differently right" ;-)
>
> > BTW having more than one return statement in a block is a little thing I
> > know but it drives me nuts ... another "Pythonic" thing I'll have to get
> > used to I suppose.
>
> Its not a pythonic thing.  Its a common and very acceptable paradigm.
>
> Mainly, it avoids complicated breaks from nested control structures, and
> especially the 'style' of maintaining one boolean value called
> "should_continue" or something equally silly.
>
> My daily work involves C, x86 assembly, reading x86/PCI/ACPI/etc
> specifications and cursing violently at some of the stupidity, Python,
> Bash and C++, and this is one of the few styles which remains fairly
> constant throughout.
>
> Take for example a Linux system call handler.  The general form looks a
> little like (substituting C for python style pseudocode)
>
> if not (you are permitted to do this):
>     return -EPERM
> if not (you've given me some valid data):
>     return -EFAULT
> if not (you've given me some sensible data):
>     return -EINVAL
> return actually_try_to_do_something_with(data)
>
> How would you program this sort of logic with a single return statement?
>  This is very common logic for all routines for which there is even the
> remotest possibility that some data has come from an untrusted source.

return (-EPERM if not_permitted else -EFAULT if non_valid else -EINVAL
if non_sensible else do_something)

Not that I recommend *doing* this :-)
[I recommend knowing about it]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Andrew Cooper]

On 17/07/2012 19:36, Lipska the Kat wrote:
> On 17/07/12 19:18, Mark Lawrence wrote:
>> On 17/07/2012 18:29, Ethan Furman wrote:
>>> Terry Reedy wrote:
 On 7/17/2012 10:23 AM, Lipska the Kat wrote:

> Well 'type-bondage' is a strange way of thinking about compile time
> type
> checking and making code easier to read (and therefor debug

 'type-bondage' is the requirement to restrict function inputs and
 output to one declared type, where the type declaration mechanisms are
 usually quite limited.

 >>> def max(a, b):
 if a <= b: return a
 return b
>>>
>>>
>>> Surely you meant 'if a >= b: . . .'
>>>
>>> No worries, I'm sure your unittests would have caught it. ;)
>>>
>>> ~Ethan~
>>
>> Wouldn't the compiler have caught it before the unittests? :-)
>>
> 
> Not unless the compiler could read your mind!
> The syntax looks fine it's the semantics that are suspect. Wrong is a
> word that I try not to use as it tends to upset people, let's call them
> "differently right" ;-)
> 
> BTW having more than one return statement in a block is a little thing I
> know but it drives me nuts ... another "Pythonic" thing I'll have to get
> used to I suppose.
> 

Its not a pythonic thing.  Its a common and very acceptable paradigm.

Mainly, it avoids complicated breaks from nested control structures, and
especially the 'style' of maintaining one boolean value called
"should_continue" or something equally silly.

My daily work involves C, x86 assembly, reading x86/PCI/ACPI/etc
specifications and cursing violently at some of the stupidity, Python,
Bash and C++, and this is one of the few styles which remains fairly
constant throughout.

Take for example a Linux system call handler.  The general form looks a
little like (substituting C for python style pseudocode)

if not (you are permitted to do this):
return -EPERM
if not (you've given me some valid data):
return -EFAULT
if not (you've given me some sensible data):
return -EINVAL
return actually_try_to_do_something_with(data)

How would you program this sort of logic with a single return statement?
 This is very common logic for all routines for which there is even the
remotest possibility that some data has come from an untrusted source.

~Andrew

P.S. like the sig.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 20:39, Mark Lawrence wrote:

On 17/07/2012 20:29, Lipska the Kat wrote:

On 17/07/12 18:07, Terry Reedy wrote:

On 7/17/2012 10:23 AM, Lipska the Kat wrote:



snip


How easy was it to write max, or a universal sort in Java?


Well java.lang.Math.max() (or min() depending on what you want) might do
it and as for sorting ... java.utils.Collections.sort will sort anything
that implements the java.util.Comparable interface. All the standard
numerical classes implement Comparable by default so there is nothing to
do really.

Lipska



I would like to spend more time on this thread, but unfortunately the 44
ton artic carrying "Java in a Nutshell Volume 1 Part 1 Chapter 1
Paragraph 1 Sentence 1" has just arrived outside my abode and needs
unloading :-)


:-)))

LOL (and I did) but the pay is FANTASTIC, particularly if you 'get' OO.


--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Ian]

On 17/07/2012 19:43, Ethan Furman wrote:

Mark Lawrence wrote:

On 17/07/2012 18:29, Ethan Furman wrote:

Terry Reedy wrote:

On 7/17/2012 10:23 AM, Lipska the Kat wrote:

Well 'type-bondage' is a strange way of thinking about compile 
time type

checking and making code easier to read (and therefor debug


'type-bondage' is the requirement to restrict function inputs and
output to one declared type, where the type declaration mechanisms are
usually quite limited.

 >>> def max(a, b):
if a <= b: return a
return b



Surely you meant 'if a >= b: . . .'

No worries, I'm sure your unittests would have caught it.  ;)

~Ethan~


Wouldn't the compiler have caught it before the unittests? :-)


Silly me, the word processor would have caught it!

~Ethan~
No compiler can find as many faults as publishing your code on a mailing 
list!!!

 :)

Ian


--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Mark Lawrence]

On 17/07/2012 20:29, Lipska the Kat wrote:

On 17/07/12 18:07, Terry Reedy wrote:

On 7/17/2012 10:23 AM, Lipska the Kat wrote:


Well 'type-bondage' is a strange way of thinking about compile time type
checking and making code easier to read (and therefor debug




snip



How easy was it to write max, or a universal sort in Java?


Well java.lang.Math.max() (or min() depending on what you want) might do
it and as for sorting ... java.utils.Collections.sort will sort anything
that implements the java.util.Comparable interface. All the standard
numerical classes implement Comparable by default so there is nothing to
do really.

Lipska



I would like to spend more time on this thread, but unfortunately the 44 
ton artic carrying "Java in a Nutshell Volume 1 Part 1 Chapter 1 
Paragraph 1 Sentence 1" has just arrived outside my abode and needs 
unloading :-)


--
Cheers.

Mark Lawrence.



--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Mark Lawrence]

On 17/07/2012 19:43, Ethan Furman wrote:

Mark Lawrence wrote:

On 17/07/2012 18:29, Ethan Furman wrote:

Terry Reedy wrote:

On 7/17/2012 10:23 AM, Lipska the Kat wrote:


Well 'type-bondage' is a strange way of thinking about compile time
type
checking and making code easier to read (and therefor debug


'type-bondage' is the requirement to restrict function inputs and
output to one declared type, where the type declaration mechanisms are
usually quite limited.

 >>> def max(a, b):
if a <= b: return a
return b



Surely you meant 'if a >= b: . . .'

No worries, I'm sure your unittests would have caught it.  ;)

~Ethan~


Wouldn't the compiler have caught it before the unittests? :-)


Silly me, the word processor would have caught it!

~Ethan~


+1 laugh of the week

--
Cheers.

Mark Lawrence.



--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 18:07, Terry Reedy wrote:

On 7/17/2012 10:23 AM, Lipska the Kat wrote:


Well 'type-bondage' is a strange way of thinking about compile time type
checking and making code easier to read (and therefor debug




snip



How easy was it to write max, or a universal sort in Java?

Well java.lang.Math.max() (or min() depending on what you want) might do 
it and as for sorting ... java.utils.Collections.sort will sort anything 
that implements the java.util.Comparable interface. All the standard 
numerical classes implement Comparable by default so there is nothing to 
do really.


Lipska

--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Devin Jeanpierre]

On Tue, Jul 17, 2012 at 1:07 PM, Terry Reedy  wrote:
> 'type-bondage' is the requirement to restrict function inputs and output to
> one declared type, where the type declaration mechanisms are usually quite
> limited.

This is interesting, I hadn't expected that sort of definition. So
Haskell is not a type-bondage language?

(i.e. it lets you write functions that accept any type via parametric
polymorphism, or any type that supports an interface via type
classes).

> How easy was it to write max, or a universal sort in Java?

You write obj.compareTo(other) < 0  instead of using obj < other, and
your methods only work on objects (that support the comparable
interface). Otherwise, no different than Python, I guess.

Would Java not be a type-bondage language if everything was an object?

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 19:18, Mark Lawrence wrote:

On 17/07/2012 18:29, Ethan Furman wrote:

Terry Reedy wrote:

On 7/17/2012 10:23 AM, Lipska the Kat wrote:


Well 'type-bondage' is a strange way of thinking about compile time
type
checking and making code easier to read (and therefor debug


'type-bondage' is the requirement to restrict function inputs and
output to one declared type, where the type declaration mechanisms are
usually quite limited.

>>> def max(a, b):
if a <= b: return a
return b



Surely you meant 'if a >= b: . . .'

No worries, I'm sure your unittests would have caught it. ;)

~Ethan~


Wouldn't the compiler have caught it before the unittests? :-)



Not unless the compiler could read your mind!
The syntax looks fine it's the semantics that are suspect. Wrong is a 
word that I try not to use as it tends to upset people, let's call them 
"differently right" ;-)


BTW having more than one return statement in a block is a little thing I 
know but it drives me nuts ... another "Pythonic" thing I'll have to get 
used to I suppose.


--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Ethan Furman]

Mark Lawrence wrote:

On 17/07/2012 18:29, Ethan Furman wrote:

Terry Reedy wrote:

On 7/17/2012 10:23 AM, Lipska the Kat wrote:

Well 'type-bondage' is a strange way of thinking about compile time 
type

checking and making code easier to read (and therefor debug


'type-bondage' is the requirement to restrict function inputs and
output to one declared type, where the type declaration mechanisms are
usually quite limited.

 >>> def max(a, b):
if a <= b: return a
return b



Surely you meant 'if a >= b: . . .'

No worries, I'm sure your unittests would have caught it.  ;)

~Ethan~


Wouldn't the compiler have caught it before the unittests? :-)


Silly me, the word processor would have caught it!

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 18:24, Terry Reedy wrote:

On 7/17/2012 8:01 AM, Lipska the Kat wrote:

On 17/07/12 09:45, Lipska the Kat wrote:

Pythoners

Python 2.7.3
Ubuntu Linux 12.04 LTS

I've been taking a brief look at Python.



snip

>>

Well I've set myself a task.
I have a text file containing a list of stock items
each line contains the number in stock followed by a tab followed by the
name of the item. I need to implement something that reads in the text
file and outputs the stock list in ascending or descending order of
quantity.



snip




In bash this is laughably trivial

sort -nr $1 | head -${2:-10}


Won't sort work alphabetically and leave the following as is?

1\talpha
11\tbeta
2\tgamma


The -n option tells sort to interpret the first word on a line as a 
number r means sort in descending order. It works fine. I also added 
another feature not in the specification that allows the input of a 
number of lines to print ...

well on the way to being bloatware I guess ;-)

Lipska

--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Mark Lawrence]

On 17/07/2012 18:29, Ethan Furman wrote:

Terry Reedy wrote:

On 7/17/2012 10:23 AM, Lipska the Kat wrote:


Well 'type-bondage' is a strange way of thinking about compile time type
checking and making code easier to read (and therefor debug


'type-bondage' is the requirement to restrict function inputs and
output to one declared type, where the type declaration mechanisms are
usually quite limited.

 >>> def max(a, b):
if a <= b: return a
return b



Surely you meant 'if a >= b: . . .'

No worries, I'm sure your unittests would have caught it.  ;)

~Ethan~


Wouldn't the compiler have caught it before the unittests? :-)

--
Cheers.

Mark Lawrence.



--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Tim Chase]

On 07/17/12 12:29, Ethan Furman wrote:
> Terry Reedy wrote:
>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>>
>>> Well 'type-bondage' is a strange way of thinking about compile time type
>>> checking and making code easier to read (and therefor debug
>>
>> 'type-bondage' is the requirement to restrict function inputs and output 
>> to one declared type, where the type declaration mechanisms are usually 
>> quite limited.
>>
>>  >>> def max(a, b):
>> if a <= b: return a
>> return b
> 
> 
> Surely you meant 'if a >= b: . . .'
> 
> No worries, I'm sure your unittests would have caught it.  ;)

Or he could have meant "min" instead of "max".

Or he could have returned the wrong values:

  def max(a, b):
if a <= b: return b
return a

:-)

-tkc


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Chris Angelico]

On Wed, Jul 18, 2012 at 12:23 AM, Lipska the Kat
 wrote:
> Well 'type-bondage' is a strange way of thinking about compile time type
> checking and making code easier to read (and therefor debug) but
> I'm not about to get into some religious war about declaring a variables
> type.

There are options for that, but they aren't Python. (I'd like to see a
"from __future__ import variable_declarations", but it doesn't seem to
work. Yet.) If you're interested, I could tell you about a language
that has a lot of what you're looking for (including polymorphism and
even the ability to declare a variable that can contain "non-negative
integer" as a type), but it's off-topic for the forum. However, I
can't email you, as lipskathekat.com doesn't seem to exist... Email me
privately if you're interested, we can continue the discussion
off-list.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Andrew Berg]

On 7/17/2012 12:30 PM, Terry Reedy wrote:
> (In some ways, it is already better than 3.2.3.)
I certainly make heavy use of some of the new features. I'm not sure we
can have enough separate exceptions for OS errors without exhausting
every possibility and I might start looking for excuses to use the lzma
module. :P

-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Tim Chase]

On 07/17/12 12:24, Terry Reedy wrote:
> On 7/17/2012 8:01 AM, Lipska the Kat wrote:
>> In bash this is laughably trivial
>>
>> sort -nr $1 | head -${2:-10}
> 
> Won't sort work alphabetically and leave the following as is?
> 
> 1\talpha
> 11\tbeta
> 2\tgamma

Only if Lipska had omitted the "-n" which tells sort to treat
numbers like numbers.

For Lipska, you'd want to look into the "csv" module for parsing the
file easily (specifying '\t' as the delimiter).  You can then sort
and crop as-is, or you can use heapq.nsmallest()

-tkc



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[MRAB]

On 17/07/2012 18:24, Terry Reedy wrote:

On 7/17/2012 8:01 AM, Lipska the Kat wrote:

On 17/07/12 09:45, Lipska the Kat wrote:

Pythoners

Python 2.7.3
Ubuntu Linux 12.04 LTS

I've been taking a brief look at Python.



snip

Well I've set myself a task.
I have a text file containing a list of stock items
each line contains the number in stock followed by a tab followed by the
name of the item. I need to implement something that reads in the text
file and outputs the stock list in ascending or descending order of
quantity.


Nice problem. Easy but non-trivial.


Please note I am NOT asking for solutions.


Ok. With some inefficient redundancy, I believe it could be done in one
line in Python. Better code would take a few more.


In bash this is laughably trivial

sort -nr $1 | head -${2:-10}


Won't sort work alphabetically and leave the following as is?

1\talpha
11\tbeta
2\tgamma


The commandline options are "-nr". "n" means compare numerically and
"r" means reverse order.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Ethan Furman]

Terry Reedy wrote:

On 7/17/2012 10:23 AM, Lipska the Kat wrote:


Well 'type-bondage' is a strange way of thinking about compile time type
checking and making code easier to read (and therefor debug


'type-bondage' is the requirement to restrict function inputs and output 
to one declared type, where the type declaration mechanisms are usually 
quite limited.


 >>> def max(a, b):
if a <= b: return a
return b



Surely you meant 'if a >= b: . . .'

No worries, I'm sure your unittests would have caught it.  ;)

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Terry Reedy]

On 7/17/2012 10:16 AM, Andrew Berg wrote:

On 7/17/2012 9:01 AM, Lipska the Kat wrote:

Wow, that was a blast from the past
Just downloaded, unzipped, untarred, configured, made and installed
python 3.2.3 ... it's YEARS since I've done this, makes me feel young again.



Most Linux distributions should have a premade package for stable Python
versions - apt-get install python3 or something like that.


I am just curious: how long will it take 'most Linux distributions' to 
premake the even better 3.3.0 (after it comes out) and change the 
default python3 to that? Do any of them have a premade 3.3.0b0 
available? (In some ways, it is already better than 3.2.3.)


--
Terry Jan Reedy



--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Terry Reedy]

On 7/17/2012 8:01 AM, Lipska the Kat wrote:

On 17/07/12 09:45, Lipska the Kat wrote:

Pythoners

Python 2.7.3
Ubuntu Linux 12.04 LTS

I've been taking a brief look at Python.



snip

Well I've set myself a task.
I have a text file containing a list of stock items
each line contains the number in stock followed by a tab followed by the
name of the item. I need to implement something that reads in the text
file and outputs the stock list in ascending or descending order of
quantity.


Nice problem. Easy but non-trivial.


Please note I am NOT asking for solutions.


Ok. With some inefficient redundancy, I believe it could be done in one 
line in Python. Better code would take a few more.



In bash this is laughably trivial

sort -nr $1 | head -${2:-10}


Won't sort work alphabetically and leave the following as is?

1\talpha
11\tbeta
2\tgamma

--
Terry Jan Reedy



--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Terry Reedy]

On 7/17/2012 10:23 AM, Lipska the Kat wrote:


Well 'type-bondage' is a strange way of thinking about compile time type
checking and making code easier to read (and therefor debug


'type-bondage' is the requirement to restrict function inputs and output 
to one declared type, where the type declaration mechanisms are usually 
quite limited.


>>> def max(a, b):
if a <= b: return a
return b

>>> max(1,3)
1
>>> max(3.3, 3.1)
3.1
>>> max('ab', 'aa')
'aa'
>>> max([1,1], [1,0])
[1, 0]

and so on, indefinitely. How easy is it to write the same in Java?
Similarly, list.sort sorts any list as long as a < b works for all pairs 
of items in the list.


Function max works for any two objects as long as 'a <= b' works. So the 
'type' of a and b is 'mutually comparable with <='.  How do you declare 
that in Java? How do you declare the type 'non-negative number'? In 
python, putting 'if input >= 0:' as the top effectively 'declares' that 
input must be a number and greater than 0.



but I'm not about to get into some religious war about declaring a variables
type.


In Python, *all* data items have a class (type). Names in code do not 
have a type. When they become data items, they are strings. 'Variable' 
is a somewhat fuzzy term or concept in Python.


Since every object is an instance of some class, every class is a 
subclass of class 'object', and an instance of a class is an instance of 
all its classess superclasses; every object is an instance of 'object'. 
So 'object' is the type of all inputs until further restricted. id(ob) 
produces an integer for all objects. str(ob) is intented to produce a 
string representation for all objects. The print functions calls str on 
all its inputs.



I'll just say that I prefer to devote testing efforts to the real
danger area which in my experience is 'user' input.
Clients look dimly on runtime errors however they occur and if I can
leave it to the compiler to check as much as possible then I'll take that.


import ast
a = ast.literal_eval(input('enter a value: '))
b = ast.literal_eval(input('enter a comparable value: ')
try:
print('the max of those two is ', max(a,b))
except TypeError:
print(a, ' and ', b, ' are not comparable')

I suppose


Still, I'm sure you're only kidding around with me :-)


How easy was it to write max, or a universal sort in Java?

--
Terry Jan Reedy



--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 17:26, Mark Lawrence wrote:

On 17/07/2012 15:23, Lipska the Kat wrote:

On 17/07/12 14:52, Roy Smith wrote:


snip



Still, I'm sure you're only kidding around with me :-)


Kidding around on a Python mailing list, never, how dare you Sir, simply
wouldn't be cricket :-)


As in "The batsman of the Kalahari" no doubt :-)

--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Mark Lawrence]

On 17/07/2012 15:23, Lipska the Kat wrote:

On 17/07/12 14:52, Roy Smith wrote:

In article<-8sdnvrxgqie25jnnz2dnuvz7qkdn...@bt.com>,
  Lipska the Kat  wrote:


I'm not used to using variables without declaring their type


If you truly wanted to recreate this type-bondage style of programming
in Python, it's easy enough to do.


snip

Well 'type-bondage' is a strange way of thinking about compile time type
checking and making code easier to read (and therefor debug) but
I'm not about to get into some religious war about declaring a variables
type. I'll just say that I prefer to devote testing efforts to the real
danger area which in my experience is 'user' input.


Why waste time testing, I thought that the compiler looked after 
everything? :)  But seriously you might want to look at the unittest 
module in the standard library.  There's also a separate mailing list 
for Python testing and I'm sure there's a wiki that compares the 
available tesing tools.  Google and ye shall find!!!



Clients look dimly on runtime errors however they occur and if I can
leave it to the compiler to check as much as possible then I'll take that.

I do understand however that compiling an intepreted language doesn't
really make sense however i'm sure there are interpreted languages that
allow pre-execution type checking ... aren't there ? Oh yes, there's one
called Java :-)


There are tools available to help here such as pylint, pychecker and 
pyflakes.  For other modules check out pypi at http://pypi.python.org/pypi




Still, I'm sure you're only kidding around with me :-)


Kidding around on a Python mailing list, never, how dare you Sir, simply 
wouldn't be cricket :-)




Lipska



--
Cheers.

Mark Lawrence.



--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 15:16, Andrew Berg wrote:

On 7/17/2012 9:01 AM, Lipska the Kat wrote:

Wow, that was a blast from the past
Just downloaded, unzipped, untarred, configured, made and installed
python 3.2.3 ... it's YEARS since I've done this, makes me feel young again.

Most Linux distributions should have a premade package for stable Python
versions - apt-get install python3 or something like that.


Not as much fun though is it :-)

Lipska

--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 14:52, Roy Smith wrote:

In article<-8sdnvrxgqie25jnnz2dnuvz7qkdn...@bt.com>,
  Lipska the Kat  wrote:


I'm not used to using variables without declaring their type


If you truly wanted to recreate this type-bondage style of programming
in Python, it's easy enough to do.


snip

Well 'type-bondage' is a strange way of thinking about compile time type 
checking and making code easier to read (and therefor debug) but
I'm not about to get into some religious war about declaring a variables 
type. I'll just say that I prefer to devote testing efforts to the real 
danger area which in my experience is 'user' input.
Clients look dimly on runtime errors however they occur and if I can 
leave it to the compiler to check as much as possible then I'll take that.


I do understand however that compiling an intepreted language doesn't 
really make sense however i'm sure there are interpreted languages that 
allow pre-execution type checking ... aren't there ? Oh yes, there's one 
called Java :-)


Still, I'm sure you're only kidding around with me :-)

Lipska

--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Andrew Berg]

On 7/17/2012 9:01 AM, Lipska the Kat wrote:
> Wow, that was a blast from the past
> Just downloaded, unzipped, untarred, configured, made and installed 
> python 3.2.3 ... it's YEARS since I've done this, makes me feel young again.
Most Linux distributions should have a premade package for stable Python
versions - apt-get install python3 or something like that. Python 2 is
generally the default Python because of all the system scripts that
haven't been ported to py3k.
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 12:37, Andrew Berg wrote:

On 7/17/2012 6:01 AM, Lipska the Kat wrote:


snip


On a side note, I would highly recommend learning Python 3 (3.2 is the
latest stable version) unless you have an explicit need for Python 2
(some major 3rd-party libraries have not been ported yet). Python 2
won't get any new features; it will simply get bug fixes until its EOL
in 2014 (15?).


Wow, that was a blast from the past
Just downloaded, unzipped, untarred, configured, made and installed 
python 3.2.3 ... it's YEARS since I've done this, makes me feel young again.


Lispka


--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Roy Smith]

In article <-8sdnvrxgqie25jnnz2dnuvz7qkdn...@bt.com>,
 Lipska the Kat  wrote:

> I'm not used to using variables without declaring their type 

If you truly wanted to recreate this type-bondage style of programming 
in Python, it's easy enough to do.

Where you would write in C++:

// Type matching will get checked at compile-time
void my_function(MassivelyParallelFrobinator& mpf, OtherThing& ot) {
   blah, blah, blah
}

you could write in Python:

# Type matching will get checked at run-time
def my_function(mpf, ot):
   assert isinstance(mpf, MassivelyParallelFrobinator)
   assert isinstance(ot, OtherThing)

but that's just not the way people write code in Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Mark Lawrence]

On 17/07/2012 12:44, Lipska the Kat wrote:


You're not kidding, the 'duck' example at
http://en.wikipedia.org/wiki/Duck_typing made me check I hadn't overdone
the medication this morning. That is just plain ...weird. It will take
me a while to form non knee jerk opinions of this for sure.

Lipska




It's difficult to get junkies off of their addictive substances but I'm 
sure that the qualities of Python will eventually overcome your Java 
habit :)


--
Cheers.

Mark Lawrence.



--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Mark Lawrence]

On 17/07/2012 12:01, Lipska the Kat wrote:


Anyway, I'm looking at Python as a rapid prototyping language.

Lipska



One of the huge advantages of Python here is that you can simply blast 
stuff into the interactive prompt and see what happens, no need to write 
a script.


--
Cheers.

Mark Lawrence.



--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Ulrich Eckhardt]

Am 17.07.2012 13:01, schrieb Lipska the Kat:

On 17/07/12 10:30, Ulrich Eckhardt wrote:

Am 17.07.2012 10:45, schrieb Lipska the Kat:

I was expecting (hoping) to see in depth documentation relating to Class
construction, extension mechanisms and runtime polymorphism.


In addition to this forum for direct help and discussion, two
suggestions: Firstly, it could help if you mentioned what programming
languages you are fluent in


For the past 9 years I have been developing in Java  [...]


Java is usually called an OOP language, because everything you do there 
is put into a class. Free functions don't exist, the closest you get is 
class-static functions (correct me if I'm wrong, I'm not really fluent 
in that language). In Python, you have the choice to use OOP, but you 
can also use free functions or mix those.




I'm not used to using variables without declaring their type


As a C++ programmer (roughly 80%C++, 15%Python, 5%C) I know that 
feeling. Having types declared in advance just helps by having the 
compiler check if the passed arguments are correct. Not having this 
gives both freedom but also bears dangers.




what's this obsession with 'correct' indentation of code ???


You'll get used to it and then start loving it.

;)

Uli

--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 09:45, Lipska the Kat wrote:

Pythoners

Python 2.7.3
Ubuntu Linux 12.04 LTS

I've been taking a brief look at Python.



snip

Well I've set myself a task.
I have a text file containing a list of stock items
each line contains the number in stock followed by a tab followed by the 
name of the item. I need to implement something that reads in the text 
file and outputs the stock list in ascending or descending order of 
quantity.


Please note I am NOT asking for solutions.

In bash this is laughably trivial

sort -nr $1 | head -${2:-10}

Java is easy but long winded and takes a while to set up

C is ... well it's been a while but I'll get there

Python, well that's my current task. It will be interesting to compare 
the solutions for speed and ease of development and more importantly

re-usability.



Lipska




--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Andrew Berg]

On 7/17/2012 6:44 AM, Lipska the Kat wrote:
> I'll check it out, thanks.
I forgot to add this:
http://wiki.python.org/moin/Python2orPython3

It's a little outdated (there is more progress toward py3k by 3rd-party
libraries every day), but still quite helpful.
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 12:37, Andrew Berg wrote:

On 7/17/2012 6:01 AM, Lipska the Kat wrote:

Anyway, I'm looking at Python as a rapid prototyping language.


snip


"Pythonic" is (or at least should be) a word you encounter frequently in
discussions of Python code. Learn what is considered Pythonic and then
write Python code that way if you want to work with the language rather
than fight it. Duck-typing is very Pythonic


You're not kidding, the 'duck' example at 
http://en.wikipedia.org/wiki/Duck_typing made me check I hadn't overdone 
the medication this morning. That is just plain ...weird. It will take 
me a while to form non knee jerk opinions of this for sure.


snip


On a side note, I would highly recommend learning Python 3 (3.2 is the
latest stable version) unless you have an explicit need for Python 2
(some major 3rd-party libraries have not been ported yet). Python 2
won't get any new features; it will simply get bug fixes until its EOL
in 2014 (15?).


I'll check it out, thanks.

Lipska


--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Andrew Berg]

On 7/17/2012 6:01 AM, Lipska the Kat wrote:
> Anyway, I'm looking at Python as a rapid prototyping language.
> I have an idea and just want to get it down in basic outline code as 
> quickly as possible before it departs my aging brain... I'm not used to 
> using variables without declaring their type ... (well I used to do 
> Visual Basic many years ago) It just seems so weird, and what's this 
> obsession with 'correct' indentation of code ???
"Pythonic" is (or at least should be) a word you encounter frequently in
discussions of Python code. Learn what is considered Pythonic and then
write Python code that way if you want to work with the language rather
than fight it. Duck-typing is very Pythonic and so is readable code. As
Dave mentioned, indentation is part of the syntax - blocks must be
indented with either tabs or spaces (choose one - if you mix them
ambiguously, an IndentationError will be raised). Try "from __future__
import braces" and "import this" for some insight. ;)

The official tutorial gives a great overview of the language and has
links to reference material that goes into greater detail:
http://docs.python.org/tutorial/ (Python 2.7)
http://docs.python.org/py3k/tutorial/ (Python 3.2)

On a side note, I would highly recommend learning Python 3 (3.2 is the
latest stable version) unless you have an explicit need for Python 2
(some major 3rd-party libraries have not been ported yet). Python 2
won't get any new features; it will simply get bug fixes until its EOL
in 2014 (15?).
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 11:03, Devin Jeanpierre wrote:

On Tue, Jul 17, 2012 at 4:45 AM, Lipska the Kat  wrote:

Is Python truly OO or is it just one way to use the language. I see some
documentation relating to classes but nothing on instantiation .. in fact
the documentation appears to say that classes are used in a static way e.g
ClassName.method(), and command line scripting is really outside the scope
of other OO languages I have experienced.


It doesn't look like you're reading the section on classes:

http://docs.python.org/tutorial/classes.html


Thanks, I wasn't, there is too much to do and not enough time to do it.
So now I just need to chill out a bit and get into 'documentation 
reading mode' again




Polymorphism is "duck typed" --


Yes, I've been reading the wikipedia entry on this ... this type of 
polymorphism is not familiar to me ... I come from a Java background. 
more reading I guess.


snip


-- Devin


Thanks for your time and I'll try to do a bit better with the reading 
thing before asking more questions... not sure about this obsession with 
code indentation though :-|



--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Dave Angel]

On 07/17/2012 07:01 AM, Lipska the Kat wrote:
> 
>
> Anyway, I'm looking at Python as a rapid prototyping language.
> I have an idea and just want to get it down in basic outline code as
> quickly as possible before it departs my aging brain... I'm not used
> to using variables without declaring their type ... (well I used to do
> Visual Basic many years ago) It just seems so weird, and what's this
> obsession with 'correct' indentation of code ???
>

Welcome to comp.lang.python.  I hope you enjoy learning and using Python.

Indentation isn't just custom in Python.  It's part of the syntax. 
Other languages use braces, or keywords, to indicate scope, but Python
uses indentation.  Other than the occasional tab to confuse things, the
rules are pretty simple.

You must indent the body of a function, the scope of an if or else
clause, or other similar language pieces (class, try, except, ...)
Within such a scope, you cannot change indentation, except of course for
a nested scope.
At the end of such scope you must outdent to the previous state.

The convention is to use 4 spaces per indentation, but the language will
accept any amount, as long as it's consistent within any single scope. 
And although mixing tabs and space worked in Python 2.x, sort of, it's
disallowed in Python 3.

An expression may span multiple lines, but only if it's unambiguous to
the compiler (eg. a pending left paren with no matching right paren
yet).  In that case. indentation of the subsequent lines is unrestricted.

HTH

-- 

DaveA

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 17/07/12 10:30, Ulrich Eckhardt wrote:

Welcome!

Am 17.07.2012 10:45, schrieb Lipska the Kat:

I was expecting (hoping) to see in depth documentation relating to Class
construction, extension mechanisms and runtime polymorphism.


In addition to this forum for direct help and discussion, two
suggestions: Firstly, it could help if you mentioned what programming
languages you are fluent in


For the past 9 years I have been developing in Java, everything from 
device drivers (well firmware interfaces would be a better description)
to serverside business logic implemented using POJOs and database 
interfaces along with some in depth work with earlier versions of J2EE 
including EJBs and of course the obligatory frameworks. There's more but 
you get the idea.


My speciality if you like is the design of high availability real time 
business systems right from high level natural language specifications 
to detailed use cases and associated models in UML. I also do some 
implementation work although not so much these days. phew! my resume in 
a nutshell I suppose


Earlier on in my career I did some fairly low level stuff in C and C++ 
although the mists of time and all that ...


Anyway, I'm looking at Python as a rapid prototyping language.
I have an idea and just want to get it down in basic outline code as 
quickly as possible before it departs my aging brain... I'm not used to 
using variables without declaring their type ... (well I used to do 
Visual Basic many years ago) It just seems so weird, and what's this 
obsession with 'correct' indentation of code ???



in order to help traditional misconceptions
and to draw parallels. Secondly, http://docs.python.org is the central
hub to tutorials and documentation.



What I actually get is a confusion of Classes, modules, scripts and
whatever else.


Due to the very dynamic nature of Python, types (classes), modules and
functions are themselves objects that can be manipulated.




snip




I see some documentation relating to classes but nothing on
instantiation .. in fact the documentation appears to say that classes

 > are used in a static way e.g ClassName.method(), and command line
 > scripting is really outside the scope of other OO languages I have
 > experienced.

I think you are confused.


Highly likely


For the documentation, it would help to know
which documentation exactly seems to make such claims. For the thing
about commandline scripting, I'm afraid you will have to adjust your
expectations.


I'll try to find it again



BTW: In general, you instantiate a class by just calling the class' name
like a function. If e.g. ClassName is a class, ClassName() instantiates
this class.


Good luck!


Thank you, and thank you for your kind response

Lipska


--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Ulrich Eckhardt]

Welcome!

Am 17.07.2012 10:45, schrieb Lipska the Kat:

I was expecting (hoping) to see in depth documentation relating to Class
construction, extension mechanisms and runtime polymorphism.


In addition to this forum for direct help and discussion, two 
suggestions: Firstly, it could help if you mentioned what programming 
languages you are fluent in, in order to help traditional misconceptions 
and to draw parallels. Secondly, http://docs.python.org is the central 
hub to tutorials and documentation.




What I actually get is a confusion of Classes, modules, scripts and
whatever else.


Due to the very dynamic nature of Python, types (classes), modules and 
functions are themselves objects that can be manipulated.




Is Python truly OO or is it just one way to use the language.


Python supports OOP, but it doesn't enforce it. You can use other 
paradigms, too.




I see some documentation relating to classes but nothing on
instantiation .. in fact the documentation appears to say that classes

> are used in a static way e.g ClassName.method(), and command line
> scripting is really outside the scope of other OO languages I have
> experienced.

I think you are confused. For the documentation, it would help to know 
which documentation exactly seems to make such claims. For the thing 
about commandline scripting, I'm afraid you will have to adjust your 
expectations.


BTW: In general, you instantiate a class by just calling the class' name 
like a function. If e.g. ClassName is a class, ClassName() instantiates 
this class.



Good luck!

Uli
--
http://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation, inheritance and polymorphism

[Devin Jeanpierre]

On Tue, Jul 17, 2012 at 4:45 AM, Lipska the Kat  wrote:
> Is Python truly OO or is it just one way to use the language. I see some
> documentation relating to classes but nothing on instantiation .. in fact
> the documentation appears to say that classes are used in a static way e.g
> ClassName.method(), and command line scripting is really outside the scope
> of other OO languages I have experienced.

It doesn't look like you're reading the section on classes:

http://docs.python.org/tutorial/classes.html

You create a class like this:

class MyClass(MySuperclass1, MySuperclass2):
# class attributes and methods
attr = 3
def method(self): print self.attr

You can instantiate it by calling the class, as if it were a function:

myinstance = MyClass()

You call a method getting the method (myinstance.method), and then
calling that as if it were a function.

myinstance.method()

Polymorphism is "duck typed" -- that is, it's based on the
presence/absence of attributes and methods, not on declared interfaces
(Python has no interfaces). So, for example, "foo.read()" works on any
object bound to the name "foo", as long as it has a read method that
takes no parameters. This could be a file-like object, but it could
also be something completely different that just happens to have a
method by the same name.

> Is there a previous discussion in the group that I could read.

Man, I dunno, the list archives are impossible to navigate.

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list