7 ms·

I agree with the response that there are a few "gotchas" with python, like with any language! I have gotten caught up with a few type problems when dealing with

I agree with the response that there are a few "gotchas" with python, like with any language! I have gotten caught up with a few type problems when dealing with sending raw binary data over serial and things like that - but luckily python has great unit testing frameworks to help with this. My main beef with python is that it is harder to deploy projects to other people, without them setting up a virtual environment or things like that. I know that there are some tools to help compile but they aren't easy to use. Also, it is hard to create GUI applications vs languages like C#! Other than that I love using python and I think it is a great tool to use in embedded development along with c/c++.

metalliqaz 7y ago
I also run up against the deploying problem quite a bit. For the most part, only Windows has been a real issue for me. Lately I've use Cython and found that adds an even tougher layer of difficulty to the problem.
WilliamEdward 7y ago
All true, but I don't think python's really supposed to be perfect for making desktop apps, its lack of static typing means a large scale app would end up becoming a pain to maintain. That's why it is best used in small teams for data science and scripting; run once and never look back. Most complaints about python IMO fail to appreciate its design philosophy.
- jofer 7y ago
  Just my $0.02: I've maintained and/or written more than a few large desktop apps in both python and C++. The python ones are a hell of a lot easier to maintain, i.m.o. Python _is_ strongly typed unlike JS, and I don't feel like the dynamic typing aspects have ever really bit me from a maintenance perspective. At least in my experience, I've seen a lot of either verbose/repetitive or highly cryptic C++ written to in situations that dynamic typing makes straightforward and i.m.o easier to maintain. To be fair, though, I have a pretty accurate mental model of what python's doing under the hood, and I still regularly find myself mystified by certain C++ language features and what the compiler actually does in slightly ambiguous situations. I've nominally been using C++ longer, but I've used python a lot more frequently. (I'm primarily in scientific computing.) As a whole, I've always found python to be a nice language from a maintenance perspective, though I'll grant that people have more room to do bizarre things in some circumstances. I've definitely seen some unmaintainable and unreadable python, but I've seen that every bit as frequently in static-typed languages. I feel that python is quite well-suited to desktop application development. Part of this boils down to Qt being a nice library regardless of whether you're working in C++ or python. However, python codebases tend to be more succinct and readable. In the end, I've consistently found that to be a larger advantage in maintenance than static typing.
  - SketchySeaBeast 7y ago
    I find any one block of code more enjoyable and succient to read in Python, but with very large implementations I can't figure out a good methodology to maintain it all. How do you deal with arbitrary objects being passed around and not know what's potentially coming from where? With something like C# without having to know the whole solution I can easily figure out what's coming into a function and manipulate that to get the desired result. With Python, is it just matter of getting a model of the whole system? Or do you take advantage of your IDE to hopefully supply all that information to you?
    - jofer 7y ago
      > How do you deal with arbitrary objects being passed around and not know what's potentially coming from where? Honestly, by trusting that those objects conform to what things are documented to expect and using operations that will naturally raise an error for unexpected cases. Basically, you don't depend on compile-time or IDE-time checks, you depend more heavily on tests. It allows for much more of a direct approach. E.g. if something's documented to accept a sequence, I don't care whether it's a list, tuple, some custom object, etc, I just need it to have certain properties like iteration and ability to index. You write things to expect certain abstract categories of types and do things that will raise errors if they're not in the category you expect. The downside is that nothing is enforcing that in an IDE or at compile time. As a result, you need more integration tests. In some ways, yes, you're more at the mercy of other developers behaving well. The flip side to that is more flexibility and less duplication.
      - SketchySeaBeast 7y ago
        Ah, OK, so you build the "checking" in via process and practice. It requires more discipline, but you end up evolving to kind of a similar place, but with more flexibility. Thanks!
      - weberc2 7y ago
        > Honestly, by trusting that those objects conform to what things are documented to expect and using operations that will naturally raise an error for unexpected cases. Which is really hit or miss in the wild. Even the standard library documentation doesn't reliably document types. There are abundant references to "file-like objects" as though that is a type. It is (or at least was) totally unclear if a "file-like object" supports seek() or just read() and write(). Our internal Python code is a mess as well; we can't keep documentation up to date with function signatures (even though it's part of our code review process). As someone who develops primarily in Python, I think you're missing out on quite a lot if you think C++ is a good characterization of the state of static typing. Having used Python and Go and a few other languages, I'm convinced that static typing is more productive when it's done well.
vangourd 7y ago
I know you mentioned the build tools but I didn't know if you knew they can work with Qt. QT for Python and The Fman build system would allow you to deploy in some cases a single executable. https://wiki.python.org/moin/PyQt/Deploying_PyQt_Applications https://wiki.python.org/moin/PyQt/Deploying_PyQt_Application... That being said I had issues getting everything installed correctly with Pipenv and then locking the specific versions that are compatible. fman and pyside2. A GUI builder comes with the Pyside2 package qtdesigner.exe I think.
wlesieutre 7y ago
I have the same two complaints. I’ve automated some large tasks at my job with Python, and avoided external dependencies because while I’m sure I could deal with it, nobody else here is a programmer and it don’t think it would go well if someone had to try and figure that out later. “Install python (3.6 or later), point script at the csv file” avoids that complexity. It’d be better if it were a self contained executable with a GUI but not worth the time to figure that out. I messed around with TkInter a while back, not sure if anything's new since then. For executables there was py2exe, cx_freeze, and PyInstaller, but the situation with packaging DLLs into an executable that would actually work on someone else's computer was iffy last I checked.
- noobiemcfoob 7y ago
  I believe fbs might have massaged some of your GUI packaging problems. I haven't used it myself, but a coworker who builds a Windows GUI application swears by it. From him, "It's the package manager python doesn't deserve" https://build-system.fman.io/ https://build-system.fman.io/
  - wlesieutre 7y ago
    Looks interesting, though the license situation seems less than ideal. If it's for an internal only tool, does that fit under all the GPL / LGPL requirements?
    - CogitoCogito 7y ago
      > If it's for an internal only tool, does that fit under all the GPL / LGPL requirements? Yes.
- metalliqaz 7y ago
  I've found that the built-in tkinter lib is good enough for basic GUIs that you might use on a utility.
  - wlesieutre 7y ago
turtlebits 7y ago
This project- https://github.com/unixtreme/D3Edit https://github.com/unixtreme/D3Edit, has an interesting approach of bundling the virtual environment for linux/Mac/Windows and activating the corresponding when you launch the script.
weberc2 7y ago
I wish it had a better async story. We've had production outages that were difficult to debug because some third party library made a sync call deep in the call stack and starved the event loop. APM showed performance degradation in unrelated endpoints. Eventually health checks began failing and containers were killed, putting the load on other containers which inevitably fell over and so on. We've seen similar issues with CPU starvation due to CPU-intensive tasks as well, though they were more straightforward to debug. We also continue to see runtime type errors because someone forgot to await an async function: `rsp = aiohttp.get() # oops, rsp is the promise, not the response!`. As far as deployment goes, we've had good luck with pex files (executable zip files containing everything but the interpreter). https://github.com/pantsbuild/pex https://github.com/pantsbuild/pex. Your deployment target still needs the right version of the Python interpreter and .so files that your dependencies might link against. Personally, I've found that Go solves most/all Python issues without introducing too many of its own--and anyone writing Python (sans mypy) doesn't get to chastise Go for lacking generics! :)
- fizzybeetle 7y ago
  > anyone writing Python (sans mypy) doesn't get to chastise Go for lacking generics! :) Why do you say this point in particular? Python's duck typing makes generics very easy, no? i.e., you can write an algorithm in python that just assumes a particular method is callable and you don't have to code gen individual implementations for different types. plus the dunder (e.g., `__iadd__`) methods give a lot of useful basic functionality
  - weberc2 7y ago
    Mostly I was just amusing myself, but here's what I meant: Usually when people refer to generics they're referring to a static type system that allows for expressing generic algorithms. (Untyped) Python inherently has no static type system, so necessarily can't support generics by that definition. The other definition of generics that _is_ satisfiable by (untyped) Python--the definition you presumably had in mind--is equally satisfiable by Go via its `interface{}` type. So regardless of which definition you adhere to, "Go lacks generics" is no more valid a criticism for Go than for Python. Practically speaking, there's some syntax ceremony involved in using `interface{}` in Go; coming from Python or another dynamic language, this ceremony will probably offend your sensibilities--why is it so hard to opt out of the type system!? But that's by design--Go generally tries to keep you on the path of correctness without being overbearing (as many find stricter languages--e.g., Haskell--to be).
jbergens 7y ago
C# has been more focused on Windows but there it has been very easy to create gui applications. In fact there are probably more (Windows) gui applications made with C# than with any other language. Maybe Electron and js has taken over now. For C# on Linux Avalonia looks promising. https://avaloniaui.net/ https://avaloniaui.net/
m463 7y ago
> My main beef with python is that it is harder to deploy projects to other people On the other hand, I think python has more "batteries included" than other scripting languages and for many projects you can usually figure out how to eliminate dependencies.
kumarvvr 7y ago
> Also, it is hard to create GUI applications vs languages like C# While this is a problem, for many projects, I have overcome this by including a local web-server, that accepts requests from 127.0.0.1 and serves a web app as a GUI. It's not a perfect solution, but It worked for me in many projects.

metalliqaz 7y ago

I also run up against the deploying problem quite a bit. For the most part, only Windows has been a real issue for me. Lately I've use Cython and found that adds an even tougher layer of difficulty to the problem.

WilliamEdward 7y ago

All true, but I don't think python's really supposed to be perfect for making desktop apps, its lack of static typing means a large scale app would end up becoming a pain to maintain. That's why it is best used in small teams for data science and scripting; run once and never look back. Most complaints about python IMO fail to appreciate its design philosophy.

jofer 7y ago
Just my $0.02: I've maintained and/or written more than a few large desktop apps in both python and C++. The python ones are a hell of a lot easier to maintain, i.m.o. Python _is_ strongly typed unlike JS, and I don't feel like the dynamic typing aspects have ever really bit me from a maintenance perspective. At least in my experience, I've seen a lot of either verbose/repetitive or highly cryptic C++ written to in situations that dynamic typing makes straightforward and i.m.o easier to maintain. To be fair, though, I have a pretty accurate mental model of what python's doing under the hood, and I still regularly find myself mystified by certain C++ language features and what the compiler actually does in slightly ambiguous situations. I've nominally been using C++ longer, but I've used python a lot more frequently. (I'm primarily in scientific computing.) As a whole, I've always found python to be a nice language from a maintenance perspective, though I'll grant that people have more room to do bizarre things in some circumstances. I've definitely seen some unmaintainable and unreadable python, but I've seen that every bit as frequently in static-typed languages. I feel that python is quite well-suited to desktop application development. Part of this boils down to Qt being a nice library regardless of whether you're working in C++ or python. However, python codebases tend to be more succinct and readable. In the end, I've consistently found that to be a larger advantage in maintenance than static typing.
- SketchySeaBeast 7y ago
  I find any one block of code more enjoyable and succient to read in Python, but with very large implementations I can't figure out a good methodology to maintain it all. How do you deal with arbitrary objects being passed around and not know what's potentially coming from where? With something like C# without having to know the whole solution I can easily figure out what's coming into a function and manipulate that to get the desired result. With Python, is it just matter of getting a model of the whole system? Or do you take advantage of your IDE to hopefully supply all that information to you?
  - jofer 7y ago
    > How do you deal with arbitrary objects being passed around and not know what's potentially coming from where? Honestly, by trusting that those objects conform to what things are documented to expect and using operations that will naturally raise an error for unexpected cases. Basically, you don't depend on compile-time or IDE-time checks, you depend more heavily on tests. It allows for much more of a direct approach. E.g. if something's documented to accept a sequence, I don't care whether it's a list, tuple, some custom object, etc, I just need it to have certain properties like iteration and ability to index. You write things to expect certain abstract categories of types and do things that will raise errors if they're not in the category you expect. The downside is that nothing is enforcing that in an IDE or at compile time. As a result, you need more integration tests. In some ways, yes, you're more at the mercy of other developers behaving well. The flip side to that is more flexibility and less duplication.
    - SketchySeaBeast 7y ago
      Ah, OK, so you build the "checking" in via process and practice. It requires more discipline, but you end up evolving to kind of a similar place, but with more flexibility. Thanks!
    - weberc2 7y ago
      > Honestly, by trusting that those objects conform to what things are documented to expect and using operations that will naturally raise an error for unexpected cases. Which is really hit or miss in the wild. Even the standard library documentation doesn't reliably document types. There are abundant references to "file-like objects" as though that is a type. It is (or at least was) totally unclear if a "file-like object" supports seek() or just read() and write(). Our internal Python code is a mess as well; we can't keep documentation up to date with function signatures (even though it's part of our code review process). As someone who develops primarily in Python, I think you're missing out on quite a lot if you think C++ is a good characterization of the state of static typing. Having used Python and Go and a few other languages, I'm convinced that static typing is more productive when it's done well.

vangourd 7y ago

I know you mentioned the build tools but I didn't know if you knew they can work with Qt. QT for Python and The Fman build system would allow you to deploy in some cases a single executable. https://wiki.python.org/moin/PyQt/Deploying_PyQt_Applications https://wiki.python.org/moin/PyQt/Deploying_PyQt_Application... That being said I had issues getting everything installed correctly with Pipenv and then locking the specific versions that are compatible. fman and pyside2. A GUI builder comes with the Pyside2 package qtdesigner.exe I think.

wlesieutre 7y ago

I have the same two complaints. I’ve automated some large tasks at my job with Python, and avoided external dependencies because while I’m sure I could deal with it, nobody else here is a programmer and it don’t think it would go well if someone had to try and figure that out later. “Install python (3.6 or later), point script at the csv file” avoids that complexity. It’d be better if it were a self contained executable with a GUI but not worth the time to figure that out. I messed around with TkInter a while back, not sure if anything's new since then. For executables there was py2exe, cx_freeze, and PyInstaller, but the situation with packaging DLLs into an executable that would actually work on someone else's computer was iffy last I checked.

noobiemcfoob 7y ago
I believe fbs might have massaged some of your GUI packaging problems. I haven't used it myself, but a coworker who builds a Windows GUI application swears by it. From him, "It's the package manager python doesn't deserve" https://build-system.fman.io/ https://build-system.fman.io/
- wlesieutre 7y ago
  Looks interesting, though the license situation seems less than ideal. If it's for an internal only tool, does that fit under all the GPL / LGPL requirements?
  - CogitoCogito 7y ago
    > If it's for an internal only tool, does that fit under all the GPL / LGPL requirements? Yes.
metalliqaz 7y ago
I've found that the built-in tkinter lib is good enough for basic GUIs that you might use on a utility.
- wlesieutre 7y ago

turtlebits 7y ago

This project- https://github.com/unixtreme/D3Edit https://github.com/unixtreme/D3Edit, has an interesting approach of bundling the virtual environment for linux/Mac/Windows and activating the corresponding when you launch the script.

weberc2 7y ago

I wish it had a better async story. We've had production outages that were difficult to debug because some third party library made a sync call deep in the call stack and starved the event loop. APM showed performance degradation in unrelated endpoints. Eventually health checks began failing and containers were killed, putting the load on other containers which inevitably fell over and so on. We've seen similar issues with CPU starvation due to CPU-intensive tasks as well, though they were more straightforward to debug. We also continue to see runtime type errors because someone forgot to await an async function: `rsp = aiohttp.get() # oops, rsp is the promise, not the response!`. As far as deployment goes, we've had good luck with pex files (executable zip files containing everything but the interpreter). https://github.com/pantsbuild/pex https://github.com/pantsbuild/pex. Your deployment target still needs the right version of the Python interpreter and .so files that your dependencies might link against. Personally, I've found that Go solves most/all Python issues without introducing too many of its own--and anyone writing Python (sans mypy) doesn't get to chastise Go for lacking generics! :)

fizzybeetle 7y ago
> anyone writing Python (sans mypy) doesn't get to chastise Go for lacking generics! :) Why do you say this point in particular? Python's duck typing makes generics very easy, no? i.e., you can write an algorithm in python that just assumes a particular method is callable and you don't have to code gen individual implementations for different types. plus the dunder (e.g., `__iadd__`) methods give a lot of useful basic functionality
- weberc2 7y ago
  Mostly I was just amusing myself, but here's what I meant: Usually when people refer to generics they're referring to a static type system that allows for expressing generic algorithms. (Untyped) Python inherently has no static type system, so necessarily can't support generics by that definition. The other definition of generics that _is_ satisfiable by (untyped) Python--the definition you presumably had in mind--is equally satisfiable by Go via its `interface{}` type. So regardless of which definition you adhere to, "Go lacks generics" is no more valid a criticism for Go than for Python. Practically speaking, there's some syntax ceremony involved in using `interface{}` in Go; coming from Python or another dynamic language, this ceremony will probably offend your sensibilities--why is it so hard to opt out of the type system!? But that's by design--Go generally tries to keep you on the path of correctness without being overbearing (as many find stricter languages--e.g., Haskell--to be).

jbergens 7y ago

C# has been more focused on Windows but there it has been very easy to create gui applications. In fact there are probably more (Windows) gui applications made with C# than with any other language. Maybe Electron and js has taken over now. For C# on Linux Avalonia looks promising. https://avaloniaui.net/ https://avaloniaui.net/

m463 7y ago

> My main beef with python is that it is harder to deploy projects to other people On the other hand, I think python has more "batteries included" than other scripting languages and for many projects you can usually figure out how to eliminate dependencies.

kumarvvr 7y ago

> Also, it is hard to create GUI applications vs languages like C# While this is a problem, for many projects, I have overcome this by including a local web-server, that accepts requests from 127.0.0.1 and serves a web app as a GUI. It's not a perfect solution, but It worked for me in many projects.