5 ms·

Monkeypatching anywhere except unittests is a nono for me. It adds some black magic you need to know before reading the code. Am I reading the standard pathlib

by linkdd 6y ago

Monkeypatching anywhere except unittests is a nono for me. It adds some black magic you need to know before reading the code. Am I reading the standard pathlib.Path or the monkeypatched one ? If I have a bug with it, it comes from the standard library or the patch introduced silently ? Remember the zen of Python: > Explicit is better than implicit And I would personally prefer a unification library ( https://github.com/mrocklin/unification/ https://github.com/mrocklin/unification/ ) over the type dispatch proposed here. It's just more powerful and closer to pattern matching if that's really what you want.

BiteCode_dev 6y ago
Same. But I think what they did with partial should be in the stdlib. In fact partial should also be rewritten in C et promoted to built in. Right now it's 10 times slower than lambda, and you have to know about and wish to import functools, yet still loose the docstring. Shame for such a great feature.
- wrmsr 6y ago
  As far as I can tell functools.partial has been implemented in C since it was added sixteen years ago ( https://github.com/python/cpython/commit/9c323f8de4910dfc0baa5e55aa84eb1b02bcbb72#diff-5bf0cd222f939befcac59055e14cb683R19 https://github.com/python/cpython/commit/9c323f8de4910dfc0ba... ), and it's faster than lambda ( https://gist.github.com/wrmsr/1e13eda3ed78288679c010acbe6d2b44 https://gist.github.com/wrmsr/1e13eda3ed78288679c010acbe6d2b... ). Regarding docstrings you can access the underlying function via the __wrapped__ attribute, and signature forwarding is too brittle and magical for stdlib.
  - deleted 6y ago
    [deleted]
  - BiteCode_dev 6y ago
    > As far as I can tell functools.partial has been implemented in C since it was added sixteen years ago ( https://github.com/python/cpython/commit/9c323f8de4910dfc0ba.. https://github.com/python/cpython/commit/9c323f8de4910dfc0ba.... ), and it's faster than lambda ( https://gist.github.com/wrmsr/1e13eda3ed78288679c010acbe6d2b.. https://gist.github.com/wrmsr/1e13eda3ed78288679c010acbe6d2b.... ) I tried to prove you wrong and run multiple tests that all shown you were right. Then I tried to run them on different python versions, down to Python 2.7, expecting that my knowledge was just dated. No, I was just wrong. Don't know why I was so convinced of this. > Regarding docstrings you can access the underlying function via the __wrapped__ attribute, This assumes one knows about that. A lot of people never even heard of partial(), and won't know about _ _wrapped_ _. Not to mention I never seen a tool using help() fetching _ _wrapped_ _._ _doc_ _ if it exists. > and signature forwarding is too brittle and magical for stdlib. @functools.wraps() does signature forwarding to great success, and is in the stdlib. Nevertheless, I don't think it would be the right strategy for partial(), because you don't have the exact same signature. But at least having something like: This function is the result of x() being wrapped with partial(x, 1, foo='bar'). Here is the original docstring of x(): ....
Alex3917 6y ago
> Monkeypatching anywhere except unittests is a nono for me. What do you think about adding pprint to builtins so that you don't need to import it each time when debugging? (Or, alternatively, so that you don't need to add it to the top of every single file?) It seems kind of wrong, but the alternatives are bad also. I'm not sure why Python didn't do this themselves when they added breakpoint in 3.7.
- orf 6y ago
  pprint is a standard library module which isn’t necessarily available everywhere. You can run python without the standard library, but the moment you add it to the default builtins it needs to become part of the language.
- lacker 6y ago
  Monkeypatching in one application is maybe okay. You really want pprint in builtins, fine, who is it really hurting? Monkeypatching in a library like fastcore that many other people use is really bad. All sorts of bugs and incompatibilities will happen down the road, as software becomes dependent on your monkeypatch without anyone realizing it.
- xapata 6y ago
  Can you configure your debugger to include it? I'd rather do that than modify production code to include a debugging tool.
- kristjansson 6y ago
  Pdb already has pretty print built in? $ python -m pdb ... (Pdb) help pp pp expression Pretty-print the value of the expression. (Pdb) pp ...
- linkdd 6y ago
  The debug code you add doesn't get removed before going into production?
- nuclear_eclipse 6y ago
  If you want it in your debugger (or ipython, etc), add an import to your `.pythonrc` or equivalent. Then it's ready and waiting for you without influencing your production environment or other engineer's testing environments. If you want to use it in all your modules, create a template/snippet so that it's imported at the top ofevery new file you create. Then it's obvious to every new engineer you hire as to what's going on, rather than having non-standard behavior everywhere without any obvious indications.

by linkdd 6y ago

BiteCode_dev 6y ago

Same. But I think what they did with partial should be in the stdlib. In fact partial should also be rewritten in C et promoted to built in. Right now it's 10 times slower than lambda, and you have to know about and wish to import functools, yet still loose the docstring. Shame for such a great feature.

wrmsr 6y ago
As far as I can tell functools.partial has been implemented in C since it was added sixteen years ago ( https://github.com/python/cpython/commit/9c323f8de4910dfc0baa5e55aa84eb1b02bcbb72#diff-5bf0cd222f939befcac59055e14cb683R19 https://github.com/python/cpython/commit/9c323f8de4910dfc0ba... ), and it's faster than lambda ( https://gist.github.com/wrmsr/1e13eda3ed78288679c010acbe6d2b44 https://gist.github.com/wrmsr/1e13eda3ed78288679c010acbe6d2b... ). Regarding docstrings you can access the underlying function via the __wrapped__ attribute, and signature forwarding is too brittle and magical for stdlib.
- deleted 6y ago
  [deleted]
- BiteCode_dev 6y ago
  > As far as I can tell functools.partial has been implemented in C since it was added sixteen years ago ( https://github.com/python/cpython/commit/9c323f8de4910dfc0ba.. https://github.com/python/cpython/commit/9c323f8de4910dfc0ba.... ), and it's faster than lambda ( https://gist.github.com/wrmsr/1e13eda3ed78288679c010acbe6d2b.. https://gist.github.com/wrmsr/1e13eda3ed78288679c010acbe6d2b.... ) I tried to prove you wrong and run multiple tests that all shown you were right. Then I tried to run them on different python versions, down to Python 2.7, expecting that my knowledge was just dated. No, I was just wrong. Don't know why I was so convinced of this. > Regarding docstrings you can access the underlying function via the __wrapped__ attribute, This assumes one knows about that. A lot of people never even heard of partial(), and won't know about _ _wrapped_ _. Not to mention I never seen a tool using help() fetching _ _wrapped_ _._ _doc_ _ if it exists. > and signature forwarding is too brittle and magical for stdlib. @functools.wraps() does signature forwarding to great success, and is in the stdlib. Nevertheless, I don't think it would be the right strategy for partial(), because you don't have the exact same signature. But at least having something like: This function is the result of x() being wrapped with partial(x, 1, foo='bar'). Here is the original docstring of x(): ....

Alex3917 6y ago

> Monkeypatching anywhere except unittests is a nono for me. What do you think about adding pprint to builtins so that you don't need to import it each time when debugging? (Or, alternatively, so that you don't need to add it to the top of every single file?) It seems kind of wrong, but the alternatives are bad also. I'm not sure why Python didn't do this themselves when they added breakpoint in 3.7.

orf 6y ago
pprint is a standard library module which isn’t necessarily available everywhere. You can run python without the standard library, but the moment you add it to the default builtins it needs to become part of the language.
lacker 6y ago
Monkeypatching in one application is maybe okay. You really want pprint in builtins, fine, who is it really hurting? Monkeypatching in a library like fastcore that many other people use is really bad. All sorts of bugs and incompatibilities will happen down the road, as software becomes dependent on your monkeypatch without anyone realizing it.
xapata 6y ago
Can you configure your debugger to include it? I'd rather do that than modify production code to include a debugging tool.
kristjansson 6y ago
Pdb already has pretty print built in? $ python -m pdb ... (Pdb) help pp pp expression Pretty-print the value of the expression. (Pdb) pp ...
linkdd 6y ago
The debug code you add doesn't get removed before going into production?
nuclear_eclipse 6y ago
If you want it in your debugger (or ipython, etc), add an import to your `.pythonrc` or equivalent. Then it's ready and waiting for you without influencing your production environment or other engineer's testing environments. If you want to use it in all your modules, create a template/snippet so that it's imported at the top ofevery new file you create. Then it's obvious to every new engineer you hire as to what's going on, rather than having non-standard behavior everywhere without any obvious indications.