Earlier quoted context omitted.
I believe the walrus operator `:=` was introduced in Python 3.8. So keep that it in mind.
As was this feature.
Indeed but the operator is useful beyond fprint
Icecream: Never use print() to debug again in Python
261–270 of 271 posts
Re: Icecream: Never use print() to debug again in Python
#262wait isnt that just enforcing bad practice? doesnt python have proper debuggers with breakpoints ect? why in hell should i use a lib to print stuff just for debugging? i mean why not having a proper logging lib and pipe some statements to [debug] or whatever i dont get it.
Requirements for logging and debugging are quite different. For logging I probably don't want to print the source expression, I probably want to include a semantic description. For logging it is also intended to live in the code for longer, so I probably want something a touch more readable. The debugging and logging spaces overlap but there are definitely differences if you really start optimizing for debugging expe…
You are right with some points but i still see it a bit different. I disagree with the statement "I don't think encouraging bad practices is a problem if the code will be deleted before being submitted.". The thing is the deadline just needs to be shifted a bit and suddenly you have to commit code in a hurry. There will always be the chance that you forget delete something. A great example is this one: https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice... low level code with debugging printfs nearly made it into the freebsd kernel.
I mean everyone prints something for debugging purpouse from time to time, thats fine. but having a lib extra for that. i dont think thats a good idea. Logging frameworks also enable toggling if source expression is printed or not. So you can only show it if you give a --debug flag to your tool for example.
Re: Icecream: Never use print() to debug again in Python
#263Earlier quoted context omitted.
I had this exact thought, but the title gives the wrong impression (at least to me). The package just defines a fancy print.
Sure, but typing ic(someVariable) is a lot faster for me than typing print(f"{someVariable=}") in Python3.8 or >, and still faster than typing print(f"someVariable={someVariable}") in Python It's especially faster when I think about how often I fat-finger the '{' (and '}', when my editor doesn't insert the matching brace automagically). Of course YMMV.
I (and the person I replied to, I suspect) interpreted the title to mean that you shouldn't debug by printing stuff to the console at all, but instead do some other thing.
Re: Icecream: Never use print() to debug again in Python
#264Earlier quoted context omitted.
Why would the amount of characters possibly matter?
I find it important because it lowers the barrier of entry to print debugging. I have found myself using less prints in Java than in Python both because of static typing and having to write the full `System.out.println`. This is also important to me because I am very cautious of not doing a file-level import (I don't want to commit a file with the dependency). The fewer characters it takes, the easier it is for me to…
That's why you should write `log.info("message")` ;)
Besides, just use a proper debugger instead.
Re: Icecream: Never use print() to debug again in Python
#265Earlier quoted context omitted.
I find it important because it lowers the barrier of entry to print debugging. I have found myself using less prints in Java than in Python both because of static typing and having to write the full `System.out.println`. This is also important to me because I am very cautious of not doing a file-level import (I don't want to commit a file with the dependency). The fewer characters it takes, the easier it is for me to…
Do you use typing in Python?
I don't. I've tried it, it just doesn't "click in" for me. I love types and (i.e. I love Rust's type system), but not on Python.
Re: Icecream: Never use print() to debug again in Python
#266I was wondering if there was any equivalent library for Ruby. Turns out there is: https://github.com/AndyObtiva/puts_debuggerer. With that library,
pd bug_or_band
[PD] /Users/User/trivia_app.rb:4
> pd bug_or_band
=> "beattle"Re: Icecream: Never use print() to debug again in Python
#267You can do the same thing with Python 3.8+ by using f-strings and just appending "=" to the variable name: >>> print(f"{d['key'][1]=}") d['key'][1]='one'
Thank you for sharing this.
Re: Icecream: Never use print() to debug again in Python
#268You can do the same thing with Python 3.8+ by using f-strings and just appending "=" to the variable name: >>> print(f"{d['key'][1]=}") d['key'][1]='one'
Nice feature. Is there a way to globally enable/disable it? E.g., python3 myscript.py --enableFstringDebugging=true So that I could get rid of lots of conditional statements, e.g.: if debug: print (f"some useful debugging info")
No. You should use logging syntax[0] instead.
Re: Icecream: Never use print() to debug again in Python
#269> prints both its own arguments and the values of those arguments. That's not enough. Almost always I also want the argument type . Occasionally a unique (i.e. as precise as possible) sortable (i.e. with leading zeros) time stamp also comes useful.
This would be great to have. I don't use types in my Python much. Yet at least. Can you submit a PR to add this? That'd be awesome.
[deleted]
Re: Icecream: Never use print() to debug again in Python
#270If you like this, you might also like my small debugging utility, a better_exchook replacement: https://github.com/albertz/py_better_exchook Simple example: assert x == 4 When this fails, it will print the value of `x`.
Just a point of curiosity about reassigning `sys.excepthook`. Is there a reason you simply reassign it and lose information about the old excepthook: sys.excepthook = better_exchook instead of something like: def generate_better_exchook(..., current_excepthook=None): previous_excepthook = current_excepthook def better_exchook(exception_type, exception_instance, exception_traceback): ... if previous_excepthook is not…
Hey, sorry, just saw this question right now.
Actually, I don't know. I assume this is not standard, because many excepthook handlers would probably print some variant of the stack trace on stdout or stderr, and then you would end up having printed the stack trace multiple times. Or maybe it depends. If your excepthook instead prints it somewhere else (e.g. some log file), it makes sense to also call the default handler afterwards.
But no, this is not about the closure.