Dead Comment
I can also disable all print statements with "def print(* args, * * kwargs): pass" at the top of the module.
I've had times where I couldn't figure out where a print was coming from, so I could replace print() to check the arguments passed in:
import builtins
builtin_print = builtins.print
def my_print(*args, **kwargs):
if "looking for" in args: # adjust as appropriate
1/0
return builtin_print(*args, **kwargs)
builtins.print = my_print
Previously I had to do that by wrapping sys.stdout with my own file-like object, to intercept write(). (Granted, not hard, but harder.)1) it modified the file object's "softspace"
>>> class MyFile(object):
... softspace = "Hello"
... def write(self, s):
... pass
...
>>> f = MyFile()
>>> f.softspace
'Hello'
>>> print >>f, "spam"
>>> f.softspace
0
2) This wasn't a problem until >> was added, because of problem #2 - the print statement didn't originally let you print to anything other than stdout. Which meant that if you wanted to support writing to a file instead of a stdout then you had to re-implement print yourself.In practice, I've also found that having print as a function adds functionality because I can do things like:
print(*data_values, sep="\n")
which is a quick way to print each value in a list on its own line. for v in data_values: print v
Is exactly the same length but much more readable. print "Hey, they brought back the print statement!"
print("But you can still call the print() function!")
print ("printing", "tuples", "works", "like", "python2")
It would be a massive QoL improvement and also accelerate Python 3 adoption.(I'd actually be OK with allowing keywords to be used as method/function names in general, but that's a more extensive change than
from __past__ import print_statement
)What is your workflow? I find the following to be true, in that one of 3 things happens inevitably:
1. The Text Editor becomes the IDE, (e.g., with VSCode, if you just live in plain HTML, CSS/SCSS/LESS and JSX/TSX/JS/TS all day, its actually pretty great, lots of well maintained extensions and Microsoft really put their energy into capturing into this market with VS Code I think. If you have more than ~10 extensions installed, I'd argue you got an IDE (not including themes or colorizers))
2. They have extensively curated vim or emacs setups that were built over time to add IDE-like features, in some cases I'd argue they become IDEs themselves via deep customization
3. They move to an IDE
So my question is if none of the 3 are true, whats your workflow like?
For context of my own workflow, it slowly over time is all around my IDE (JetBrains user, hardcore. You'll pry it from my cold dead hands). With the exception of running scripts (sometimes, like builds) and using git (git CLI is the best git interface IMO) I have moved it 100% into my IDE, and I'm so much faster at things, including picking up new languages
When I started, I used VS Code heavily professionally, and vim before that, and relied on the CLI for anything outside of editing the code (basically, I think I had some auto formatting setup too), but I hit a wall at some point where I never turned back and went full into JetBrains to this day
Now for Common Lisp I use SLIME, which I guess does count as IDE, seeing as it's much more powerful than most IDEs.
Now when I wanted to take an JLPT exam, I realized that my listening skills are awful, and my grammar skills aren't very good either. I started watching grammar lessons on Youtube in Japanese, as well as random videos in Japanese (mostly about trains/traveling). In the end I just barely passed listening (JLPT N2) but my grammar skills were really good.
[1] https://twitter.com/GossiTheDog/status/1565629001862873088