Unnecessary underscore suffix for many arguments and attributes #234

Activity

1. wbolster

   changed the title [-]"id" is not a reserved word, so why use "id_" everywhere?[/-] [+]Unnecessary underscore suffix for many arguments and attributes[/+] on Nov 25, 2014
2. gtback commented on Nov 25, 2014

   

   gtback

   on Nov 25, 2014

   Contributor

   More actions

   Thanks, @wbolster . This is something I'd like to consider the next time we do a major refactoring of the library (perhaps for the next major release of the language).

   I was initially opposed to having attributes with the same name as Python builtins (particularly ones that actually get used in the same code, such as object and type). In addition, it has the potential to make syntax highlighters confused, which can in turn confuse programmers. Since then, I've seen more occasions where libraries use (e.g.) id as an attribute/kwarg, so "overriding" the builtin may not be as bad of an idea as I initially thought.

   I'm curious to hear what other people think. Does anyone know of examples (popular Python libraries) where the "trailing _" strategy is vs. is not used?

   Regardless, I don't think we'll want to change it until a major release. The backward compatibility issues would be enormous.
3. gtback commented on Nov 25, 2014

   

   gtback

   on Nov 25, 2014

   Contributor

   More actions

   My initial confusion was caused by mentally substituting "built-in" for "keyword" in PEP8.

   single_trailing_underscore_ : used by convention to avoid conflicts with Python keyword, e.g.

   I'll take the blame 100% for this.
4. wbolster commented on Nov 25, 2014

   

   wbolster

   on Nov 25, 2014

   Author

   More actions

   Thanks. Trailing underscores are a necessary evil for things like class_ (prefer cls) and from_ (e.g. in an email api), but built-ins can be overridden. It allows nice APIs at the cost of a bit of careful coding inside the library,. e.g. alias builtin_type = type when using both a type=... arg and the type() built-in.

   That said, do you have any other "big picture" ideas for a future version?
5. wbolster commented on Nov 25, 2014

   

   wbolster

   on Nov 25, 2014

   Author

   More actions

   Re. example code: all Pythonic code has nice APIs of course! :) For example, it's very common to have a id field on SQLAlchemy models. An example for a type arg in the stdlib (among many others): https://docs.python.org/3/library/mimetypes.html#mimetypes.guess_extension
6. gtback commented on Dec 1, 2014

   

   gtback

   on Dec 1, 2014

   Contributor

   More actions

   Thanks, @wbolster. My other long-term goals are primarily to get rid of the "bindings" (stix.bindings) in favor of some more-Pythonic and easier-to-maintain alternative, and also adding support for Python 3. The former should make the latter much easier.
7. wbolster commented on Dec 1, 2014

   

   wbolster

   on Dec 1, 2014

   Author

   More actions

   Have you considered PyXB instead of generateDS?
8. wbolster commented on Dec 1, 2014

   

   wbolster

   on Dec 1, 2014

   Author

   More actions

   In the mean time, it would be nice if you could document (maybe just a README in the bindings/ directory would suffice) the process of (re)generating the bindings.
9. bworrell commented on Dec 1, 2014

   

   bworrell

   on Dec 1, 2014

   Contributor

   More actions

   @wbolster, we looked at PyXB when we started python-cybox development and unfortunately it wasn't able to process the CybOX schemas, so we went with generateDS.