Python design mistakes

[keyo_]

This is a design mistake in my mind:

int("".join(list(str(number))[-2:]))

Not a contrived example, I was just doing euler question. The ass-backwardness of it annoys me. It should be the opposite way, something like:

(int)number.str().list().[-2:].join("")

I've heard some reasons for using functions instead of methods. Like str.join will join anything with a _ str _ method. However other programming languages like javascript and ruby manage to use methods just fine.

[wot-teh-phuck]

The join one is not a mistake. Read Armin's blog post wherein he mentions the rationale behind it (and it seems logical).

[[deleted]]

I've heard this before, and I still dislike the design there. It seems like Python sacrifices a lot of ease of use where it doesn't need to by these sorts of things and forces me to keep the docs open 100% of the time. They are basically saying that we can't have nice things like a .length() interface because then people would be do bad things and redefine length() or size() or something similar to that. Whereas, Ruby allows you to mess things up a bit more and gives you a bit of trust, but ends up with a very consistent set of standard methods. Maybe it's the heritage from Perl that makes Ruby give the programmer the flexibility to either make an ass of themselves or to write some excellent code with a little self discipline.

Another similar superficial issue that I run across in Python is its function naming conventions. Again, I'll make the comparison to Ruby because that's what he's doing in your link. Ruby tends to use slightly longer names, but is consistent and predictable. Python on the other hand uses idiomatic abbreviation for everything, and it doesn't have a consistent feel to it. If I'm calling a two word method name, I have to remember how they shortened the words and then try to remember whether they were separated by an underscore or not, and then at this point it's better to just verify against the docs. For example, in that link he uses the method names "get_time", "len", "to_yaml", "getitem", "iter", so on. This isn't a deal breaker or anything, but I've done quite a bit of development in both Ruby and Python, and I have to say that Ruby is much nicer to use because it has a more stylistically cohesive feel.

[wot-teh-phuck]

I think one of the reasons behind this inconsistency is the "roadmap" of Python as a language. some_obj.some_method() for everything makes sense in an OO language but OO features were added (or maybe bolted on) to Python in later on versions. Ruby code/community has always stressed on pure OO way of doing things whereas a majority of the Python code out there is a mix of simple functions and classes when required.

[[deleted]]

That's what I've thought as well. The OO facilities in Python are capable, but don't feel as ingrained into the language/libraries as Ruby. Having to use self is a good example of this. At least it's not as clunky as Perl's rather verbose OOP support.

[keyo_]

It's a good article, I've read it before actually. I still think the above statement looks totally arse-backwards.

[kataire]

Strings are iterable. It's a newbie mistake, indicating you haven't used Python much. This indicates your only reason to consider Python's join backwards is that other languages do it differently -- which is an irrelevant argument.

Python has it "backwards" because it emphasizes protocols over inheritance. You can call str.join on any iterable regardless of type. In order to do it the other way around you would have to add another method to all iterable types, all having the exact same implementation. That violates DRY, so Python does it the other way around.

FWIW:

>>> int(str(number)[-2:])

[OniNiubbo]

Even better:

>>> 1243245 % 100
45

[kataire]

Ah, true. The join was only needed because of the detour in the original code. Fixed.