Isn’t that already happening? I’ve seen countless suggestions getting rejected for such reasons.
Python has no such philosophy. Many people believe that it does, because of their interpretation of the line in the “Zen of Python”, but the Python core developers’ interpretation seems quite different. As expressed in PEP 584:
There is no [Only One Way] koan
There is no [more than one way to do it] prohibition
If you’re looking for a language that comes closer to your desired philosophy of “one way of doing things”, perhaps consider Go?
(my emphasis).
As a puzzle, expect to find golfing, obfuscations, and scarcely used /often misunderstood areas of Python..
@bluelobe, were there some instructions provided along with the code that you could share with us? We would like to know the details of the challenge that was being posed.
@bluelobe Would be good to share a link to the tweet.
x[::-1] and reversed(x) are similar, but they have some important differences. The first form preserves the type of the sequence and is thus convenient if you want, for example, reverse a string or a tuple:
>>> 'hello'[::-1]
'olleh'
>>> (1, 2, 3)[::-1]
(3, 2, 1)
If you use reversed(), you get a reversed object that you then need to convert yourself:
>>> reversed('hello')
<reversed object at 0x7f0d88933af0>
>>> ''.join(reversed('hello'))
'olleh'
>>> tuple(reversed((1, 2, 3)))
(3, 2, 1)
A benefit of reversed() is that it just iterates items from the end of sequence and doesn’t need to recreate the whole sequence in memory. This doesn’t matter with the above examples, but with large lists and other sequences the difference can be significant over using the slice notation.
In other words, there are use cases where x[::-1] works better and use cases where reversed(x) works better. In my opinion Python would be a poorer language if it only had one of them. I’m not sure is it necessary for reversed to be a built-in, but if it needed to be imported, many users would probably use the slice notation even in places where reversed would be better.
Not true already for lists. You get a list_reverseiterator object instead. But yes, an iterator in either case, and that has different features/advantages. Besides memory usage, it can also be a lot faster (for example to find the last index of a list element) and can be used by multiple consumers for shared iteration (like zip(it, it) to get pairs, or more elaborate cases that use the same iterator in several places, like those where the itertools docs call iter(...)).
True, but if you have other indexings all over your code like L[::-2], the most obvious way might be [::-1] over reversed, for the sake of unfoolish consistency. Note that the zen of python does not say “there MUST be…”.
A simple and easy solution is coming up with a universal Python Manual that’ll be used as a guide for good and preferred Python coding practices. Example: PHP: explode - Manual
That example looks similar to the Programming FAQ; perhaps that could be the answer?
Even being Dutch, it’s not always obvious, though.
There are many guides out there. Find one that you like, and use it. Or write one of your own. You can even get a group of people together and write one. The core team is not going to try to dictate how all Python code should be written. PEP 8 is a small part of a comprehensive guide, and even that doesn’t have universal acceptance.
I’m not sure why you linked to the PHP explode page. There are examples on that page and comments. The Python docs will not have comments on them, but lots of people would like more examples. You can contribute examples yourself if you like.
I don’t see how a fixed comprehensive guide to good practices could be written, given that we don’t know the future. New technologies will develop and they will change what the best practices are.
For example, pathlib is relatively new, not having history back to Python 2. Nowadays I make and use many APIs which accept pathlib.Path objects, and consider standardizing on that interface a good idea where possible. But before pathlib existed, we couldn’t possibly advise people to use it!
If you have trivially parallel problems, concurrent.futures is awesome! But we didn’t used to have that tool. Because it had to be invented first.
So if you want to write such a guide, you should plan to make it a living doc which gets updated as the world changes.
It may be a useful exercise to write. It’s certainly not a “simple and easy” one though.
One place that [::-1] is invaluable is in repl sessions. Sometimes I just want to slap a list into the terminal, type [::-1] at the end and immediately use the result somewhere else.
I’d also just consider it a side effect of how slices are implemented instead of an intended feature. If you can specify start, stop, and step you should as a consequence of that be able to step backwards though a list. Especially since negative indexing is common and allowed.
I refer to the official Python docs first, and sometimes to the PEPs to see how features were thought to be used when they were added. I’d say follow more than one of the copious, up to date tutorials available and cross-check with the official Python docs.