3 ms·
Very interesting. I suspect we may even have worked for the same bank! I'd love to discover how we came to such opposing conclusions. To give you a Python ex
by tome 8y ago
Very interesting. I suspect we may even have worked for the same bank! I'd love to discover how we came to such opposing conclusions.
To give you a Python example, it encourages stuff like:
def send_email(recipients, contents):
if type(recipients) == str:
send_one_email(recipients, contents)
else:
for recipient in recipients:
send_one_email(recipient, contents)
That is a flavour of convenience that people commonly implement in Python. People like it because it allows both
send_email("tome", contents)
and
send_email(["tome", "mlthoughts2018"], contents)
and saves them from typing two square brackets. The problem is when you call
send_email(u"tome", contents)
It tries to email "t", "o", "m", and "e". This kind of stuff is endemic in Python. Yes, this did happen in practice in a company I worked for (a company that was responsible for trading hundreds of millions of dollars of securities every day). Call the programmers exceptionally bad if you like, but they were among the brightest minds graduating in my country. It was Python that allowed them to be sloppy.
- mlthoughts2018 8y agoI disagree very much. The Pythonic way would be to do something like map(send_email, list_of_addresses), and have send_email raise an exception if not passed precisely a single string, and presumable raise exceptions when you validate that the email address is of an acceptable format, etc. It would not be Pythonic to make the function superficially handle different arities of argument through explicit handling on the list type with isinstance, precisely because you’d need to handle different meanings of different types that implement the Iterator Protocol. That’s not something Python generally encourages, it’s just a mistaken implementation. And particularly not making careless assumptions when basing branches on isinstance behavior (for example, you could always encounter custom classes that have overridden __instancecheck__ or __subclasshook__ special methods.
- tome 8y agoIt's certainly a poor use of Python's flexibility, but I've seen that kind of thing written at two completely different companies by completely different, yet smart, people so I suspect it's prevalent. Haskell does a much better job of nudging smart people to write good code. Gabriel Gonzalez explained it better than I could: http://www.haskellforall.com/2016/04/worst-practices-should-be-hard.html http://www.haskellforall.com/2016/04/worst-practices-should-...
- olau 8y agoThis isn't really spaghetti code, though, it's a syntactic sugar optimization gone wrong due to the Python 2 str/unicode split. It's in the same league as people overloading operators in C++ to do silly things. While some people like to harp on that, I don't think those instances are prevalent enough to actually cause that many bugs. YMMV.