Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A bite of Python

access.redhat.com

Post reply on HN
Print view View original

121–130 of 168 posts

Re: A bite of Python

#121

Post by kstrauser »

dschiptsov wrote: post #48

"Reusable integers" is a real fail - it violates the principle of least surprise and introduces a nasty inconsistency - all integers should logically be (refer to) the same integer object, not just the first 100. Assert is a statement, not an expression, so do not use it as an expression. One should never compare floats. This is taught in any freshman CS course. The limitation is due to the standard encoding of float…

> "Reusable integers" is a real fail - it violates the principle of least surprise and introduces a nasty inconsistency - all integers should logically be (refer to) the same integer object, not just the first 100.

I find the concept of special-casing ints to behave that way to be surprising and inconsistent. If ints act that way, shouldn't strings? And if they (very much unexpectedly) did, why not every other type?

"is" is very useful on its own. "variable is None" is a common and powerful idiom entirely distinct from "variable == None". There are many cases when you want to compare object identity. None of those use cases apply to ints where "==" is always the correct way to compare them, so the fact that "a == b" and "a is b" might occasionally be the same or different doesn't affect anything at all in practice.

Re: A bite of Python

#122

Post by look_lookatme »

bpicolo wrote: post #74
dec0dedab0de wrote: post #66

Earlier quoted context omitted.

I love Python, but I have to agree on this one.

I mean, this one is solvable by not using magic constants. Pretty easy to avoid. Can also lint it.

How often do people write production software that doesn't have string literals?

Re: A bite of Python

#123

Post by [deleted] »

catnaroek wrote: post #117
coldtea wrote: post #93

Earlier quoted context omitted.

> Apparently not obvious enough for JonnieCache, who said: “If you have the process quit it definitely stops them from being false though.” He meant from being false subsequently in the program. I see we were joined by Technically Correct Man too. http://9gag.com/gag/a5PmrLq/technically-correct-man-the-man-...

> He meant from being false subsequently in the program. But, you see, the assertion is no less false just because the process was aborted. The fact remains that there exists a reachable state for which the assert fails. So apparently what I meant is no more obvious to you than it was for JonnieCache.

[deleted]

Re: A bite of Python

#124

Post by xapata »

pvdebbe wrote: post #56

One Python gotcha that has bitten people in my company a lot: fun_call('string1', 'string2' 'string3') That is, missing commas and subsequent string concatenations can lead to nasty errors. I wish Python didn't nick this from C and would have just enforced the use of + to concat over-length strings, if they need to be split to multiple lines.

They considered dropping that for Python 3. I forget the reason why they changed their minds, but there's probably a PEP about it. You may find that their discussion will change your mind as well.

Re: A bite of Python

#125

Post by skywhopper »

drauh wrote: post #119
skywhopper wrote: post #95

I would never accuse Python of "language clarity and friendliness". Far from it. For someone who came up through C, Java, Perl, and Ruby, but who's wrangled with Python, Javascript, Go, and even Haskell in recent years, I still find Python mysterious, self-contradictory, and filled with implicit rules and assumptions that are entirely un-intuitive to me far more than other languages. And yet, people seem to like it.…

I'm afraid I disagree. I programmed in a variety of languages in grad school (physics): C, C++, Fortran 77, Tcl, Perl, Matlab, Maple, Mathematica, IDL, Emacs LISP, etc. Not to mention the stuff I started on in high school. When I switched my analysis to Python, I became so much more productive. And other science researchers I have known have echoed this sentiment. Even writing a C module to speed up my Python was pre…

Yep, this was my point. I'm curious what makes Python seem so obviously clear to other people, but not to me. Maybe it's the OO approach. I had done a lot of Java, Smalltalk, and Ruby before I ever tried to approach Python. Maybe it's because Python's OO support feels (to me) bolted on compared to those other languages which are obviously OO from the bottom up, and I'm unwittingly trying to apply mental models I developed in those other languages to how I think about Python.

Re: A bite of Python

#126

Post by xapata »

skywhopper wrote: post #125
drauh wrote: post #119

Earlier quoted context omitted.

I'm afraid I disagree. I programmed in a variety of languages in grad school (physics): C, C++, Fortran 77, Tcl, Perl, Matlab, Maple, Mathematica, IDL, Emacs LISP, etc. Not to mention the stuff I started on in high school. When I switched my analysis to Python, I became so much more productive. And other science researchers I have known have echoed this sentiment. Even writing a C module to speed up my Python was pre…

Yep, this was my point. I'm curious what makes Python seem so obviously clear to other people, but not to me. Maybe it's the OO approach. I had done a lot of Java, Smalltalk, and Ruby before I ever tried to approach Python. Maybe it's because Python's OO support feels (to me) bolted on compared to those other languages which are obviously OO from the bottom up, and I'm unwittingly trying to apply mental models I deve…

But Python is OO from the bottom up. Unlike Java, everything in Python is an object.

Perhaps your experience with objects in other languages has given you a different mental model for what an object is. I find Python objects to be more straightforward than in other languages, especially because classes are objects, too.

Re: A bite of Python

#127

Post by xapata »

commenter23 wrote: post #16

The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. It's because the comparison operators are defined for every value. That is, "True https://docs.python.org/3.0/whatsnew/3.0.html#ordering-compa... ). This is also not a case of Python doing something useful, like with '"foo"*2'. The result of the comparison is defined, but it'…

> not ... something useful

Intertype comparison is useful for sorting a list of heterogenous types. But for Python 3 they decided that use case wasn't so important.

Re: A bite of Python

#128

Post by JoachimSchipper »

skywhopper wrote: post #95

I would never accuse Python of "language clarity and friendliness". Far from it. For someone who came up through C, Java, Perl, and Ruby, but who's wrangled with Python, Javascript, Go, and even Haskell in recent years, I still find Python mysterious, self-contradictory, and filled with implicit rules and assumptions that are entirely un-intuitive to me far more than other languages. And yet, people seem to like it.…

I usually find it fairly easy to figure out what Python code does... as long as no errors occur. The fact that basically no Python code documents what errors it can throw/generate is really annoying.

Re: A bite of Python

#129

Post by skywhopper »

xapata wrote: post #126
skywhopper wrote: post #125

Earlier quoted context omitted.

Yep, this was my point. I'm curious what makes Python seem so obviously clear to other people, but not to me. Maybe it's the OO approach. I had done a lot of Java, Smalltalk, and Ruby before I ever tried to approach Python. Maybe it's because Python's OO support feels (to me) bolted on compared to those other languages which are obviously OO from the bottom up, and I'm unwittingly trying to apply mental models I deve…

But Python is OO from the bottom up. Unlike Java, everything in Python is an object. Perhaps your experience with objects in other languages has given you a different mental model for what an object is. I find Python objects to be more straightforward than in other languages, especially because classes are objects, too.

If it really is OO, then the global `len()` function and like explicitly declaring "self" in method declarations makes it _feel_ bolted on (to me). Why is `len()` special? I immediately question what other basic operations aren't methods, but global functions.

And as for method declaration, if you aren't satisfied with implicit self, I much prefer Go's choice of having you declare the self reference for methods before the method name, instead of in the argument spec list (which then doesn't match the calling list). Python's way makes it feel like the compiler writer couldn't be bothered to hide the OO implementation on the declaration side, but embraced it on the calling side.

Meh, I know these have been hashed over a thousand times here. Just some of the things that rub me the wrong way when I've tried to deal with Python.

Re: A bite of Python

#130

Post by vram22 »

HerrMonnezza wrote: post #76
sitkack wrote: post #70

Earlier quoted context omitted.

I would argue that one should never use '-O' it also strips doc strings from running code. Not really an `optimization` but they had do something right? One couldn't run __unoptimized__ in production could they?

> I would argue that one should never use '-O' it also strips doc strings from running code. Python `-OO` strips docstrings, `-O` basically only disables assertions. See: http://stackoverflow.com/a/4777156/459543

>See: http://stackoverflow.com/a/4777156/459543

Or just do "python -h":

-O : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x -OO : remove doc-strings in addition to the -O optimizations

Same on both Py 2 and 3.

Post reply on HN