My python annoyances so far

[Steven D'Aprano]

Well, why do some things in the library have to be functions, and
other things have to be class methods?

Why aren't they all just either functions or class methods? like
perhaps ruby.

Perhaps you should read about the Kingdom of Nouns:

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

 

[Steven D'Aprano]

Perhaps because some things are more naturally function like? For
'instance' (pardon the pun), functions shouldn't retain data. They
perform an operation, return data and quit.

Why ever not? How the function performs the operation is an implementation
detail you shouldn't care about. Functions that cache the result of long
time-consuming complications are _good_.

You might also consider generators and iterators and co-routines. None of
those could exist if functions couldn't store data.


[snip]

Another example are with respect to 'int' and 'float' operations. Why
should int(x) be a class?

That's a terrible example, because in fact int and float _are_ classes
(actually types, which are conceptually the same as classes but
implemented differently).

 

[James Stroud]

Actually, it's really simple. When you get right down to it,
*everything* in *every* current implementation of Python is either a one
or a zero. Would you like us to make it all zeros?

Perhaps you should meditate on the idea to the concept of "sufficient
and necessary complexity" ...

Here is something on which to meditate: classes become functions when
you get the quantum mechanics just so!

py> class add(object):
.... def __new__(self, a, b):
.... return a + b
....
py> c = add(3, 1)
py> c
4
py> type(c)
<type 'int'>
py> add
<class '__main__.add'>
py> def add(a, b):
.... return a + b
....
py> add(3, 1)
4

 

[Alex Martelli]

detail you shouldn't care about. Functions that cache the result of long
time-consuming complications are _good_.

Not necessarily --
<http://blogs.msdn.com/oldnewthing/archive/2004/12/20/327369.aspx>
asserts the exactly opposite principle, "Don't save anything you can
recalculate"... of course, the best approach is generally a compromise,
but it's good to be aware of the potentially high costs of caching.


Alex

 

[John Nagle]

Not necessarily --
<http://blogs.msdn.com/oldnewthing/archive/2004/12/20/327369.aspx>
asserts the exactly opposite principle, "Don't save anything you can
recalculate"... of course, the best approach is generally a compromise,
but it's good to be aware of the potentially high costs of caching.


Alex

Abelson and Sussman has a better discussion of this subject.
Look under "memoization".

John Nagle

 

[7stud]

I find Guinness annoying.

lol.

 

[Steven D'Aprano]

Not necessarily --

Absolutely -- I didn't mean to imply that functions should _always_ cache
their "complications" (I meant to write calculations, but obviously my
fingers weren't paying attention to my brain).

<http://blogs.msdn.com/oldnewthing/archive/2004/12/20/327369.aspx>
asserts the exactly opposite principle, "Don't save anything you can
recalculate"... of course, the best approach is generally a compromise,
but it's good to be aware of the potentially high costs of caching.

Yes -- I wouldn't cache anything that was cheap enough to calculate. What
cheap enough (in time or memory or other resources) means depends on the
circumstances. Nor would I cache things that were likely to change often.

 

[Marc 'BlackJack' Rintsch]

And before someone get's all technical, I know everything in Python is
an 'object' even None, which implies class, or is it the other way around?

Objects don't imply classes. There are object oriented languages without
classes like the Io language. Everything there is an object and the base
object has a `clone()` method to make a copy. So you make copies of
objects and modify them to tweak them into the way you want them.

Ciao,
Marc 'BlackJack' Rintsch

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :
(snip)

Well, why do some things in the library have to be functions, and
other things have to be class methods?
> Why aren't they all just either functions or class methods? like
> perhaps ruby.
>

If I tell you that Python's functions are in fact static methods of
their module, will this make you happy ? Because, while not technically
true, this is conceptually equivalent.

Or if you prefer to stick to technical truth, python's methods are
nothing more than a thin decorator around a function object (yes,
Python's functions *are* objects) - so in fact, there are *only*
functions - sometimes wrapped into a method object, sometimes not,
depending on how you access them.

In both cases, the fact that you don't have enough knowledge of a
language to understand it's design, and/or the fact that this design is
different from other one you already know, doesn't by itself make this
design an "annoyance".

 

[Bruno Desthuilliers]

Marc 'BlackJack' Rintsch a écrit :

Objects don't imply classes. There are object oriented languages without
classes like the Io language. Everything there is an object and the base
object has a `clone()` method to make a copy. So you make copies of
objects and modify them to tweak them into the way you want them.

And FWIW, in Python, classes are objects too, and are attributes of
their instances. Which makes Python quite close to prototype-based
languages like Io, Self or Javascript.

 

[Bruno Desthuilliers]

7stud a écrit :

Every language has annoyances. Python is no exception.

Sure. But we may disagree on what are actually Python's annoyances !-)

Post away.
Anyone that is offended can go drink a Guinness.


I thought those were pretty ugly myself. Now, I am used to them.

FWIW, you shouldn't have to directly use __magic__ methods - or only in
very special corner cases.

 

[Bjoern Schliessmann]

Here is something on which to meditate: classes become functions
when you get the quantum mechanics just so!

s/become/can behave like/



Regards,


Björn

 

[Bjoern Schliessmann]

Perhaps you should read about the Kingdom of Nouns:

<http://steve-yegge.blogspot.com/2006/03/
execution-in-kingdom-of-nouns.html>

Really cool. Thanks for sharing the link.

Regards,


Björn

 

[flifus]

If I were rude, I would ask now why you don't use ruby. But I bet
ruby has some annoyances ready for you too.

Regards,

Björn

Well, I'd use ruby but python is everywhere, and ruby isn't. All the
applications that interest me are scriptable in python, not ruby.

 

[Bjoern Schliessmann]

Well, I'd use ruby but python is everywhere, and ruby isn't. All
the applications that interest me are scriptable in python, not
ruby.

Pity that you don't comment core topics.

Regards,


Björn

 

[Antoon Pardon]

7stud a écrit :

Sure. But we may disagree on what are actually Python's annoyances !-)

That is probably why the subject says: "my annoyances"

 

[Bruno Desthuilliers]

Antoon Pardon a écrit :

That is probably why the subject says: "my annoyances"

May I suggest that before finding something annyoing, one has to use it?
When I first discovered Python - and before having any experience with
it - I thought that not having declarative static typing and access
restriction was kind of an annoyement. Real world experience made me
change my mind...

 

[Antoon Pardon]

Antoon Pardon a écrit :
May I suggest that before finding something annyoing, one has to use it?

Sure you may. But what do you mean by use? Are the first exetcices a
newbee tries out already using or do you think these don't count?

When I first discovered Python - and before having any experience with
it - I thought that not having declarative static typing and access
restriction was kind of an annoyement. Real world experience made me
change my mind...

That people may (probably) change their mind later doesn't make it any
less annoying at the moment. The frustrations of the moment don't
disappear just because the more experienced knows these will fade in
the future.

 

[Sion Arrowsmith]

I know what you mean. I always write:

someStringVar.len

and then I backspace and retype:

len(someString).

But then again, I can never remember whether length is a member or a
method in other languages.

.... or whether it's called length, size, count or len. Or even
whether the language is consistent from one container class to
the next.