3 ms·

>>> from guietta import _, Gui, Quit I am not looking forward to taking over projects using that framework abusing underscore and double underscore magic varia

>>> from guietta import _, Gui, Quit I am not looking forward to taking over projects using that framework abusing underscore and double underscore magic variables. The underscore "_" is a pseudo reserved variable in python. It is used in assignments like year,month,_ = readdate() to discard the return value and disable the lint warning about it.

codethief 6y ago
Couldn't you simply do something like >>> from guietta import _ as underscore to fix this?
- user5994461 6y ago
  After spending inordinate amounts of time debugging obscure side effect caused by "import as" and "from import". I'd reject that "from import as" on sight in code review.
  - detaro 6y ago
    Any hints towards what kind of issues those cause? I could see some around relative imports, or something else?
    - user5994461 6y ago
      Let's say you write a module httpclient doing this: from ssl import sslsocket import httplib as hlib You can think of the code above as remapping and/or duplicating the whole library it's importing. Python imports involve complex local and global states (I don't pretend to understand most of it). One direct effect on usage is that users of the library can call "httpclient.sslsocket" and "httpclient.hlib" as if they were provided by the library (the author certainly didn't mean to). This creates problem down the line when the author try to change the internal dependency, and this extends to other code also doing "import httpclient.sslsocket as sslsocket", creating problematic hidden dependencies. More generally, this affects all import dependent features, like reload(module), mock, sys content, etc... imports are looked up and tracked by full path which doesn't always work as expected when paths are hot patched as above. I used to work in a python shop (millions of line in total across the organization). Regularly had the problem with interns and new graduates abusing imports as above (sometimes even trying to change the existing imports because they though this was the better syntax). Then they couldn't pass their own tests (every new module must have a test) and asked for help after few hours of trying. Changing to a normal "import xxx" solved the problem. It's not always clear what was the exact issue, except side effects due to imports.
      - codethief 6y ago
        Let me take the opposite standpoint here and play the devil's advocate. > users of the library can call "httpclient.sslsocket" and "httpclient.hlib" as if they were provided by the library Well, they obviously shouldn't. And maybe they also shouldn't write Python code to begin with because, clearly, they're not able to adhere to Python conventions. Besides, why do you as the library developer care so much about what the users of the library do? If they don't follow your API specifications (proper API documentation should tell the users what they should and shouldn't do), it's their fault. I mean, people can and will shoot themselves in the foot all the time and in various ways. There's is nothing you can do about it. > which doesn't always work as expected when paths are hot patched as above. There is a reason why hot patching (and, by implication, mocking) needs to be done with care and only if you fully understand the consequences. Regarding issues with mocking specifically, I suppose you're referring to nasty questions like https://stackoverflow.com/questions/14341689/how-to-mock-using-patch-relative-paths/ https://stackoverflow.com/questions/14341689/how-to-mock-usi... ? Again, these things need to be done with care. (And of course the code also needs to be written in a testable way – no surprise here – and mocking should be done only if you've exhausted all other options.) > It's not always clear what was the exact issue, except side effects due to imports. Like you I am a Pythonista but I have honestly never run into any problems with selective imports (`from X import Y`) or import renaming (`import X as Y`) and much less even know what problems you're talking about. Overall, I find Python's way of importing modules rather straight-forward. (That is, as long as PYTHONPATH and __name__ are set correctly. From my POV, this is the only seriously annoying caveat.) Anyway, I'm very open to changing my opinion but I'm afraid you'll have to be more specific about the issues you're encountering so often. (If you really did encounter them so often, I would think you would have noticed a pattern by now? No offense.)
nbadg 6y ago
It's worse than that actually, as in some cases the single underscore is actually meaningful (see the SO question linked in [1]). My recommendation is always to use a double underscore for throwaway variables, particularly since dropping into an interactive terminal can be really useful in some particularly hairy debugging situations (there's a great pycon talk about when it's a good idea to do gross things like that during debugging [2]). Guietta looks interesting, but at a certain point if you're going to go with a visual representation of your gui to automatically generate it, you might as well go the whole docopt-style way and just have the whole gui defined in a docstring. That give you flexibility to have your own DSL as well (or jinja2 templates, or whatever), if you so decide, instead of needing to shoehorn python lists into the job. Plus that way you could actually modify the layout spacing, without much increase in complexity. That being said, my usual recommendation for "I need a simple python GUI" is Toga [3]. The only downside is that Windows support is lagging behind MacOS and Linux, but it's not that far behind, so for simple stuff that should be reasonably acceptable. [1] https://stackoverflow.com/questions/5893163/what-is-the-purpose-of-the-single-underscore-variable-in-python https://stackoverflow.com/questions/5893163/what-is-the-purp... [2] https://www.youtube.com/watch?v=bAcfPzxB3dk https://www.youtube.com/watch?v=bAcfPzxB3dk [3] https://toga.readthedocs.io/en/latest/ https://toga.readthedocs.io/en/latest/

codethief 6y ago

Couldn't you simply do something like >>> from guietta import _ as underscore to fix this?

user5994461 6y ago
After spending inordinate amounts of time debugging obscure side effect caused by "import as" and "from import". I'd reject that "from import as" on sight in code review.
- detaro 6y ago
  Any hints towards what kind of issues those cause? I could see some around relative imports, or something else?
  - user5994461 6y ago
    Let's say you write a module httpclient doing this: from ssl import sslsocket import httplib as hlib You can think of the code above as remapping and/or duplicating the whole library it's importing. Python imports involve complex local and global states (I don't pretend to understand most of it). One direct effect on usage is that users of the library can call "httpclient.sslsocket" and "httpclient.hlib" as if they were provided by the library (the author certainly didn't mean to). This creates problem down the line when the author try to change the internal dependency, and this extends to other code also doing "import httpclient.sslsocket as sslsocket", creating problematic hidden dependencies. More generally, this affects all import dependent features, like reload(module), mock, sys content, etc... imports are looked up and tracked by full path which doesn't always work as expected when paths are hot patched as above. I used to work in a python shop (millions of line in total across the organization). Regularly had the problem with interns and new graduates abusing imports as above (sometimes even trying to change the existing imports because they though this was the better syntax). Then they couldn't pass their own tests (every new module must have a test) and asked for help after few hours of trying. Changing to a normal "import xxx" solved the problem. It's not always clear what was the exact issue, except side effects due to imports.
    - codethief 6y ago
      Let me take the opposite standpoint here and play the devil's advocate. > users of the library can call "httpclient.sslsocket" and "httpclient.hlib" as if they were provided by the library Well, they obviously shouldn't. And maybe they also shouldn't write Python code to begin with because, clearly, they're not able to adhere to Python conventions. Besides, why do you as the library developer care so much about what the users of the library do? If they don't follow your API specifications (proper API documentation should tell the users what they should and shouldn't do), it's their fault. I mean, people can and will shoot themselves in the foot all the time and in various ways. There's is nothing you can do about it. > which doesn't always work as expected when paths are hot patched as above. There is a reason why hot patching (and, by implication, mocking) needs to be done with care and only if you fully understand the consequences. Regarding issues with mocking specifically, I suppose you're referring to nasty questions like https://stackoverflow.com/questions/14341689/how-to-mock-using-patch-relative-paths/ https://stackoverflow.com/questions/14341689/how-to-mock-usi... ? Again, these things need to be done with care. (And of course the code also needs to be written in a testable way – no surprise here – and mocking should be done only if you've exhausted all other options.) > It's not always clear what was the exact issue, except side effects due to imports. Like you I am a Pythonista but I have honestly never run into any problems with selective imports (`from X import Y`) or import renaming (`import X as Y`) and much less even know what problems you're talking about. Overall, I find Python's way of importing modules rather straight-forward. (That is, as long as PYTHONPATH and __name__ are set correctly. From my POV, this is the only seriously annoying caveat.) Anyway, I'm very open to changing my opinion but I'm afraid you'll have to be more specific about the issues you're encountering so often. (If you really did encounter them so often, I would think you would have noticed a pattern by now? No offense.)

nbadg 6y ago

It's worse than that actually, as in some cases the single underscore is actually meaningful (see the SO question linked in [1]). My recommendation is always to use a double underscore for throwaway variables, particularly since dropping into an interactive terminal can be really useful in some particularly hairy debugging situations (there's a great pycon talk about when it's a good idea to do gross things like that during debugging [2]). Guietta looks interesting, but at a certain point if you're going to go with a visual representation of your gui to automatically generate it, you might as well go the whole docopt-style way and just have the whole gui defined in a docstring. That give you flexibility to have your own DSL as well (or jinja2 templates, or whatever), if you so decide, instead of needing to shoehorn python lists into the job. Plus that way you could actually modify the layout spacing, without much increase in complexity. That being said, my usual recommendation for "I need a simple python GUI" is Toga [3]. The only downside is that Windows support is lagging behind MacOS and Linux, but it's not that far behind, so for simple stuff that should be reasonably acceptable. [1] https://stackoverflow.com/questions/5893163/what-is-the-purpose-of-the-single-underscore-variable-in-python https://stackoverflow.com/questions/5893163/what-is-the-purp... [2] https://www.youtube.com/watch?v=bAcfPzxB3dk https://www.youtube.com/watch?v=bAcfPzxB3dk [3] https://toga.readthedocs.io/en/latest/ https://toga.readthedocs.io/en/latest/