71–80 of 117 posts
Earlier quoted context omitted.
conda solves that for python at least as well as npm/yarn does. I don't understand while it is not in wider use (except for lack of PR).
how does conda solve this? Will conda fallback to pip if the conda repository doesn't contain one of your dependencies?
The main drawback of python for me, compared to NodeJS is the whole sharing projects onto different machines with virtualenv or whatever. package.json and node_modules just works by default in so much cleaner a way. You can use npm or yarn or just a zip of the node_modules to share the environment with a colleague or to deploy.
conda solves that for python at least as well as npm/yarn does. I don't understand while it is not in wider use (except for lack of PR).
Earlier quoted context omitted.
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 t…
> 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 approac…
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.
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…
For C# on Linux Avalonia looks promising. https://avaloniaui.net/
The main drawback of python for me, compared to NodeJS is the whole sharing projects onto different machines with virtualenv or whatever. package.json and node_modules just works by default in so much cleaner a way. You can use npm or yarn or just a zip of the node_modules to share the environment with a colleague or to deploy.
There should be one-- and preferably only one --obvious way to do it.
These are minor annoyances to me. The major annoyance I have with Python is that most Python code makes such heavy use of classes, even when it only needs lists, tuples, and dicts. Why do I really need a class, when: - Instance fields can be added and removed at runtime - Private fields and methods are not actually private ("we're all consenting adults here") - No pattern matching on types and `if isinstance(foo, Bar…
Isn't the reason to use classes the dispatch aspect of it? If I take in a duck-typed object and call obj.foo(), then I get an appropriate class-specific version of foo(). Like you said, isinstance() is an anti-pattern - I don't want to define a function that behaves differently based on explicit testing of input type, because that wrecks the duck typing. Right?
When I do have a datatype that needs to be handled differently based on some condition, I tend to use ABC's with only one level of concrete subclasses, just to make that implicit method interface explicit.
Earlier quoted context omitted.
No compiler can read your mind. But in a language with brackets, the compiler can at least determine scope even when things are poorly-indented. In Python it can't in a lot of cases. It's like static type checking: The class of errors the compiler can catch is larger when it's present. Likewise, with visible scoping characters, the class of errors the compiler can catch is larger than when they are invisible.
> But in a language with brackets, the compiler can at least determine scope even when things are poorly-indented. Yes, but can it determine scope if things are poorly-bracketed? Because that's the fair comparison.
That's not true of indent mistakes. Semantic whitespace is lossy -- there's data contained in those brackets that some people think is low-value that it's expendable for the sake of saving keystrokes, but it does have value in practice.
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…
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 issue…
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
Earlier quoted context omitted.
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 issue…
> 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 basi…
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).