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

211–220 of 234 posts

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

#211

Post by frollogaston »

AdieuToLogic wrote: post #157
frollogaston wrote: post #92

Earlier quoted context omitted.

There are reasons all those Py libraries with C code didn't just do it in SWIG.

> There are reasons all those Py libraries with C code didn't just do it in SWIG. And those reasons are?

The point of SWIG is it works across many langs, but this comes at a cost. The SWIG .i and autogen'd C wrapper are extra layers that can get annoying, particularly during debug. Always hated dealing with SWIG'd libs at work. And Python C modules give easier control over Python specifics.

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

#212

Post by frollogaston »

gucci-on-fleek wrote: post #133
stouset wrote: post #71

Earlier quoted context omitted.

I’ll never not be bitter than Python “won” the scripting language war over Ruby, more or less just because someone did a bit of AI work in it first and it took over that space by default. Ruby has such a nice holistic consistency to it. With a few exceptions, it feels like it was conceived of by one person with a core idea in mind. Python feels like a mess.

> I’ll never not be bitter than Python “won” the scripting language war over Ruby, more or less just because someone did a bit of AI work in it first and it took over that space by default. This is just my personal opinion with no data to back it up, but I suspect that Python "won" because it has excellent Windows support, while Ruby doesn't. Even a decade ago, Python's website offered an official native Windows inst…

This could be it. The classic student with a Windows laptop and git-bash installed, where they think git and bash are the same thing, also PuTTY.

I also wonder how many people gave up on Python just because the installer doesn't put it in your PATH. You'd install Python then no python, wtf. Ok so https://discuss.python.org/t/python-command-not-found/22255 ... Then you fix it and it runs the wrong version of Python.

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

#213

Post by Animats »

lelanthran wrote: post #171
tialaramex wrote: post #139

Earlier quoted context omitted.

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…

The interior of a for-loop is only a scope, not a closure. In most non-dynamic languages you can't package up the state and hold onto it beyond the life of the loop, which is what closures are for.

Most trouble in this area came from the iteration variable outliving the loop. That's not good when the iteration variable is a pointer. In C, it often is, and at the end of the loop, it points to an invalid address. It was a change to C (when?) to make the iteration variable go out of scope before code after the loop could get at it.

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

#214

Post by thayne »

9dev wrote: post #195
thayne wrote: post #173

Earlier quoted context omitted.

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

Just like C# has baggage. Or R has. Or Go, to some extent. This is a non-sequitur.

I don't disagree with any of that. The context for my comment was (paraphrased):

GP: python has baggage because it is old

P: that can be changed. Look at PHP

Me: PHP still has baggage, despite its evolution. You can't really get rid of it without making major breaking changes.

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

#215

Post by ModernMech »

Daishiman wrote: post #146
frollogaston wrote: post #94

Earlier quoted context omitted.

A lot of those are stuff I'd never do like `Test.prototype = null;`. Some are legit footguns, but they rarely get in your way. Python has weird file imports (no relative ones either), broken package management, historical differences between asyncio and blocking that still cause issues, threading/GIL caveats that trip up even experienced users, indentation for scope (esp weird given it was designed for REPL), weirdly…

What you put as an example isn't a footgun if you know how the language evaluation rules work. Once you understand that the "footgun" explains a dozen behaviors, which may be a weird behavior but it is consistent.

A property of footguns is they make sense and are coherent to people who do understand them. To them they are just useful tools (i.e. guns).

A gun becomes a footgun when you put it in the hands of someone who doesn’t understand how it works and they promptly blow off their foot.

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

#216

Post by jp_sc »

chlorelladevil wrote: post #174
jp_sc wrote: post #23

Earlier quoted context omitted.

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.

I don't remember the specifics, it might have been a simplification for the example

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

#217

Post by frollogaston »

xigoi wrote: post #176
frollogaston wrote: post #86

Earlier quoted context omitted.

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.

That one does suck. I'd get it if did the same thing, but it doesn't.

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

#218

Post by frollogaston »

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

All of these are cause JS builtins like to auto-cast things. + only accepts strings or numbers, - only accepts numbers. Really these should be errors instead, but it's also not very surprising or annoying once you know this. Basically, don't perform arithmetic on things that aren't numbers.

The name parseInt suggests it takes a string. Especially "" - 5, why?

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

#219

Post by frollogaston »

jrrv wrote: post #180
selcuka wrote: post #116

Earlier quoted context omitted.

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…

parseInt wants a string. If the input isn't a string, it calls toString. 0.0000001.toString() gives "1e-7". parseInt takes the first number it seems in a string, so 1 in this case, or like parseInt("123asdfasdf") gives 123.

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

#220

Post by mixmastamyk »

ModernMech wrote: post #210
mixmastamyk wrote: post #203

Earlier quoted context omitted.

Not every improvement is perfect, that’s true. I in particular fought against walrus syntax and don’t use pattern matching for other reasons. Python is also boxed in by its history. Some of the things you want done are incongruent with its design. Many people like them however. And you’re being way too charitable to that dumbass comment.

I guess what I’m trying to do is draw a distinction between “improvement” and “change”. We can agree to disagree but my view is the things I called anti-features are not improvements at all, but rather loaded footguns. Python would be more coherent language without async/unenforced type hints/non exhaustive pattern matching. Like you say, it’s constrained by its history and I feel a lot of the recent changes are to m…

Type hints are very helpful on big projects. And are enforced by other tools. Honestly, this kind of criticism shows a lack of experience, and denial of reality for an almost 40 year old language.

It sounds like scoffing at a Silver medalist to me.

In fact, Python is better at what it does than almost anything from the era. That’s why we use it. Nothing is ever going to be perfect because better solutions are emergent, and reverse time travel does not exist.

Post reply on HN