Live data from Hacker News

Python's pre-declared constants are kinda weird

sebsite.pw

181–190 of 234 posts

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

#181
post #172

Earlier quoted context omitted.

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.

Again, this is a CS/Math major kind of thinking. The term __main__ means nothing syntactically. If we care about language acquisition -- thus language adoption -- it is always better to make "very common terms" in the language understandable to someone who is completely illiterate to your formal language.

I honestly think one of the main reasons why python is so successful is as simple as:

    print "Hello world!"
...and later:

    print("Hello world!")
It might not seem like much, but when you're asking someone to pick up a language outside of a classroom setting, it's just much more intuitive than:

    echo "Hello world!";
or:

    console.log("Hello world!");
or god forbid:

    public class GFG{

        public static void main(String[] args) {

            System.out.println("Hello world!");

        }

    }
These little things matter in the long run, even if they don't seem like they matter when you're already fluent.

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

#182

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…

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

Now your "lalanthran closures" can't mutate the world because they work exclusively with copies not references, if they try to mutate something then whatever they're touching was just a copy not the real thing.

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

#183

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

> The article missed the most common one, __name__ == "__main__" like wtf

It makes perfect sense, but also is not an example of what TFA is about. In fact the entire point of having that `if` check is that `__name__` is not a constant.

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

#184

Earlier quoted context omitted.

> 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…

> 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. Now your "lalanthran closures" can't mutate the world because they work exclusively with copies not references, if they try to mutate something then whatever they're touching was just a…

> Now your "lalanthran closures" can't mutate the world because they work exclusively with copies not references, if they try to mutate something then whatever they're touching was just a copy not the real thing.

That is true. I still don't like the idea of "Here is a general rule. It applies everywhere but $HERE." Whether that general rule is "All captures are by value" or "All captures are by reference", the rule should not have exceptions based on context in the code.

A better tradeoff would be to have the general rule (whatever it is) apply everywhere, along with syntax for capturing (or not, depending what the default is). I'd rather have it grab everything by value, and for those things that are susceptible to race conditions (because more than one closure is modifying it), explicitly annotate it with a sigil (`&`, or a keyword, or similar).

I mean, in pseudocode, when I see:

    ... variables x, y and z are declared and used in this scope ...
    return (x, y, x) => { ... }
I don't want to have to examine the surrounding scope to know whether or not `y` is susceptible to a race. I'd rather just see:

    ... variables x, y and z are declared and used in this scope ...
    return (x, &y, x) => { ... }
An alternative viewpoint is that many languages have immutable variables and they seem to be getting along just fine without needing mutation on variables, shared or otherwise.

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

#185

Earlier quoted context omitted.

> JS is a lot less weird than Python. I challenge you to find Python behaviors as weird and off-putting as anything here: https://wtfjs.com/

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…

> that everyone hits and is also annoying after

I don't know why you think it should be so common, because mutating a parameter with a default value doesn't make a lot of sense in the first place. But also it's one of the single most well-documented things about the language, and it's also historically been found useful when invoked intentionally (https://stackoverflow.com/questions/9158294).

Also, we call that a list, not an array.

> no relative ones either

It certainly does have relative imports, and I have no idea what you think is "weird" about the import system.

If you're talking about dynamically importing from a string path, that, too, works just fine with a relative path. It's just that relative paths are relative to CWD rather than the source file, just like any other time you open a file.

If you're annoyed that you don't just specify a file path, keep in mind that a Python module doesn't have to correspond to a file at all. What you ask for in this case is impossible and nonsensical.

> weirdly no anonymous functions

Incorrect. `lambda`.

> differences between asyncio and blocking

This is like saying "differences between cars and traffic jams". It makes no sense whatsoever.

I could go on, but the short version is that you do not know what you are talking about.

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

#186
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

A lot of them are also about nulls and == vs ===, which are weird, but they're weird in many langs. Like Python has the whole == vs `is`. You just learn the convention and use it. Same with typecasts.

Distinguishing object equality from object identity is not even remotely comparable to having implicit, unintuitive casts everywhere.

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

#187
post #3

Past: https://news.ycombinator.com/item?id=49284392 (with my comment), https://news.ycombinator.com/item?id=49250370 . Nice to see it get attention this time.

… I take it back.

It would be nice if, just once, we could have a thread about interesting esoteric Python behaviours without people taking it as an invitation to dump their laundry list of things they personally don't (or do, for that matter) like about Python, or to make inane comparisons to other languages (especially JavaScript, for very unclear reasons) while being simply uninformed.

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

#188

The __debug__ constant is really weird - any block of code guarded with `if __debug__:` will be entirely omitted from the bytecode under PYTHONOPTIMIZE=1. This and `assert` are the only two examples of real “conditional compilation” in Python. This is also the reason why you cannot assign to __debug__: doing so would make it possible to invalidate the compiler’s assumption about `if __debug__:` statements.

I honestly have never even heard of this constant and I feel like I've been using python for a pretty long time. Although maybe my memory for some things just gets garbage collected if I don't use it enough. Does it actually get used that often in real world code? Seems like it might be kind of risky.

Because Python lets you get as far as it does without formally learning everything, but is also expected to suit a huge variety of use cases, it ends up with lots of hidden details that are irrelevant to most users.

The most direct way to find out about `__debug__` is to read `python -h` (or the usage message, which is not all that easy to trigger) in full, and then head over to the documentation.

> Does it actually get used that often in real world code?

https://github.com/search?q=language%3APython+%2F%28%3F-i%29...

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

#189

I remember reading that in early versions of Python there was no built in True and False. Each user would implement this themselves as True = 1 False = 0 then later these got added to the language. In Python 2 you could still reassign and swap them so that 'if False' was actually true! True, False = False, True Python 3 you could no longer reassign them.

I was surprised TFA didn't mention this, or seemingly know about it.

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

#190

Python is just such a weird language in general despite its popularity that I honestly cannot recommend anyone who starts programming to choose Python as their first language, contrary to popular sentiments. I mean, I was one of the first person to start using Python when I was in grad school almost a decade ago when everybody else in my field was still using Matlab for their lab code, for the simply reason that Nump…

> and then you'll have to deal with all of its weirdness: significant whitespace

By "weirdness" here you apparently mean not having to worry about matching up curly braces, and getting what you want automatically just for indenting your code the way you're supposed to indent it anyway... ?

> truthiness

Which is different from how it works in other similar languages, how exactly?

> duck typing

Which is weird, how exactly?

> GIL

You can go a lot further than five minutes in Python without having to worry about threads at all, and if you do attempt threading, unless you're writing C extensions, the worst thing the GIL does is deny you the multi-core processing you thought you were going to get.

> distribution/packaging

Tons better now, but it was honestly never difficult, people just didn't care.

Post reply on HN