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

Python's pre-declared constants are kinda weird

sebsite.pw

Post reply on HN
Print view View original

171–180 of 234 posts

Re: Python's pre-declared constants are kinda weird

#171

Post by lelanthran »

tialaramex wrote: post #139
Animats wrote: post #32

Earlier quoted context omitted.

Misery is trying to retrofit "bool", True/False, and nil/null to a language. C had to do that. Python had to do that. Getting those wrong is one of the classic language design mistakes. It seems like treating "True" as a value that equates to 1 will work, but then the special cases get you. Like being able to perform arithmetic on True. Common language design boners: - Not building in strings. That's now in the past.…

You list a few absences but absences aren't the end of the world, I say it's worse when designers make a booboo where the language semantics are wrong. In C++ there are so many of these it's not sporting but a recurring example from the garbage collected languages would be the for-each loop mistake. Several times now†, people make a language where the way a for-each loop (for each Goose in Geese ...) works is that th…

> What you actually should deliver is an implementation where each time around the loop there's a new variable named Goose, that variable goes away at the end of that iteration and will be replaced by the next one, with the same exact name.

Is this because a closure inside a loop will capture a reference to `Goose`?

I think that this is a capture problem not a variable problem. The closure should always do the right thing and capture the value of all variables (not just ones inside the loop), instead of capturing the reference to the variables.

Then the general problem is fixed to match what developers expect, instead of a specific instance of that class of problems being fixed and working differently to how other captured variables work.

Re: Python's pre-declared constants are kinda weird

#172

Post by scoofy »

zmgsabst wrote: post #113
frollogaston wrote: post #77

Earlier quoted context omitted.

JS is a lot less weird than Python. And Python is what I started with and continue to use half the time. The article missed the most common one, __name__ == "__main__" like wtf

> __name__ == "__main__" What makes this weirder than other languages detecting if they’re an import or an invoked file?

It’s only weird syntactically. Python tends to lean towards intuitive, natural language by default. I would have assumed they’d have created a syntactically straightforward alternative, like:

__this_file__ == “__launch_file__”

or similar. I understand python values “only one way” of doing things, but it would be helpful for readability.

Re: Python's pre-declared constants are kinda weird

#173

Post by thayne »

9dev wrote: post #168
thayne wrote: post #38

Earlier quoted context omitted.

PHP has evolved a lot, but it also still has a lot of cruft from its earlier days. And it has made breaking changes on a scale python probably couldn't get away with.

Show me a language that old without lots of cruft. The worst thing you can find is the standard library, which is just an unsolvable problem.

That's my point. PHP is still an old language with lots of "baggage", just like python is an old language with lots of "baggage".

Re: Python's pre-declared constants are kinda weird

#174

Post by chlorelladevil »

jp_sc wrote: post #23
LPisGood wrote: post #21

Earlier quoted context omitted.

It is certainly the case that isinstance(True, int) returns True, even today.

I got a bug for not remembering it, a couple of years ago: https://jpscaletti.com/p/8/true-false-one-and-zero

Hmm. Having read your post, surely the bug is having a function where

    set(foo, false)
removes foo entirely. What if you want foo to have the value False? Even besides the unintended behaviour where 0 is coerced to a boolean value, this function seems poorly designed.

Re: Python's pre-declared constants are kinda weird

#175

Post by impulsivepuppet »

frollogaston wrote: post #77
Revanche1367 wrote: post #73

A lot of Python design decisions have felt weird and off to me but they’ve long justified it by saying that it’s those little ugly design choices that make the language so usable and effective in practice compared to more well-designed languages that hardly anybody uses. I’m not enough of an expert to clearly say if that’s really true, but imo, there’s a repeated pattern of slightly weirdly designed languages becomin…

JS is a lot less weird than Python. And Python is what I started with and continue to use half the time. The article missed the most common one, __name__ == "__main__" like wtf

this isn't uniquely pythonic and JS isn't a great counterexample.

https://nodejs.org/api/esm.html#importmetamain

node also has __dirname and __filename from the good old days.

Re: Python's pre-declared constants are kinda weird

#176

Post by xigoi »

frollogaston wrote: post #86
Revanche1367 wrote: post #84

Earlier quoted context omitted.

I’m not a regular JS user and haven’t touched the language in a long time, but I remember a (popular?) website for teaching modern JavaScript mentioned that some aspect of the function/macro that returns the type of an object was just plain wrong in a specific and important case. This was years ago however, so maybe the problem isn’t there anymore. Anyhow, I added JS to the list mainly because it is known as a badly…

There are certainly weird things about it, but they're all things you can ignore especially in modern times, whereas in Python you're constantly dealing with it head-on.

JavaScript still has many quirks you can’t just ignore, such as sort() using string comparison by default.

Re: Python's pre-declared constants are kinda weird

#178

Post by xigoi »

toast0 wrote: post #152
Chinjut wrote: post #142

Earlier quoted context omitted.

Haskell, Lean, and Agda too. But even if Python were the only one, it wouldn't be weird to someone for whom this was their first programming language. It would just seem the way programming languages are. There's nothing intrinsically weird about indentation being significant. It's quite visibly part of the code you write and read.

> There's nothing intrinsically weird about indentation being significant. It's quite visibly part of the code you write and read. The idea is fine, I guess, although I certainly don't care for it. Where it gets most nasty is that whitespace that looks the same (in your editor) might not be equal and will cause you pain.

> Where it gets most nasty is that whitespace that looks the same (in your editor) might not be equal and will cause you pain.

This is why idiomatic Python only uses spaces for indentation.

Re: Python's pre-declared constants are kinda weird

#179

Post by wodenokoto »

scoofy wrote: post #172
zmgsabst wrote: post #113

Earlier quoted context omitted.

> __name__ == "__main__" What makes this weirder than other languages detecting if they’re an import or an invoked file?

It’s only weird syntactically. Python tends to lean towards intuitive, natural language by default. I would have assumed they’d have created a syntactically straightforward alternative, like: __this_file__ == “__launch_file__” or similar. I understand python values “only one way” of doing things, but it would be helpful for readability.

No, the “readable” shortcut would have been

    if __main__:
There are no magic strings to remember and the IDE can help you look up variables.

Re: Python's pre-declared constants are kinda weird

#180

Post by jrrv »

selcuka wrote: post #116
jrrv wrote: post #104

Earlier quoted context omitted.

I clicked on half a dozen of these at random and none of them are weird. For example, why would you expect `Boolean("false")` to equal `false`? It's a string, and bears no relation to the Boolean type. [0] [0] https://wtfjs.com/wtfs/2014-10-07-true-equals-false

I agree that the examples on that site are not very good. What about [1, 2, 3] + [4, 5, 6] == "1, 2, 34, 5, 6" or parseInt(0.000001) == 0 parseInt(0.0000001) == 1 or "" + 5 == "5" "" - 5 = -5

> [1, 2, 3] + [4, 5, 6] == "1, 2, 34, 5, 6"

Well, `+` is a string operator. There's no infix array concatenation operator, so makes sense.

> parseInt(0.000001) == 0 > parseInt(0.0000001) == 1

Never knew about this one! Quite funny actually and I'm curious why that happens. I suppose because `0.0000001` is represented as an exponent rather than a decimal? Although I haven't seen `parseInt` used since 2015, you should use `Number`.

> "" + 5 == "5" > "" - 5 = -5

iirc

`+` operator: - If LHS is a string, concatenate - Otherwise, cast to Number and perform arithmetic.

`-` operator: - Perform arithmetic.

All of these are explainable, and never catch anybody competent out in practice. And, since TypeScript is the norm in a lot of places now, it's never an issue.

Post reply on HN