Hacker News Reader

Comment by roland35 | Hacker News Reader

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++.

View on HN

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. 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! :)

> 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

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).

>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.

Well, that's not exactly the case. Interface{} might have the same tradeoffs with Python's dynamic types (plus more ceremony), but that's not the real issue.

Python is inherently a dynamic typed language, so not having types and generics is expected and idiomatic.

For Go, you have a type system and static type checking, but you can't properly use it when you resort to interface{} to make generic algorithms.

So while for Python not having types/generics is business as usual (and that's part of the very promise of the language), for Go not having generics means losing two of it's main promises, static type checking and speed.

For whatever it's worth, I'm a proponent of generics in Go.

"Static type checking" does not mean "every conceivable program is safely expressable by the type system". Haskell doesn't make this promise and neither does Go.

Anyway, Go is as slow and as unsafe as Python in the ~1-5% of code that is generic. It's still a pretty good deal even if you were mistakenly expecting 0%.

>"Static type checking" does not mean "every conceivable program is safely expressable by the type system". Haskell doesn't make this promise and neither does Go.

No, and I didn't make this claim or demand this either.

But it should mean: "any algorithm variation where just the type changes should be expressable by the type system without me having to rewrite e.g. a sort list for int64 lists, int32 lists, float lists, etc, it's 2019 already".

That's not what static typing means. If you want it to mean that, go right ahead. I agree that Go should support that feature, but it has no bearing on the definition of static typing nor on Go's position relative to Python with respect to speed or safety.

PEX looks interesting! Thanks for the link. I have this same issue

Trio is my favorite async library. It's simple and extremely powerful. https://trio.readthedocs.io

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.

I've found that the built-in tkinter lib is good enough for basic GUIs that you might use on a utility.

That's the one I've tried a bit before, but haven't spent enough time to be comfortable with it. The crux of it for this project is that if I were making a UI I'd like to move the data validation in to that (and add some more sanity checking) with visual indications if there's a bad row or something looks off. Currently it just it yells at you and terminates if there's invalid data.

So a UI rewrite would make it much friendlier to other users, but it'd be a time investment I can't justify over the "just don't give it bad data" strategy.

The inputs and outputs are all handled manually so reliability isn't a huge focus as long as someone can poke around for a bit and make it work. Only user is me for now, so ¯\_(ツ)_/¯

    # TODO: make it less shitty

if you just want to make a self contained executable for windows users I've used py2exe a few times and it always works well. It's basically one command and it gives you an exe of your .py file

https://pypi.org/project/py2exe/

py2exe and anything else that uses Joachim Bauch's memory loader is loading DLLs in a broken fashion that is bound to bite you sooner or later, assuming it works in the first place.

Reimplementing - in a buggy incompatible way - the Windows loader (which is what that code is doing) from scratch, is a gross hack and should not be used to build anything that's meant to be reliable.

Note that pyinstaller and cx_freeze do not suffer from these issues. Do not use py2exe.

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/

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?

> If it's for an internal only tool, does that fit under all the GPL / LGPL requirements?

Yes.

I used to be type of of developer who would always make executables and installers in years gone by. I find now in all cases I whip up what I want to do as a script and then embed it in Flask as a webapp. The only thing I don't do this is with compiler tools that I can bring in with cmake etc. If the app needs data I just add an upload button or have it point at S3. YMMV.

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.

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.

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?

> 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.

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!

> 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.

> 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.

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_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.

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/

This project- 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.

> 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.

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.

Reply on news.ycombinator.com