Got a music degree, decided the career wasn't for me, went to a programming incubator, really struggled with interviewing for a while, got a job at a startup, got a job at FAANG, here I am a decade after the career switch

Yep same. "Teach yourself to eat chocolate."

had a french voice in my head going "teache yourself to eatee chocolate"

Sounds good to me!

Fun article! Particularly enjoyed the anecdotal evidence from individual soldier's writing.

Studying the civil war is really interesting and I wish schools did a better job of it. There is so much material from letters people wrote at the time that is just fascinating to read.

Thanks, I enjoyed this and it rings true. This abstract concept of "space" getting filled up thoughtlessly, and that "space" being created by unnecessarily breaking things up into smaller parts that don't really need to be separate, makes a lot of sense and I think I've seen this happen.

The article stops short of proposing a clear plan for how to handle the opposite problem, though: Entrenched monoliths. Once a class (or other abstraction) has grown for long enough (e.g. perhaps someone has read this article and is trying to avoid unnecessary complexity of code structure), it can become very difficult to break it up.

Try not to worry about what others think of you, and definitely don't think about IQ. Judgment is so much more important than speed. Why are you concerned with speedy thinking?

Made me laugh out loud

And maybe even one day, the abbreviation will become so ubiquitous that it becomes divorced in practice from the original referent.

Lol

First example seems odd? The author acknowledges that the two proposed alternatives (printing "<function exit>" or actually exiting) aren't great. The fact that the Python REPL provides a helpful hint seems like extra effort to make your life easier. This is especially notable given that in the next example, the author's complaint is about a command _not_ providing special guidance about the thing the user is probably trying to do.

I'd have done both the hint and the actual result. Like this:

    >>> print
    <built-in function print>
    >>> exit
    <built-in function exit>
    Hint: Use exit() or Ctrl-D (i.e. EOF) to exit
    >>> 

This way, it does do the thing you literally asked for, but also does help a newbie out.

Yes, I completely agree. If you want to teach the user the rules, then you follow the rules. The problem with the Python example is that they DID special-case it, but in an unhelpful way.

The special case is actually less a special case than you'd expect. It's "just" a python object that does some slightly funky things when turned into a string[0]. Making plain `exit` actually exit would mean triggering it accidentally could get too easy or would need a special case in the interpreter itself.

[0] https://github.com/Source-Python-Dev-Team/Source.Python/blob...

It should print the first to stdout and the second to stderr. That's completely consistent with how stdout and stderr are usually used.

The regular Python REPL doesn't distinguish between stdout and stderr (perhaps it should!), but you can embed it in things like Jupyter notebooks that do.

> It should print the first to stdout and the second to stderr. That's completely consistent with how stdout and stderr are usually used.

That makes sense from a unix tool perspective, but not from a python repl perspective. The repl's behavior is to print the result from the last executed statement. For the exit function, the __repr__ method was overwriten to print the message. That way when you type in "exit", the last value would be exit (the function), and the overwritten __repr__ method causes the help message to be printed. There's no way to have it print to both without adding in some repl specific hacks.

    >>> exit
    Use exit() or Ctrl-Z plus Return to exit
    >>> exit.__repr__()
    'Use exit() or Ctrl-Z plus Return to exit'

How about

    def __repr__(self):
        import warnings
        warnings.warn("Use exit() or Ctrl-Z plus Return to exit")
        return super().repr()

What if you aren't in the REPL? Using __repr__ at all seems like an abstraction violation. It should be the REPL's job to layer on special casing for exit.

The actual behavior is indeed a bit ridiculous:

    >>> print('%r' % str)
    <class 'str'>
    >>> def whatisit(x):
    ...     print('It is %r' % x)
    ... 
    >>> whatisit(min)
    It is <built-in function min>
    >>> whatisit(exit)
    It is Use exit() or Ctrl-D (i.e. EOF) to exit

Excuse me?

IMO if the REPL wanted a friendly feature like this, it should be a generic REPL feature, not a hack applied to the function exit.

Also a bit funny:

    >>> def get_function():
    ...     return exit
    ... 
    >>> a = get_function()
    >>> a
    Use exit() or Ctrl-D (i.e. EOF) to exit

You could use the same pattern as DeprecationWarning. It's suppressed by default and test runners like pytest enable it. A new ReplWarning could be enabled by interactive tools only.

I think I agree though: what you really want to special case is the situation where the user types precisely 'exit<cr>' at a REPL prompt, and that hack needs to exist further up the stack than in the implementation of __repr__.

Thanks for this, it never occurred to me it used __repr__ for the message. I just added this to my .pythonrc

    exit.__class__.__repr__ = lambda _: exit()
    quit = exit

Edit, you also need this in your bashrc:

    export PYTHONSTARTUP=~/.pythonrc

> does help a newbie out

… or a long-time dev that switches languages fairly often :)

But really it should just exit. There's really no reason why it shouldn't.

I think telnet does something stupid along the same lines "I know you want to quit but please ask address me as Sir first".

There would be two ways to implement that, neither of which are particularly good. You could either have the exit function call itself from its __repr__ method, which an abstraction violation so egregious it introduces security vulnerabilities (imagine a logger printing repr(thing) to stderr, and someone sneaking the exit function in there for it to print), or you could special case it by making exit a reserved word, which flies in the face of the Python 3 ethos which changed print from a reserved word to a function and breaks a lot of established code.

Programming languages have rules that the programmer is expected to learn. Part of being a programmer is foregoing a certain amount of user friendliness in favor of an environment that is more powerful so that we can actually get things done. Programmers are paid to memorize and follow these rules so that the end user does not have to learn them.

You're trying to think of problems, not solutions.

It's pretty easy to think of a good solution with few enough downsides that overall the design is much better:

In the REPL only, if you type "exit" and press enter, it quits.

No changes to Python semantics required. All code still works. Much friendlier UX.

I wonder what dubious justification the Python Devs would come up with to avoid implementing that (and therefore admitting they've been wrong for 20 years). They'd probably try and claim it is more confusing to beginners or some nonsense like that.

Yeah. "I know it's not right, but it's not totally wrong and probably better than not doing anything" actions as maddening as the behaviour he describes. A world where that's the standard would be chaos.

When you work with _precise_ systems, they sometime take _precise_ input to work. That's kinda just part of the job.

Except in the case of the 'exit' clearly this is accepting and parsing imprecise input in order to guide the user. If the code wasn't looking for 'exit' in order to correct the user (to use 'exit()'), it would just spit out some other error for 'I don't know what you're talking about'. Instead, they actually detect the intent by specifically coding for it... and then ignore it anyway. That's bloody minded.

Except they didn't -- the result of a statement is turned into a string, and the string is printed. There are standard ways of turning objects into strings, and the `__repr__` function on the `exit` object returns that string. If you call that object then it raises an exception that triggers a REPL to cleanly quit.

The code is here: https://github.com/python/cpython/blob/3.12/Lib/_sitebuiltin...

How about making `exit.__repr__` raise a CleanExit exception that gets caught in the outer REPL and then exits?

I'm fairly sure that having any object's `__repr__` throw an exception and exit would lead to even more confusion. Especially if it exits cleanly.

The object shouldn't be in scope anywhere other than the REPL, but that doesn't mean that something, somewhere, isn't stringifying everything because $REASONS and changing the behaviour won't cause an obscure "crash" somewhere unexpected and hard to debug.

If it actually exited, you might incorrectly conclude that exit would work the same way in a script.

How do you feel about java/c++ compiler that give hints like "missing semicolon"? Clearly it knows what's wrong. Why not automagically fix that for you[1]?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

JavaScript automatic semicolon insertion does a great job most of the time, but still leads to bafflement when code like

    const b = 1
    [1, 2, 3].forEach(console.log)

(from your linked page) does the wrong thing, because both forms (with and without a semicolon) are syntactically valid. I would much rather just always use semicolons (or, like Python, never use them) than have to memorise the 5% of oddball cases where I need to add them manually to resolve ambiguity.

I'd actually love that feature!

We have AI now that can write the entire code for you. Surely it's not much to ask that a compiler, as it parses your code and likely already has high confidence you need a semicolon in a certain spot, can just correct it for you and move on. Maybe have a --fix-errors option to the compiler command line or something.

> A world where that's the standard would be chaos.

We saw this play it with web browsers in the late 90s early ‘aughts where they’d do their best to render what they thought you meant if your html was wrong, and it was indeed chaos.

Strict systems with strict inputs makes for a better overall ecosystem.

> The fact that the Python REPL provides a helpful hint seems like extra effort to make your life easier.

I agree; Python is actually helping you out here, since just typing `exit` doesn't actually call the callable.

Also, Python being Python, while not recommended, there's nothing stopping the user from assigning to `exit` then printing it in the repl:

    >>> exit = 42
    >>> exit
    42

What would the author expect Python to do in this instance?

I think the current behavior is worse simply exiting. The only concern with exiting when the user types "exit" is that perhaps the user actually wanted to see the value of the `exit` function. But the current behavior doesn't show the value of the `exit` function either, so it's useless for that use case.

Yeah, and it’s also useful to teach newbies about the usual syntax for doing things rather than introducing special-case magic. It would be _weird_ to just quit after writing a bare “exit”.

ipython intentionally diverges from the regular python REPL. It just quits like you expect without crying about it.

Yep this happened to me yesterday. In a taxi, the driver was following Google Maps, which showed a 22 min ETA, with one or two alternatives adding a minute or so. My phone was open and showed the same options. He felt certain that he knew a better route—via a highway, not a back road—and when he took that first rogue turn, Google Maps adjusted and the ETA instantly dropped to 14 min.

Google's doing it to balance traffic loads. Remember that you're the product, not the customer. Right now it's just in the testing phase, but soon the capability will be sold to municipalities and billboard owners.

I'm not really sure where I sit on this, but I have to admit it's a hell of a capability. There's some big implications of this degree of control over a population.

Is this confirmed or just your speculation? Interesting idea regardless.

are you saying it has a stake in roadway advertisements and prioritizes routes that maximize billboard views per trip? That’s pretty depressing :/ yet also capitalism I guess

Beautiful Country, by Qian Julie Wang. Beautifully written memoir about immigrating to NYC as a child in the 90s. Poignant, sweet, honest, easy to read, fun, not too too emotionally heavy, but also full of lessons about trauma.

Sounds like the thing about "ad blocker sabotage" is about replacing the Web Request API with something called declarativeNetRequest. I've been sifting through documentation but have had trouble seeing why this is any kind of a downgrade for ad blockers. Can someone explain?

It removes the ability to run custom logic to decide whether a net request should be allowed to go through, switching Chrome to a system like Safari's where you can only declaratively specify what you would like blocked.

While Google claims it is a change they are making for security and performance, a lot of people are worried that it is actually intended to make ad blocking harder.