⬆️ ⬇️

The answer to Python vs Ruby

The user eyeofhell recently wrote a Python vs Ruby article.

Notable holivar turned out. I can not support. At first I thought to write in the comments - but the answer came out too voluminous.





About myself:

I have been writing on Python for more than ten years, with Ruby a rather superficial sign.

Recently, I am Python Core Developer with commit rights.



At the last US PyCon in Santa Clara, Guido van Rossum made a wonderful speech - I recommend everyone to watch it.

')

In particular, he indicated that Python and Ruby are almost twin brothers. The differences between them are much smaller than the opposition of these languages ​​to the rest.

Let's be friends, and not find out who is cooler.



Now on specific claims to the author (on the part of Python, of course - let the knowledgeable rubist also say a weighty word).



- Python has a built-in ssl module. Due to ancient licensing issues with Microsoft (correct, if not), this module is not included in the distribution for Windows. On all other OS it is.



- subprocess allows you to specify command line parameters in one line, and you should call it with the shell = True parameter. It's not as concise as just brackets - but there is a way. In addition, it should be understood that the call of a subprocess is not always reduced to the substitution of text output into a variable. There is also a return code, stderr, interactivity ...



- Python can import modules in a relative path. This is a relative path for modules, not files. Modules should be in packages (folders with __init__.py). Readers have already pointed out this moment.



- codecs.open allows you to specify the encoding for the file being opened. open supports the encoding parameter for the same purpose.



- good or not, but when using operating system threads there is no reliable way to destroy a thread. There is always a risk that the resources used are not released (memory, database connections and other sockets, etc.) Therefore, Python does not have this capability. It is necessary to send a message to the stream in one way or another, and there he himself must understand.



Other: as readers have already noted, some parts are not included in the Python distribution, but are available as third-party libraries.



- pytz. The timezone list is updated more often than the one and a half year period for the release of a new Python. The documentation links to pytz not - fix.



- template engine. More than string.Template in the standard delivery is not included. Because it is not clear which template would suit everyone. jinja2, which I use is a great thing. Again, developing too fast and too independent to be part of Python as a distribution.



A lot of useful things. But if the library is included in the Standard Python - it is obliged to maintain backward compatibility. Often it is too expensive and does not allow to develop quickly, releasing releases every three months and not once a year and a half, as Python does.



And finally, the main thing.

python2 is already dead. Yes, we often do bug-fixes. python2.7.3 will be soon. But the deuce ended two years ago.



More and more libraries are confirming their support for Troika.

- SQLAlchemy made it a long time ago.

- Jinga2 - too.

- Pyramid - a week ago.

- WebOb, on which Pyramid depended - at the end of last year.

- Django also goes to the top three - they promised.



Guys, Python3 is your future, which comes on the heels. Be ready!



UPD: Django 1.5, which will be released in the fall, will have experimental support for Python 3.3

Source: https://habr.com/ru/post/140939/



All Articles