Encapsulation, inheritance and polymorphism

[Lipska the Kat]

Pythoners

Python 2.7.3
Ubuntu Linux 12.04 LTS

I've been taking a brief look at Python.

From the tutorial documentation I get the following

'Python is an easy to learn, powerful programming language. It has
efficient high-level data structures and a simple but effective approach
to object-oriented programming'.

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

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

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.

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

Many thanks

Lipska

--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer.

[Devin Jeanpierre]

On Tue, Jul 17, 2012 at 4:45 AM, Lipska the Kat <lip...@lipskathekat.com> 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

[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

[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.

[Dave Angel]

On 07/17/2012 07:01 AM, Lipska the Kat wrote:
> <SNIP>

>
> 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

[Lipska the Kat]

On 17/07/12 11:03, Devin Jeanpierre wrote:
> On Tue, Jul 17, 2012 at 4:45 AM, Lipska the Kat<lip...@lipskathekat.com> 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.

[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

[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.

[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.

[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.

[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

[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.

[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.

[Roy Smith]

In article <-8SdnVrXGqie25jN...@bt.com>,

Lipska the Kat <lip...@lipskathekat.com> 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.

[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

[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.

[Lipska the Kat]

On 17/07/12 14:52, Roy Smith wrote:
> In article<-8SdnVrXGqie25jN...@bt.com>,
> Lipska the Kat<lip...@lipskathekat.com> 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 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

[Mark Lawrence]

On 17/07/2012 15:23, Lipska the Kat wrote:
> On 17/07/12 14:52, Roy Smith wrote:
>> In article<-8SdnVrXGqie25jN...@bt.com>,
>> Lipska the Kat<lip...@lipskathekat.com> 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.

[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 :-)

[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

[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

[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

[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~

[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.

[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

[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

[Chris Angelico]

On Wed, Jul 18, 2012 at 12:23 AM, Lipska the Kat
<lip...@lipskathekat.com> 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

[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

[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.

[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 the Kat]

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.

[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~

[Devin Jeanpierre]

On Tue, Jul 17, 2012 at 1:07 PM, Terry Reedy <tjr...@udel.edu> 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

[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.

[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.

[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.

[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

[Lipska the Kat]

:-)))))))

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

[Andrew Cooper]

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.

[rusi]

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]

[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 -=-

[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

[Arnaud Delobelle]

On 17 July 2012 13:01, Lipska the Kat <lip...@lipskathekat.com> 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

[Ulrich Eckhardt]

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

[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

[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

[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

[Roy Smith]

In article <5006b2e2$0$29978$c3e8da3$5496...@news.astraweb.com>,

Steven D'Aprano <steve+comp....@pearwood.info> 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.

[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

[Grant Edwards]

On 2012-07-17, Lipska the Kat <lip...@lipskathekat.com> 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.edwards Yow! NEWARK has been
at REZONED!! DES MOINES has
gmail.com been REZONED!!

[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

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]

On 18/07/12 15:34, Grant Edwards wrote:
> On 2012-07-17, Lipska the Kat<lip...@lipskathekat.com> 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.
>


--

[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

[Chris Angelico]

On Thu, Jul 19, 2012 at 12:40 AM, Lipska the Kat
<lip...@lipskathekat.com> 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

[Chris Angelico]

On Thu, Jul 19, 2012 at 12:48 AM, Lipska the Kat
<lip...@lipskathekat.com> 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

[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~

[Lipska the Kat]

On 18/07/12 16:09, Chris Angelico wrote:
> On Thu, Jul 19, 2012 at 12:48 AM, Lipska the Kat
> <lip...@lipskathekat.com> 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]

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~

[Dave Angel]

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

>
>
> 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)
>
>

> <SNIP>

> 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

[BartC]

"Lipska the Kat" <lip...@lipskathekat.com> wrote in message
news:c76dnV778_sw4ZvN...@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

[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

[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

[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:

>> <SNIP>

>> 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

[MRAB]

"""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

[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

[Chris Angelico]

On Thu, Jul 19, 2012 at 11:22 AM, Steven D'Aprano
<steve+comp....@pearwood.info> 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

[rusi]

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

+comp.lang.pyt...@pearwood.info> 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.

[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

[Lipska the Kat]

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

[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

[Roy Smith]

In article <500804cc$0$29978$c3e8da3$5496...@news.astraweb.com>,

Steven D'Aprano <steve+comp....@pearwood.info> 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.

[rusi]

On Jul 19, 1:56 pm, Lipska the Kat <lip...@lipskathekat.com> 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]

[Paul Rudin]

Steven D'Aprano <steve+comp....@pearwood.info> 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://en.wikipedia.org/wiki/Charity_(programming_language)>

[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

[Chris Angelico]

On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase
<pytho...@tim.thechases.com> 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

[Tim Chase]

On 07/19/12 13:28, Chris Angelico wrote:
> On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase
> <pytho...@tim.thechases.com> 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

[John Gordon]

In <mailman.2317.1342730...@python.org> Dennis Lee Bieber <wlf...@ix.netcom.com> 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"

[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

[Chris Angelico]

On Fri, Jul 20, 2012 at 7:01 AM, John Gordon <gor...@panix.com> wrote:
> In <mailman.2317.1342730...@python.org> Dennis Lee Bieber <wlf...@ix.netcom.com> 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 looooooooong way off...

ChrisA

[John Gordon]

In <mailman.2320.1342736...@python.org> Chris Angelico <ros...@gmail.com> 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*

[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

[Ian Kelly]

On Thu, Jul 19, 2012 at 3:01 PM, John Gordon <gor...@panix.com> wrote:
> In <mailman.2317.1342730...@python.org> Dennis Lee Bieber <wlf...@ix.netcom.com> 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.

[Devin Jeanpierre]

On Thu, Jul 19, 2012 at 5:01 PM, John Gordon <gor...@panix.com> 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

[Steven D'Aprano]

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

[rusi]

On Jul 20, 12:24 pm, Steven D'Aprano <steve

+comp.lang.pyt...@pearwood.info> wrote:
> I often end up writing more
> documentation than code, sometimes by a factor of two. Fortunately I love
> to write. As may be obvious.

Now, now! Really??

[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 looooooooong 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

[Mark Lawrence]

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

> On Thu, Jul 19, 2012 at 3:01 PM, John Gordon <gor...@panix.com> wrote:
>> In <mailman.2317.1342730...@python.org> Dennis Lee Bieber <wlf...@ix.netcom.com> 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.

[Erik Max Francis]

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

[Virgil Stokes]

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/

[BartC]

"Erik Max Francis" <m...@alcyone.com> wrote in message
news:GsKdnWOQPKOOvZTN...@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

[Hans Mulder]

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


-- HansM

[Erik Max Francis]

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

[Erik Max Francis]

On 07/20/2012 03:28 AM, BartC wrote:
> "Erik Max Francis" <m...@alcyone.com> wrote in message
> news:GsKdnWOQPKOOvZTN...@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

[Albert van der Horst]

In article <5006b48a$0$29978$c3e8da3$5496...@news.astraweb.com>,

Steven D'Aprano <steve+comp....@pearwood.info> wrote:

<SNIP.
>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

[Chris Angelico]

On Tue, Jul 24, 2012 at 2:18 AM, Albert van der Horst
<alb...@spenarnc.xs4all.nl> 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

[Albert van der Horst]

In article <Oc-dnUqKG91pgpbN...@giganews.com>,
Erik Max Francis <m...@alcyone.com> wrote:
<SNIP>

>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.)