3 ms·

FWIW, re-replaying the stack trace to figure out what was imported and re-implementing it is a horrible idea. There are much better ways to do this type of imp

FWIW, re-replaying the stack trace to figure out what was imported and re-implementing it is a horrible idea. There are much better ways to do this type of import voodoo, specifically the import hooks that Python ships with. Here's an example of their use inside a small side project of mine: https://github.com/tswicegood/maxixe/blob/master/maxixe/__init__.py https://github.com/tswicegood/maxixe/blob/master/maxixe/__in... All that said, this is horribly un-Pythonic. A much better route to so is something like envoy[1] which simply wraps `subprocess` in a sane API. [1]: https://github.com/kennethreitz/envoy https://github.com/kennethreitz/envoy

tswicegood 15y ago
Just to clarify. I applaud this type of development for people trying to learn various parts of Python like playing with the stack, but the idea of this being used in the wild scares me a bit.
- steve-howard 15y ago
  It's like operator overloading for novel syntax in C++. It worked all right for iostream, but if you've ever seen boost::spirit you can see that even very smart people can make very weird things happen by trying to kludge features into new syntax.
jamesaguilar 15y ago
envoy looks a lot more verbose than this though . . . if you're really trying to replace shell scripting, having envoy.run(foo) on every line is going to get annoying. Also, it's not clear on what basis you make this assertion: > FWIW, re-replaying the stack trace to figure out what was imported and re-implementing it is a horrible idea. Does it not work?
- tswicegood 15y ago
  "Does it… work?" is not the standard by which good Python code is measured. Django went through this process years ago. It's convenient to be able to call `from myapp.models import *` and have an `Articles` model magically added to your module even though you never defined. They realized years ago that writing clever code for the sake of being clever was a bad idea. How are you going to get someone else to be able to maintain it? Not only do they have to know the logic of what you're doing, they have to know how you hacked things together. Line 17 of PEP-20 sums up my thoughts on this code as more than an intellectual exercise. > If the implementation is hard to explain, it's a bad idea. Regarding using Python as a replacement for shell scripting: if you have to rewire the language to do what you want, why are you using a different tool for the job?
  - jamesaguilar 15y ago
    > If the implementation is hard to explain, it's a bad idea. I don't think this principle is universal in software, and I don't think you need to embrace it as a prerequisite for writing or distributing Python code. My personal preference would be for a statement more like this, "If the implementation is more complicated than it needs to be to do what you want, it's probably a bad idea." > Regarding using Python as a replacement for shell scripting: if you have to rewire the language to do what you want, why are you using a different tool for the job? Well that's easy to answer. It's cleaner and more readable than bash, has some nice features that shell scripts lack, can be used to call into python libraries, allows a single unified codebase if you're already writing python code . . . I could go on.

tswicegood 15y ago

Just to clarify. I applaud this type of development for people trying to learn various parts of Python like playing with the stack, but the idea of this being used in the wild scares me a bit.

steve-howard 15y ago
It's like operator overloading for novel syntax in C++. It worked all right for iostream, but if you've ever seen boost::spirit you can see that even very smart people can make very weird things happen by trying to kludge features into new syntax.

jamesaguilar 15y ago

envoy looks a lot more verbose than this though . . . if you're really trying to replace shell scripting, having envoy.run(foo) on every line is going to get annoying. Also, it's not clear on what basis you make this assertion: > FWIW, re-replaying the stack trace to figure out what was imported and re-implementing it is a horrible idea. Does it not work?

tswicegood 15y ago
"Does it… work?" is not the standard by which good Python code is measured. Django went through this process years ago. It's convenient to be able to call `from myapp.models import *` and have an `Articles` model magically added to your module even though you never defined. They realized years ago that writing clever code for the sake of being clever was a bad idea. How are you going to get someone else to be able to maintain it? Not only do they have to know the logic of what you're doing, they have to know how you hacked things together. Line 17 of PEP-20 sums up my thoughts on this code as more than an intellectual exercise. > If the implementation is hard to explain, it's a bad idea. Regarding using Python as a replacement for shell scripting: if you have to rewire the language to do what you want, why are you using a different tool for the job?
- jamesaguilar 15y ago
  > If the implementation is hard to explain, it's a bad idea. I don't think this principle is universal in software, and I don't think you need to embrace it as a prerequisite for writing or distributing Python code. My personal preference would be for a statement more like this, "If the implementation is more complicated than it needs to be to do what you want, it's probably a bad idea." > Regarding using Python as a replacement for shell scripting: if you have to rewire the language to do what you want, why are you using a different tool for the job? Well that's easy to answer. It's cleaner and more readable than bash, has some nice features that shell scripts lack, can be used to call into python libraries, allows a single unified codebase if you're already writing python code . . . I could go on.