381–390 of 554 posts
Earlier quoted context omitted.
> They pass by pointer-value. No, Python doesn't even do that, because Python variables aren't names for storage locations to begin with. They're namespace bindings. Passing a variable to a Python function means transferring a namespace binding from the caller's namespace to the function's local namespace.
The semantics are identical.
Earlier quoted context omitted.
With regard to "pass by reference", it's not even clear to me that that's a correct way to describe how Python passes variables to functions. Python variables aren't names for storage locations to begin with; they're namespace bindings. Passing a variable to a function means passing a particular namespace binding from the caller's namespace to the function's local namespace. I don't think the author of this article u…
> Passing a variable to a function means passing a particular namespace binding from the caller's namespace to the function's local namespace. I don't think that's true, as the function will never be able to change the binding, and only gets a reference to the value of the binding. If the function was passed a particular namespace binding, it would be able to change this binding's value, and that's not possible. I ag…
More precisely, the function's arguments when it is called are a set of values for variables taken from the caller's namespace, which then get bound to the corresponding names in the local namespace. You're right that "passing the binding" doesn't really describe that process very well.
Many of the reasons authors states are quite silly. Personally I don’t like the huge perf hits everywhere you look. For example, a bool in Python takes whopping 24 bytes! Multi threading is a giant mess due to GIL that apparently no one can get rid of. Things like true static variables are missing. Import behavior differences for programs and modules is baffling. Lambda is intentionally kept under powered (ex. no gro…
Earlier quoted context omitted.
With regard to "pass by reference", it's not even clear to me that that's a correct way to describe how Python passes variables to functions. Python variables aren't names for storage locations to begin with; they're namespace bindings. Passing a variable to a function means passing a particular namespace binding from the caller's namespace to the function's local namespace. I don't think the author of this article u…
> Python variables aren't names for storage locations to begin with; they're namespace bindings. Can you explain the difference? What is a "namespace binding"? When accessing a variable's value, the interpreter's code sure looks like it treats the variable name as the name of a storage location. > Passing a variable to a function means passing a particular namespace binding "Passing a variable to a function" is not a…
An entry in a Python dictionary that is the namespace for the current scope.
For example, to repeat a response I gave to someone else upthread, compare a variable assignment in C and Python.
In C:
int i = 17;
In Python:
i = 17
My top 3 criticisms as an intermediate (~5 months of study) python programmer: 1. Importing behavior is ridiculous: https://chrisyeh96.github.io/2017/08/08/definitive-guide-pyt... 2. Python libraries' documentation leave a lot to be desired (compared to good javadocs). Just because your language is dynamically typed doesn't mean you don't need to describe what the expected shape of a parameter should be. 3. Static me…
I've been developing Python for upwards of 10 years, and not one single time I have ever had a legitimate use for double underscore, and I've only seen one legitimate use in the wild (involving auto-generated code and C interfacing).
You also very, very rarely need static methods.
Earlier quoted context omitted.
It's funny how far off the author was, because there are genuine things to complain about with python, though they may not be exclusive to python. I regularly wish python required some sort type indication for function parameters, because dealing with libraries that take complex objects as function parameters can be an absolute nightmare. I wish python had some equivalent to the switch statement that didn't involve w…
Edit: Also fuck this whole "it's so cool to shit on Java" thing. Grow up. You aren't in college anymore. You should recognize that Java fills its niche effectively, and does a decent job of being semi-fast, portable, easy to read and maintain, and safe. The "it's so cool to shit on Java" thing served an important purpose and is probably close to being retired, but it's easy not to understand if you weren't a Java pro…
I'm a python hater. Yes it is easy, but in exactly the wrong way. Easy for simple code for middle schoolers. For grownups with large codebases to develop and maintain, it's not optimal. Of course I hate the whitespace trickery. I hate the auto formatting that sometimes doesn't work. Those are fairly minor. What I really, really hate is the lack of static typechecking. You often have to read lengthy swathes of code to…
I used to program in Python, and found Ruby as a language to give me everything Python provides but with a more Programmer friendly syntax. I never understood why you would use a function like len() in an Object Oriented Language (instead of x.len ) or having to explicitly add self to every method...
The answer is simple: there is a x.len function. It's just x.__len__, the protocol. Forcing it to be exposed on every type is a waste: do you use .len, .length, .size? This duck-typing allows any object that supports the length protocol to be passed to `len()`. Simple.
Having it add itself to every object is.... not what you want at all. Some objects don't have a length.
I was looking how to get first element of an array or get nil if the array is empty.
Python library doesn't provide this kind of functionality.
https://stackoverflow.com/questions/363944/python-idiom-to-r... offers multiple ugly ways of doing it.
For Ruby, we use `.first`.
In Ruby, the standard library is richer. A lot of libraries are "official" because Rails uses it.
The version problem is Python being a victim of its own success. Since so many Linux distros used Python 2 for system scripting, you still have to have a Python 2 sitting around on your system somewhere. Then people came along with "python3" and (yikes!) "pip3", but now you might have python 3.4, 3.5, 3.6 and 3.7. The transition was pretty painful because of the Unicode thing. It does make it painful, though, to give…
Pyenv[1] is your friend.
pyenv install 3.6.4
Earlier quoted context omitted.
> 1 (versions) and 2 (installation) have to do with the ecosystem, not the language. This argument really summarizes a beautiful and dangerous thing we see in the tech community far too often; you have a strong technical and scientific understanding of the system, but lack product and design thinking. You're right. Its a problem with the ecosystem, not the language. I'm still not going to use python because of the ec…
Note how almost all languages you take as shiny examples of virtue post-date Python: they all learnt from it so much , particularly on things like the stdlib. Python’s stdlib was the gold standard for a long, long time (the “batteries included” slogan was effective for a reason - they really were!). This was not by accident - Guido and others have always had the utmost care for good developer experience out of the bo…
The Java module experience is miles ahead of the Python one. There's no global module path where you can install different things on different machines, nothing that screws up if you accidentally run it as root, no stateful virtualenvs where different shell windows run the same project with different versions of python. You just list your dependencies in your POM (which, yes, is XML; it was the early 2000s, everyone was doing it, and it does make it easy for your IDE to put a nice editor interface on it) and that's it, you're done: released versions are immutable and transient dependency resolution is deterministic, so you don't have to worry about pinning/unpinning or anything like that. There's a well-known repository that all the important libraries are in; as and when you want to have a company private repository there are a couple of standard ones you can pick from and run, either just for your own artifacts or proxying third-party libraries from the central one as well. It all Just Works.
Maven came out 14 years ago and Python still doesn't have anything that works nearly as well.