Show HN: PyScribe – A Python library to make print debugging more efficient
1–10 of 19 posts
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#2Small suggestion: make the output format configurable or at least choose simpler defaults. I think the lib itself is pretty nice and usable, but the produced logs aren't.
The log as output now contains a lot of 'human readble' text and almost full sentences, but in my experience when you are skimming a logfile manually, which for me happens a lot, it really slows you down because you constantly have to skip over the useless parts to get to the core which in this case would be values of variables.
For example:
- From line 9: x is the int 5: From is imo completely unnecessary. line could be left out as well for me, a number followed by a colon is standard enough and if you know it is a line, adding that word adds nothing to the usefulness of the log and makes for longer lines. Arguably one would rather call it an int and not the int but I'm not a native English speaker so not sure about that. It does sound weird to me though. Furthermore while I'm at it I'd leave it out all together. I would prefer something terse as 9: x int 5
- bar is the str foo at beginning of for loop at line 12 it really took a careful reading to grasp what it says. I don't immediately know what I'd pick instead, something like 12: begin for: bar str foo. Also maybe you should stick to standard Python printing as on the repl and use 'foo' in quotes so it's immediately obvious it's a string (you seem to be doing that while printing dicts?)
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#3I think it is unfortunate this does not support python 3. I think we have already passed a tipping point in the migration from python 2. Just look at the python 3 readiness[0]. I believe it might already be more interesting for beginners to learn python 3 over python 2 now.
All new packages should think about supporting python3, or at least be ready to support it with a lot of __future__ imports.
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#4Small suggestion: make the output format configurable or at least choose simpler defaults. I think the lib itself is pretty nice and usable, but the produced logs aren't. The log as output now contains a lot of 'human readble' text and almost full sentences, but in my experience when you are skimming a logfile manually, which for me happens a lot, it really slows you down because you constantly have to skip over the…
Excellent suggestions, will be adding format configurations next!
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#5I think it is unfortunate this does not support python 3. I think we have already passed a tipping point in the migration from python 2. Just look at the python 3 readiness[0]. I believe it might already be more interesting for beginners to learn python 3 over python 2 now. All new packages should think about supporting python3, or at least be ready to support it with a lot of __future__ imports. [0]: http://py3readi…
I'm not exactly sure if it doesn't work on Python3, I had only tested it on 2.7 so it mightt (there aren't any external dependencies). I'll probably test it on Python3 and safely include that in the supported versions soon.
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#6Small suggestion: make the output format configurable or at least choose simpler defaults. I think the lib itself is pretty nice and usable, but the produced logs aren't. The log as output now contains a lot of 'human readble' text and almost full sentences, but in my experience when you are skimming a logfile manually, which for me happens a lot, it really slows you down because you constantly have to skip over the…
Excellent suggestions, will be adding format configurations next!
That being said, be careful to not make it too difficult to use.
Configurable is good, as long as there are sensible defaults that just work.
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#7would like to share this which I found on twitter recently:
The Law of printf debugging: debugging messages inserted to track down unwanted behavior asymptotically approach "o_O"
-- @a_cowley
So thanks alixander for a considerable step in the right direction.
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#8Earlier quoted context omitted.
Excellent suggestions, will be adding format configurations next!
That being said, be careful to not make it too difficult to use. Configurable is good, as long as there are sensible defaults that just work.
IMO good-defaults will emit text people could reliably parse/interpret/transform with other tools.
This helps keep the project simple and focused, since users with specialized needs don't need to ask you for specialized features.
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#9I think it is unfortunate this does not support python 3. I think we have already passed a tipping point in the migration from python 2. Just look at the python 3 readiness[0]. I believe it might already be more interesting for beginners to learn python 3 over python 2 now. All new packages should think about supporting python3, or at least be ready to support it with a lot of __future__ imports. [0]: http://py3readi…
I'm not exactly sure if it doesn't work on Python3, I had only tested it on 2.7 so it mightt (there aren't any external dependencies). I'll probably test it on Python3 and safely include that in the supported versions soon.
It wasn't too bad, looks like you had a couple of calls to xrange() (now just range()) and were using the result of a filter as a list. I've submitted a PR to add 3.4 support to it, and to add it to Travis.
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#10I noticed a couple of minor issues and thought I'd post them here rather than making issues on github since the author is reading.
First, desugaring doesn't treat the shebang line of a file properly for executable python scripts on Linux. If the first line is, for example, '#!/usr/bin/env python', then the desugared file has three imports at the top of the file and the shebang line after those imports. It would be nice to preserve the shebang line as the first line (and maybe also to make the desugared file executable if the input file was executable).
Second, the desugaring doesn't ignore commented out lines, as I discovered on commenting out a line like
#ps.p("my test: " + foo)