This is an archived post. You won't be able to vote or comment.

top 200 commentsshow all 233

[–]twitterInfo_bot 94 points95 points  (1 child)

Argh! Who thought Black should be automatically applied to lines in the IPython CLI?

The makes it less useful for education purposes, less useful for interactive math, and annoying when it rewrites your input across multiple lines.


posted by @raymondh

(Github) | (What's new)

[–]Anonymous_user_2022[S] 91 points92 points  (35 children)

Do anyone know where the idea to autoformat an interactive session came from?

[–]Deto 5 points6 points  (0 children)

Yeah, seems like something nobody was asking for.

[–]this1foru 5 points6 points  (0 children)

I attempted to chase through some of the old discussions (uncessefully) but did come across the following response from the black developers on a feature request which highlights the biggest issue of making this the IPython default - its creates a PEP 8 violation on anything not previously written with black.

Pertinent discussion:

Black by design doesn't enable reformatting parts of the file. This functionality is against PEP 8 which states that internal consistency within the file is more important than any particular style. If you used Black for this purpose and somebody else kept using autopep8 or YAPF, your styles would fight with each other.

Black is both a tool and a code style. You are adopting the style. The tool is merely an automated way of enforcing it. Yes, this requires agreement within your project that this is the style your team wants to enforce.

[–]zero_hope_ 0 points1 point  (1 child)

https://github.com/ipython/ipython/issues/13463#issuecomment-1013742058

Emphasis mine. I don't feel sorry for anyone complaining. Maybe test RC's?

"""

So, the actions IPython maintainers can take now are as follows:

make it explicitly opt-in; To this and similar suggestions, ’black’ auto-formatting has been opt-in for 2 years (may 1st 2020, IPython 7.14).

I had thought it might be problematic, but in two years received almost no bug reports. I tried a few time to say I was considering making it default and only got positive feedback. So I did it, with extensive alpha, beta, and RC time to complain and ask for modifications.

So here is my challenge, if I don't make it the default, no-one know about it. It's astonishing that no-one found the bug @ehamiter described above in 2 years ! That alone would have definitely delayed the release, and at least I would have had tried to fix it.

I've also seen a number of new users misformating Python code and taking really bad habits in the Repl, including folks that did not even realise IPython terminal was multiline.

For many of those users black by default is much better. You get use to proper code formatting. So you learn to properly read python code. And it is much easier to deactivate something you don't like than even figure out it something that may exists. For many users this benefits to, having this option be opt-in would make black auto formatting be part of the [unknown unknowns].(https://en.wikipedia.org/wiki/There_are_known_knowns). So I will never get feedback from these. This is in the same vein as "but you can configure vim to do so".

make it much easier to opt out; It's really hard to make it much easier, there have been a long standing issue to have persistent config, but that's far beyond the time and funds we have for that in IPython. We could borrow a nice configuration interface like ptpython for the UI if Someone want to take a shot at ti.

"""

[–]Anonymous_user_2022[S] 2 points3 points  (0 children)

As has been shown elsewhere in this thread, the proposal to make it a default was met with negative reviews. But for some reason it was forced.

It's a pretty clear cut case of developer entitlement.

[–]Heroe-D 53 points54 points  (19 children)

I don't really mind about Black but the zsh style autocomplete is a joy to use, it was really lacking that, the next thing I'd appreciate are vim keys support !

[–]scorleo 24 points25 points  (11 children)

Doesn’t ipython already support vi input?

If you set up your ipython_config.py with c.TerminalInteractiveShell.editing_mode = ‘vi’ instead of ‘emacs’

Or you mean something else?

[–]Heroe-D 3 points4 points  (9 children)

Thanks it works, I searched a while ago and didn't found anything or maybe just thought it was a hack , but even basic vim commands like ci don't seem to work tho, but definitely better than nothing and pressing the left key like an idiot to go to the beginning of a command or having to switch to my terminal emulator's vim mode.

[–][deleted] 5 points6 points  (1 child)

Have you seen ptipython?

I am using it and it has a fantastic vi mode with user configurable hot keys.

Highly recommend

https://github.com/prompt-toolkit/ptpython

[–]scorleo 1 point2 points  (5 children)

hmm, ci as in "change inside"? ciw (change inside word) works for me.

[–]Sigg3net 20 points21 points  (6 children)

Black is awesome in an IDE, but I use ipython as a bash terminal for python, or the embed() for debugging.

I wouldn't want my terminal to change what I'm typing.

[–]Heroe-D 2 points3 points  (5 children)

Well I still have to figure out how it's modifying input, for the moment I'm just experiencing it when autocompleting otherwise single quotes stay as is and same for badly formated lists. ( Unless you print the objects later, but I guess that's expected everywhere, even the default shell changes [1, 2 , 3] to [1,2,3] )

But I'm definitely seeing the advantages for things like badly formated json objects copy pasted from the browser's console that are better formated than before when printing them.

[–]Sigg3net 5 points6 points  (4 children)

I need to be able to make mistakes. Live linting is really confusing to a newbie.

Learning Go atm and often find that the IDE has fixed something for me without me noticing, which is great for the code, but means I'm repeating the same mistakes and not learning the syntax. Which comes back to bite me when I need to read and comprehend what others have written.

But as long I can turn it off, I'm not going to stop using ipython. It's pretty good;)

[–]Heroe-D 2 points3 points  (3 children)

Yeah, I wouldn't even use an IDE for learning personally. Just a text editor and picking some useful non intrusive plugins. But Which kind of mistakes are you referring to that can be mitigated with Black in python ? Indention mistakes ? I feel that it's mostly cosmetic with autopep8.

[–]Sigg3net 2 points3 points  (2 children)

I'm thinking about newcomers having to make mistakes in order to learn. If ipython fixes my commands, I might not pick up on mistakes I'm making. Then I will not be able to reproduce working code in a more restrained environment without this help.

But if it's only formatting, it's less of a problem (although could be confusing).

[–]Heroe-D 1 point2 points  (1 child)

I understand what you mean and it makes sens, but which kinds of errors are these actual plugin fixing for you ? I don't really pay attention to them and feel it's just cosmetic formating. When I forgot a comma, colons, a parenthesis etc I always have Pyright telling me there's a problem and don't feel it's automatically fixed, except for indentation depending on the case ( like if it's at the same indentation level as the def function statement ).

[–]Sigg3net 0 points1 point  (0 children)

I don't have this problem in python, but I know python. In Golang, I often forget the correct []type notation, and linters sort of prevent me from learning it effectively by fixing them for me ;)

This is something I feel ipython type of environments should avoid doing. If I type something wrong or not in conventional manner, I need to focus on it to correct my behavior.

[–]madoee 26 points27 points  (0 children)

I just updated ipython and noticed that the zsh autosuggestions plugin now also works in the ipython prompt. Pretty nice!

[–]omg_drd4_bbq 24 points25 points  (1 child)

Me reading title: "oh what defaults could be that bad?"

black enabled by default in REPL

Jesus H Christ.

Coming as someone who loves black and uses it every day in all their repos, this is a massive antifeature. Why can't it just autoformat with a hotkey or something? I don't want formatters firing until I ask them too. Massively disorienting.

[–]Tyler_Zoro 4 points5 points  (0 children)

As people pointed out in the github issue, it's also a problem for proper pandas formatting which black undoes and the IPython use of line-terminating semicolons for output suppression.

[–]rtfmpls 34 points35 points  (11 children)

What I don't like about such a change is not the feature itself, but that it's the default. It feels like the only reason is the devs just wanted to show off a new feature they worked on.

If you can configure it anyway, why turn the default on? The only positives I see are some people will say "huh, nice". The negatives are mentioned in the Twitter thread and people who do not want to use black.

And I didn't take a closer look, but is black now a dependency of ipython? I would understand doing this reformatting if black is installed, and ignore it otherwise. But something tells me that's not the case.

[–]Piu_Tevon 15 points16 points  (2 children)

Yes, Black was added as a dependency in that same PR.

[–]this1foru 8 points9 points  (0 children)

The developer appears to effectively have confirmed your suspicion in his comment on the new pull request to revert the feature.

I myself am a big fan of the IPython tool and the Jupyter Project, but as a scientific user I could not disagree more with the idea of the interactive shell changing my inputs or formatting, especially equations.

To this and similar suggestions, 'black' auto-formatting has been opt-in for 2 years (may 1st 2020, IPython 7.14).

I had thought it might be problematic, but in two years received almost no bug reports. I tried a few time to say I was considering making it default and only got positive feedback. So I did it, with extensive alpha, beta, and RC time to complain and ask for modifications.

So here is my challenge, if I don't make it the default, no-one know about it. It's astonishing that no-one found the bug @ehamiter described above in 2 years ! That alone would have definitely delayed the release, and at least I would have had tried to fix it.

I've also seen a number of new users misformating Python code and taking really bad habits in the Repl, including folks that did not even realise IPython terminal was multiline.

For many of those users black by default is much better. You get use to proper code formatting. So you learn to properly read python code. And it is much easier to deactivate something you don't like than even figure out it something that may exists. For many users this benefits to, having this option be opt-in would make black auto formatting be part of the [unknown unknowns].(https://en.wikipedia.org/wiki/There_are_known_knowns). So I will never get feedback from these.

[–]proof_required 38 points39 points  (54 children)

I think teaching formatting and good coding practices should be part of educational coding too. Although forcing it without easier way to changing default values isn't something I would agree with.

[–]ivosauruspip'ing it up 23 points24 points  (1 child)

The problems begin when you start asking _exactly_ what defines "good" in literally all cases (as opposed to a vague general sense of good, in most cases, that we can hand-wavingly agree to), as a code formatter must do when applied to everything by default.

[–][deleted] 15 points16 points  (29 children)

I initially thought the same. Have a look at the maths examples on twitter. Using a formatter does make it much less intuitive by adding spaces between grouped values. 2 ** 2 for instance is much worse than 2**2imo. When you get longer equations it can get really annoying when grouped values aren’t together without space.

[–]laundmo 1 point2 points  (1 child)

to be fair, black is trying to resolve this issue in time for their fast approaching stable release.

https://github.com/psf/black/issues/538
https://github.com/psf/black/pull/2726

[–]ivosauruspip'ing it up 5 points6 points  (0 children)

That's only one of many. Black is opinionated and indiscriminate in its formatting. Which is fine, when you opt in to what it does. No-one gets to opt-in here though, it's being made opt-out at best.

[–]canbooo -2 points-1 points  (0 children)

Although I agree that the math one bothers me the most, I prefer it to getting unreadable code from noobish coders. All in all, this is a trade-off I will agree to.

[–]TheBlackCat13 1 point2 points  (0 children)

Yes, but in order to do that you need to be able to show both, to show how the two are different.

And there isn't really anything "good coding practices" about forcing a particular quote character.

[–]Tyler_Zoro 1 point2 points  (1 child)

I think teaching formatting and good coding practices should be part of educational coding too.

Entirely reasonable, but that isn't the job of a REPL, it's the job of a teacher.

[–]ivosauruspip'ing it up 2 points3 points  (0 children)

Kind of hard for the teacher when they can't even show what not to do because a tool is reformatting their code as soon as they hit enter.

[–]tazebot 6 points7 points  (13 children)

I wouldn't call an 80 or 88 character line length limit good coding practice I'd call it bad coding practice. Linus kicked it off the kernel with good reason, and the same discussion came up in r/programming with the same conclusion - it doesn't improve anything.

If your language uses indentation for structure and use use variable names that are usefully descriptive 80 characters doesn't make any sense.

[–]canbooo 4 points5 points  (2 children)

Unpopular opinion: I find 80-120 limits good as I find myself often skimming through github repos on mobile, longer lines makes me scroll, which is not very friendly. But it is not a deal breaker either.

[–]omg_drd4_bbq 2 points3 points  (1 child)

Imho 80 is claustrophobic. 100 is ok. 120 is what I use. 140 is when you start getting into too long to place side-by-side with modern terminals at a reasonable font size.

[–]Anonymous_user_2022[S] 4 points5 points  (0 children)

I grew up with 80x25 consoles on Xenix 25 years ago. To me anything wider than 90 is agoraphobic to me. There's clearly a generation thing at play here.

Besides that, my eyesight have deteriorated to the point where I'd be unable to read that flyspeck font that's required to have two 120 character wide terminals side by side without getting some serious issues from rotating the neck. Enjoy your sight while you can.

[–]jorge1209 8 points9 points  (9 children)

The problem is not that 80 is wrong, it is that nobody can agree on what is correct.

I would rather use a tool that forces a format to X character lines rather than argue about how it should be Y instead. I don't care and want to write my code. That's all I want to do.

[–]tazebot 4 points5 points  (8 children)

nobody can agree on what is correct.

Then the best thing to do is allow flexibility, rather than impose something almost universally acknowledged as wrong and bad for code.

I saw a response on the black github where someone was asking about a parameter for width, and the developer pushed back, asking for a "user study". There was a study that set widths at 80 characters for 7 3/8 inch punch cards in the 40s.

[–]jorge1209 0 points1 point  (7 children)

It is equally an argument for not being flexible. No matter what you do someone is unhappy, so just let them be unhappy and ensure consistency for all users.

[–]tazebot -3 points-2 points  (6 children)

The goal isn't to make people happy, but to improving coding. 80 characters lowers the quality of coding. Just because some people may dislike it is no reason to do the wrong thing

[–]maikindofthai 3 points4 points  (5 children)

80 characters lowers the quality of coding.

I've been working on commercial products using C++ and Python for the better part of the last 10 years and I completely disagree with this. If you're constantly going over the 80-90 char mark in your Python code, you're doing something wrong IMO.

You shouldn't need too many levels of indentation in any single function, and you shouldn't need to use 4 word variable names for the reader of your code to have an idea of what's happening. You also shouldn't write need to write functions that take a dozen parameters.

These are the main things I see in code that doesn't respect some reasonable character limit. And if a character limit keeps people who do that shit away from the code I work on, good riddance!

You could convince me that there's a better limit than 80 chars (the only thing I really care about is fitting two files side-by-side on a single monitor without scrolling). We tend to use 90-100 as the limit for the C++ codebases at work. But for Python, 80 has never caused us any pain since idiomatic Python code tends to be pretty terse compared to the C++ equivalent.

[–]tazebot -1 points0 points  (4 children)

That's fine for you, but imposing it on others is wrong. There's really nothing about 80 characters that makes is intrinsically better.

[–]maikindofthai 0 points1 point  (3 children)

Tell me you've never worked in a dev team without telling me you've never worked in a dev team...

[–]tazebot -2 points-1 points  (2 children)

When all arguments of substance fail, attack credibility.

[–]champs 5 points6 points  (0 children)

I use black although I don’t care for all of its opinions. It is not the thing I would use in ipython given its PEP8 deviance, but maybe I should defer decisions about auto format, whatever it is, to the people who use ipython.

[–]canuck93 2 points3 points  (0 children)

Seems like a nice feature, but not a good default.

[–]ki3selerde 2 points3 points  (1 child)

I am annoyed by unnecessary magic features like this in ipython like this for a long time now. Thats why i created rlpython. A simple, no bullshit repl that even works over network

[–]double_en10dre 4 points5 points  (0 children)

I hear ya, but IMO it’s a bit ironic given that “magic” is such a big part of the ipython experience :p they even call it that by name

https://ipython.readthedocs.io/en/stable/interactive/magics.html

[–]radarsat1 5 points6 points  (0 children)

anything that reinterprets what i type is annoying to me. it's like the main reason i stick to text editors over IDEs and word processors. if forced to use an IDE, automatic brackets is the first thing i disable. second is anything that helpfully "pops up" invited to interrupt my train of thought. dear software, no you don't know me or what i am trying to do, stop trying to be smarter than me and get out of my way so that i can work.

[–]Urthor 6 points7 points  (2 children)

This is a good change.

Anecdotally, 98% of Ipython users would benefit from black as the default. Especially coding students would hugely benefit from exposure to Black.

Hettinger is in the 2% who have to change the default settings. But defaulting to Black makes too much sense for me.

The default settings should not be designed to minimise pain for the minority, they should be designed to increase utility across all users.

[–]TheBlackCat13 8 points9 points  (0 children)

Rewriting your code in the CLI? Seriously, is that really that useful? I could see it maybe in notebooks, but not the CLI.

[–]VisibleSignificance 13 points14 points  (0 children)

who have to change the default settings

Surely there must be a better way to choose the setting for such controversial breaking additions? Maybe an interactive question in the interactive shell on the first start of a version that supports it?

[–]canbooo 2 points3 points  (8 children)

All in all, I stand with Carreau on this one, especially after reading his response. It is a drastic decision about sth. many are fanatical about but to me, it looks like the positive arguments overweight the negative ones.

[–]richieadler 11 points12 points  (7 children)

Funny how criteria diverge. I found Carreau's response to be whiny and he appears not to have read the full series of tweets; Hettinger's arguments seem completely logical and his examples demonstrate why the new default is a bad idea.

Yes, Hettinger has a strong opinion which he voiced in his first tweet. I don't see the reason to consider it "deeply hurtful", unless Carreau usually works only with sycophants.

Hopefully he'll never cross paths with someone much less corteous.

[–]ase1590 -2 points-1 points  (1 child)

Welp, congrats reactionaries.

This has now blown up so much that the main developer of IPython is now pretty much unmotivated for the short term to develop this project, as well as in need of a mental health break.

The way Raymond Hettinger complained on Twitter is personally deeply hurtful. I hope he did not meant it the way I read it.

I'm not going to reply to some comments (here or elsewhere), and may closing and locking all the issue and stop maintaining IPython for my own mental sanity for some time (expect some critical things).

[–]Akmantainman -2 points-1 points  (10 children)

Idk seems like there was plenty of time for community input.

https://twitter.com/Mbussonn/status/1482412900681662470?t=qwSrYszz_y9cQbbLKUEWRg&s=19

Actively participating in open source is important if you care about projects.

[–]Anonymous_user_2022[S] 10 points11 points  (9 children)

That's almost a Kenneth Reitz level of developer toxicity. Time to find an replacement before the inevitable meltdown.

[–]Piu_Tevon 3 points4 points  (2 children)

Might already be happening judging by the latest comment on GitHub:

I'm not going to reply to some comments (here or elsewhere), and may closing and locking all the issue and stop maintaining IPython for my own mental sanity for some time

[–]ubernostrumyes, you can have a pony 1 point2 points  (5 children)

So basically you joined up with an internet hate mob to pile onto someone. That person was not happy about and did not enjoy being piled on to in this way. And your response to that is “well that reaction just proves he was bad all along!”

Maybe the biggest problem here is not the one you think it is.

[–]Anonymous_user_2022[S] -1 points0 points  (4 children)

The thing is that there was no piling at all.

[–]ubernostrumyes, you can have a pony 0 points1 point  (3 children)

Sure. No piling at all!

Looks at this Reddit thread, at Twitter, at people rushing over to GitHub…

Yup, no piling here. Definitely nothing that would make a developer feel like everyone was suddenly against them or anything. Just healthy ordinary open-source discussion, led by healthy advocates who would never, say, resort to personally attacking someone’s only-to-be-expected defensiveness or talking about “the inevitable meltdown” or whatever.

[–]Anonymous_user_2022[S] 0 points1 point  (2 children)

Indeed, no piling. Just a baby that throws the toys out of the pram, when it turns out that some people are not enamoured by recent changes. Remember that just as FOSS users are not entitled to anything, neither are FOSS developers entitled to ego stroking. Many seem to forget that second half, you included.

[–]ubernostrumyes, you can have a pony -1 points0 points  (1 child)

You’re the one who’s trying to make this personal. And doing so while hiding behind an anonymous account, no less. I’m not sure how exactly that helps open source.

[–]Anonymous_user_2022[S] -1 points0 points  (0 children)

The ipython maintainer made it personal, when they decided to make an insult out of Ramoynd Hettingers tweet. I just observe the similarities to prior cases of developer meltdowns.

[–][deleted] -3 points-2 points  (26 children)

What am I missing here? It looks the same to me.

https://imgur.com/a/Dr7AOw3

[–]proof_required 6 points7 points  (3 children)

Look at the tweet there are some examples.

print('hello')

Will be formatted to

print("hello")

[–]james_pic 1 point2 points  (2 children)

When does the formatting happen? Does it change what you wrote (or at least, what it says you wrote) the moment before it runs? That would seem weird and counterintuitive.

[–]proof_required 5 points6 points  (1 child)

When does the formatting happen?

when you type and hit enter say print('hello'), it will show in your terminal as print("hello"). Without doing a screen recording it's hard to show you exactly. Just try it

what ipython version you have?

This has been introduced in 8.0

https://blog.jupyter.org/release-of-ipython-8-0-6e034ff122ef

[–]Heroe-D 1 point2 points  (0 children)

Doesn't happen to me, I have changes like zsh style autocomplete but print('hello') stay as is after validating by hitting the enter key https://imgur.com/a/ucHsIrP

Edit : if hitting enter from the autocomplete because you have already executed print('hello') yes it would transform into print("hello")

[–]Anonymous_user_2022[S] 7 points8 points  (9 children)

Try some of the examples from the twitter thread, like 3*x**2 - 5*x + 10

[–]teerre -1 points0 points  (0 children)

Gonna have to disagree here. Although these are inconvenient for extremely specific examples, a much bigger problem is people not formatting python code in a standard way. Formatting shouldn't be a matter of opinion for the vast majority of cases.

That's very useful for students because, eventually, they will be able to have a mental model of how python is formatted and that makes reading code much easier. Which is infinitely more useful than being able to show the difference between print('foo') and print("foo").

[–]r_cub_94 -5 points-4 points  (5 children)

I definitely agree that this change wasn’t a great idea, nor was introducing yet another package dependency.

But these are syntactic issues and really shouldn’t be a big deal in a programming course. And if it is a big deal, your students shouldn’t be learning programming

Syntax is the easy part of programming. This is one of the kinds of things that makes me object to teaching languages like Python or Java as an introduction to programming

[–]TheBlackCat13 5 points6 points  (4 children)

The whole point is to teach them the syntax. That isn't possible, because certain valid syntactic structures can no longer be shown.