Earlier quoted context omitted.
The correct behavior from `repr()` isn't to do anything, including reading from stdin. That would break documentation generators, along with anything else that expects to be able to call `repr()` without side effects.
Nobody said anything about repr()? It's the REPL's job to handle this case and provide a good UX.
You can't do that because I hate you
191–200 of 216 posts
Re: You can't do that because I hate you
#192Re: You can't do that because I hate you
#193Such a weird rant. Yes, some tools do some things, but not others. Making tools do everything for everyone just bloats them to unmaintainable messes. And it’s a special kind of entitlement to believe that the way _I_ imagine things must be working is the only possible correct interpretation. Reality is messy, there are trade-offs, and a lot of smart people think very hard about what the correct trade-offs should be g…
Writing code should be part of the OS as fundamentally as web browsing. You should get a cursor to write code, have a tree worth of files and have a button to publish the application as a single clickable program. Anything else is a tribute to the rant.
Re: You can't do that because I hate you
#194Such a weird rant. Yes, some tools do some things, but not others. Making tools do everything for everyone just bloats them to unmaintainable messes. And it’s a special kind of entitlement to believe that the way _I_ imagine things must be working is the only possible correct interpretation. Reality is messy, there are trade-offs, and a lot of smart people think very hard about what the correct trade-offs should be g…
Re: You can't do that because I hate you
#195Earlier quoted context omitted.
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…
exit.__class__.__repr__ = lambda _: exit()
quit = exit
Edit, you also need this in your bashrc: export PYTHONSTARTUP=~/.pythonrcRe: You can't do that because I hate you
#196Such a weird rant. Yes, some tools do some things, but not others. Making tools do everything for everyone just bloats them to unmaintainable messes. And it’s a special kind of entitlement to believe that the way _I_ imagine things must be working is the only possible correct interpretation. Reality is messy, there are trade-offs, and a lot of smart people think very hard about what the correct trade-offs should be g…
I agree with the rant, but not the examples. It pisses me off when programmers add "features" which forces users to deal with them. For example, pipenv always prints a message when you activate an environment (I don't know if it's still the case because I don't use it anymore). I had to migrate a cronjob which ran a Python script and sent an error email if anything got printed to stderr. This is a pretty standard Uni…
This is a pet peeve of mine. I see it every so often and every time, I wonder if the dev wasn't familiar with the norms of the platform or if the dev was being malicious.
Either way, it doesn't speak well for them.
Re: You can't do that because I hate you
#197The unstable warning preventing you from wrapping the comments actually seems pretty reasonable to me. It is implemented, but there are probably edge cases where the proper way to wrap and retain the best possible formatting is still disputed. Since a lot of people format on save, via commit hooks or during CI, having this feature enabled as stable and _changing the behavior later_ would cause massive annoying diffs…
Gating it behind nightly is just bizarre though. Today's nightly, where the feature is available, will turn into 1.76 or whatever, but then the feature will become unavailable again. That is not how normal software works.
Re: You can't do that because I hate you
#198Earlier quoted context omitted.
> No, there is no such absolute requirement that "newly added" functions cannot be stabilized. I never said so.
You did, and it was already covered in https://news.ycombinator.com/item?id=38801686 so I'm not going to repeat it.
Re: You can't do that because I hate you
#199Earlier quoted context omitted.
The post itself isn't very generous; its title is “You can’t do that because I hate you.” You're right that "frustrating to use software" applies to proprietary software as well, but the author only gives very specific examples all of which involve open source.
> The post itself isn't very generous; its title is “You can’t do that because I hate you.” Well, sure, the post is a good old-fashioned rant to vent his frustrations. The title is part of that. A well-written one, but nothing more than a rant.
Rants are fine, and I've been frustrated by software too many times to count.
I'm being a bit protective because I would feel hurt if someone wrote that "I hate them" about some of the software I've worked on for free and open sourced.
Re: You can't do that because I hate you
#200Such a weird rant. Yes, some tools do some things, but not others. Making tools do everything for everyone just bloats them to unmaintainable messes. And it’s a special kind of entitlement to believe that the way _I_ imagine things must be working is the only possible correct interpretation. Reality is messy, there are trade-offs, and a lot of smart people think very hard about what the correct trade-offs should be g…
Not having a feature is fine. Kind of having a feature but hiding it behind obnoxious gatekeeping is not fine. Features that are buggy or inexplicably complex is not fine. Some open source projects get this right, and others don't. Some projects don't care about wasting the user's time. Or they berate the user for wanting to do something in the 'wrong' way. Or they break things that worked just fine in the pursuit of…
really depends on so many factors that this isn't a good general sentiment. Sure, if this is a professional grade tool targeting corporate, it better be polished or have excellent support for when stuff breaks. If it's some small scrappy tool handling a complex task with all kinds of edge cases I can give some leeway to the UX and even some very esoteric use cases.
vector graphics comes immediately to mind. I won't be too griped if Krita as a FOSS has some subtle bugs. I can at the very lest throw out an issue to at least bring awareness. I'd be much more miffed if Illustrator had some issue given how closed up and hard to contact Adobe is if you're not a million dollar business (not to mention Adobe's general philosophy of how they approach software these days).
Attitude is a factor, but I do take into account the problem space when evaluating feature completeness.