Hacker News new | past | comments | ask | show | jobs | submit login

It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time. At the end of the day, PEP8 is just a convention and we're free to break with it where it makes sense. Imho, this is such a case.



> It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time.

Those are things that make it better for the library maintainers, sure, but presenting (and documenting) an API that is idiomatic, both in structure and behavior, for the host language is better for library consumers, as it doesn't force them to context switch between the idioms of the host language and the idioms of the foreign library.


Agree with having a pythonic API.

There are already examples in the "Hello Qt" which are easily solvable:

  app = QApplication([])
  # should read instead:
  app = QApplication()
where the empty list is the default argument. Also

  app.exec_()
  # should be instead
  app.exec()
as it is also in the C++ API.

These small things make the difference.


`exec` is a python built-in (in py3, it was a keyword in py2). Variables that would clash names with keywords / built-is are conventionally followed by an _, so `exec_` is expected.

I agree on your first example.


exec is a reserved keyword in Python. The _ is there because the code wouldn't "compile" otherwise.


Parent was taking about PEP8, which is purely syntactic. I would argue that has very little to do with structure and behaviour. It's completely superficial.


Syntax is an element of structure. But, yes, I was going beyond the upthread comment.


Well, if code readability is superficial to you, you are probably not the target group of Python I guess. For Python users, readability, however, is very important.


No it really is not. You are defending Qt's decision to keep their own lives simple. That's fine for Qt, but not so for their target Python audience.

Generating similar high quality docs for the Pythonic wrapper should not be a issue.

Isn't the point that you don't have to translate in your head all the time. For non-Pythonic, non pep8 code you are going to do that constantly, not only when you read the Qt docs.

pep8 is a subset of 'Pythonic', the current wrappers are not only not pep8 compliant, they are also un-Pythonic in other ways.

Don't get me wrong, I appreciate Qt trying to expand their user base, but I would consider this effort a early milestone on the road to something that really fits into the Python ecosystem.


The Python standard library itself also breaks the PEP8 naming convention in all the ways PyQt does so their decision really makes sense. If Python itself were consistent the trade-off would be different...

I find PyQt to be Pythonic in all the ways that count, e.g. replacing `self.setFoo(bar)` with `self.foo = bar`, decorators for signals/slots, etc.


It does? Which library?


Unfortunately, a few library modules that predate PEP 8 and that never made the switch still use camel case, such as `unittest` and a few others. Bugs the hell out of me, as do libraries that have no excuse for their lack of compliance with PEP 8, such as PySide.


logging for instance.

    import logging
    logger = logging.getLogger()
    logger.setLevel(logging.DEBUG)
    logger.addHandler(...)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: