5 ms·

I'm afraid I disagree. I programmed in a variety of languages in grad school (physics): C, C++, Fortran 77, Tcl, Perl, Matlab, Maple, Mathematica, IDL, Emacs LI

by drauh 10y ago

I'm afraid I disagree. I programmed in a variety of languages in grad school (physics): C, C++, Fortran 77, Tcl, Perl, Matlab, Maple, Mathematica, IDL, Emacs LISP, etc. Not to mention the stuff I started on in high school. When I switched my analysis to Python, I became so much more productive. And other science researchers I have known have echoed this sentiment. Even writing a C module to speed up my Python was pretty straightforward, if tedious. Python had the fewest surprises. And debugging other people's Python is exponentially less annoying than debugging other people's Fortran or C. It's still my go-to language to get stuff done without fuss.

skywhopper 10y ago
Yep, this was my point. I'm curious what makes Python seem so obviously clear to other people, but not to me. Maybe it's the OO approach. I had done a lot of Java, Smalltalk, and Ruby before I ever tried to approach Python. Maybe it's because Python's OO support feels (to me) bolted on compared to those other languages which are obviously OO from the bottom up, and I'm unwittingly trying to apply mental models I developed in those other languages to how I think about Python.
- xapata 10y ago
  But Python is OO from the bottom up. Unlike Java, everything in Python is an object. Perhaps your experience with objects in other languages has given you a different mental model for what an object is. I find Python objects to be more straightforward than in other languages, especially because classes are objects, too.
  - skywhopper 10y ago
    If it really is OO, then the global `len()` function and like explicitly declaring "self" in method declarations makes it _feel_ bolted on (to me). Why is `len()` special? I immediately question what other basic operations aren't methods, but global functions. And as for method declaration, if you aren't satisfied with implicit self, I much prefer Go's choice of having you declare the self reference for methods before the method name, instead of in the argument spec list (which then doesn't match the calling list). Python's way makes it feel like the compiler writer couldn't be bothered to hide the OO implementation on the declaration side, but embraced it on the calling side. Meh, I know these have been hashed over a thousand times here. Just some of the things that rub me the wrong way when I've tried to deal with Python.
    - xapata 10y ago
      You can find explanations for both those questions in the design FAQ. The explicit self came from Modula-3. https://docs.python.org/2/faq/design.html#why-must-self-be-used-explicitly-in-method-definitions-and-calls https://docs.python.org/2/faq/design.html#why-must-self-be-u... The explanation for len is a little lacking. https://docs.python.org/2/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list https://docs.python.org/2/faq/design.html#why-does-python-us... Guido once explained further in an email to the mailing list. I've forgotten some of it, but the gist is that he didn't want anyone to accidentally create or override a .len() method to do something other than tell the number of elements in the container. And... almost everything is a method. Even ``len(obj)`` is just sugar for ``obj.__len__()``.
      - ubernostrum 10y ago
        almost everything is a method Not "almost". Just "everything is a method", in terms of function calls. Even user-defined standalone functions. Consider: def my_func(arg): return arg + 5 The following are equivalent, and show how things work: my_func(3) and my_func.__call__(3) and types.FunctionType.__call__(my_func, 3)
        xapata 10y ago
        I'm not certain, but I think the C API can avoid that. I've learned to say "almost" because every time I say Python can't X, someone shows me it can.
        ubernostrum 10y ago
        There are a few functions in the C API to let you call things, depending on the type of thing and set of arguments you feel like providing, and they rely on the Python API to handle the calling for you. I imagine if you really wanted to, and knew enough about the structure and expectations of the Python object you were working with, you could "manually" call without going through one of those C API functions, but I don't know that I'd recommend trying it...

by drauh 10y ago

skywhopper 10y ago

Yep, this was my point. I'm curious what makes Python seem so obviously clear to other people, but not to me. Maybe it's the OO approach. I had done a lot of Java, Smalltalk, and Ruby before I ever tried to approach Python. Maybe it's because Python's OO support feels (to me) bolted on compared to those other languages which are obviously OO from the bottom up, and I'm unwittingly trying to apply mental models I developed in those other languages to how I think about Python.

xapata 10y ago
But Python is OO from the bottom up. Unlike Java, everything in Python is an object. Perhaps your experience with objects in other languages has given you a different mental model for what an object is. I find Python objects to be more straightforward than in other languages, especially because classes are objects, too.
- skywhopper 10y ago
  If it really is OO, then the global `len()` function and like explicitly declaring "self" in method declarations makes it _feel_ bolted on (to me). Why is `len()` special? I immediately question what other basic operations aren't methods, but global functions. And as for method declaration, if you aren't satisfied with implicit self, I much prefer Go's choice of having you declare the self reference for methods before the method name, instead of in the argument spec list (which then doesn't match the calling list). Python's way makes it feel like the compiler writer couldn't be bothered to hide the OO implementation on the declaration side, but embraced it on the calling side. Meh, I know these have been hashed over a thousand times here. Just some of the things that rub me the wrong way when I've tried to deal with Python.
  - xapata 10y ago
    You can find explanations for both those questions in the design FAQ. The explicit self came from Modula-3. https://docs.python.org/2/faq/design.html#why-must-self-be-used-explicitly-in-method-definitions-and-calls https://docs.python.org/2/faq/design.html#why-must-self-be-u... The explanation for len is a little lacking. https://docs.python.org/2/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list https://docs.python.org/2/faq/design.html#why-does-python-us... Guido once explained further in an email to the mailing list. I've forgotten some of it, but the gist is that he didn't want anyone to accidentally create or override a .len() method to do something other than tell the number of elements in the container. And... almost everything is a method. Even ``len(obj)`` is just sugar for ``obj.__len__()``.
    - ubernostrum 10y ago
      almost everything is a method Not "almost". Just "everything is a method", in terms of function calls. Even user-defined standalone functions. Consider: def my_func(arg): return arg + 5 The following are equivalent, and show how things work: my_func(3) and my_func.__call__(3) and types.FunctionType.__call__(my_func, 3)
      - xapata 10y ago
        I'm not certain, but I think the C API can avoid that. I've learned to say "almost" because every time I say Python can't X, someone shows me it can.
        ubernostrum 10y ago
        There are a few functions in the C API to let you call things, depending on the type of thing and set of arguments you feel like providing, and they rely on the Python API to handle the calling for you. I imagine if you really wanted to, and knew enough about the structure and expectations of the Python object you were working with, you could "manually" call without going through one of those C API functions, but I don't know that I'd recommend trying it...