Ask HN: What is your least favorite part of your favorite language?

I'm not sure that it's a good reason, but the explicit self allows for weird intermingling of functions and members. For instance,

    class foo:
        def __init__(self,val):
            self.x=val
        def square(self):
            return self.x**2

    #imperative way
    imperative = [foo(x).square() for x in range(5)]

    #functional way
    s = foo.square
    composed = lambda x: s(foo(x))
    functional = map(composed,range(5))

    print imperative==functional

The explicit self allows you to treat member functions as generic function and compose them in a functional way. Now, most functional programming isn't necessarily Pythonic. However, given a proper compose function, I could imagine it being useful to mix a long chain of function and member calls without needing to make a distinction between the two.

iOS?

I found it a little confusing ready ruby code that omits parentheses, but sometimes I feel like a method call with no input params shouldn't need parens

I agree with the python one. Some more things I find annoying in Python:

- Hardcoded recursion limit + no tail call optimization. I understand Guido's reasons for this but I find myself writing ugly code instead of beatiful code. (But maybe changing this would make Python's internals ugly.)

Mainly Python but other languages too. - Length of the collection: len(foo). String representation: str(foo). Why not foo.len() or foo.str(). Or even better: foo.len or foo.str. As a Python user, I'm not a fan of getters. I think we should use the "attribute syntax" to get data about and of the object/type/thing, regardless if it involves any computations or not. (but would probably generate more problems than solve little nitpicks)

I second the Python one. Why the wierd distinction between packages, modules, and things in files?

I believe all of these three should give me os.path.isdir:

    import os
    import os.path
    import os.path.isdir

    os.path.isdir(...)

And to get isdir() directly, I would use either:

    from os.path import isdir
    import os.path.isdir as isdir

This should work if path is either a package (a directory), a module (a file), or an object defined in os.py!

Sometimes, for some reason if I only import a module, I can't use submodules. So `import os` wouldn't give `os.path.isdir`. I don't know when that occurs, maybe it was in an ancient version of python. But it leaves me with an uneasy feeling every time I use a submodule. Anyone know when this happens?

Last but not least, it should be easier to import stuff from above the script. If my script lives at ./tools/foobar.py, and I want to import ./helper.py, it should just be something like

    # ./tools/foobar.py
    from .. import helper
    
    $ python ./tools/foobar.py     # simple run-a-script syntax

and not

    $ python -m tools/foobar       # hideous run-a-module syntax

or what I'm using now

    # ./tools/foobar.py
    # hideous boilerplate header
    import sys, os
    SCRIPTDIR = os.path.relpath(os.path.dirname(__file__) or ".")
    PARENTDIR = os.path.relpath(os.path.join(SCRIPTDIR, ".."))
    sys.path.insert(0, PARENTDIR)

    import helper

    $ python ./tools/foobar.py     # simple run-a-script syntax