Можно чуть поподробнее, зачем нужно подбирать пояс по короткому имени? Мне правда интересно.
Мы в календаре столько настрадались со всеми этими названиями и сокращениями таймзон. Так, например, MS Outlook в разное время, в разных версиях и в разных локализациях ОС выдаёт таймзоны вида:
— (GMT+03.00) Moscow / St. Petersburg / Volgograd
— (GMT+04.00) Moscow / St. Petersburg / Volgograd
— (UTC+04.00) Moscow / St. Petersburg / Volgograd
— (UTC+04:00) Волгоград, Москва, Санкт-Петербург
— Волгоград, Москва, Санкт-Петербург
— Moscow, St. Petersburg, Volgograd
— Russian Standard Time
— Russian
И ещё огромную кучу других вариантов. Поди потом найди соответствие нужному часовому поясу и разберись, что же этот аутлук имел в виду. А если всмомнить ещё про проблему с переводом часов в Windows — вообще за голову хватаешься.
Я не знаю, что конкретно имел в виду автор, но, по всей видимости, он говорил о «Riyadh Solar Time». В Саудовской Аравии с 1987 по 1989 годы пытались использовать эту таймзону, но потом отказались.
536 of the Olsen timezones are supported. The missing few are for
Riyadh Solar Time in 1987, 1988 and 1989. As Saudi Arabia gave up
trying to cope with their timezone definition, I see no reason
to complicate my code further to cope with them. (I understand
the intention was to set sunset to 0:00 local time, the start of the
Islamic day. In the best case caused the DST offset to change daily
and worst case caused the DST offset to change each instant depending
on how you interpreted the ruling.)
Вот первая ссылка с правилами перехода, которую я нашёл (не ручаюсь за её достоверность): gist.github.com/NZKoz/5259788
MyPy — просто левый проект, PEP — просто рекомендации. Это понятно и так :)
Pylint, конечно, хорошо, однако не панацея ни разу. Да, часть проблем (в основном, результат обычной невнимательности) он решает, однако взамен он привносит огромное количество геморроя. Вариант с явной или статической типизацией ведь всегда будет лучше, чем гадание на кофейной гуще, коей является pylint?
Другое дело, что не существует общепринятого стандарта, ну и докстринги — они ни на что не влияют в чистом Python, это просто документация для разработчика.
Я никогда не думал, что в Python так много спорных мест, однако же конструктивная критика Армина позволяет трезво взглянуть на вещи со стороны. К сожалению, я уже позабыл всё то, что когда-то знал про PHP, поэтому не могу оценить его или Ruby. Что касается JS, автор его «любит»: lucumr.pocoo.org/2013/12/9/stop-being-clever/ =)
Вообще, речь в статье именно про Python. А можно я просто отвечу цитатой из статьи?
Например, объекты datetime, в общем случае, можно сравнивать с другими объектами. Но если вы хотите сравнить два объекта datetime друг с другом, то это можно сделать только в случае совместимости их таймзон.
То есть того времени, которое я потратил на перевод недостаточно, нужно ещё персонально вам ответить на все те вопросы, которые возникли после того, как вы не прочитали перевод, с учётом того факта, что ответы на все эти вопросы есть в статье? Ну давайте, чего уж там, мне всё равно в два часа ночи перед началом рабочей недели делать нечего. Всегда мечтал побыть в шкуре репетитора :)
Повторите, пожалуйста, ещё раз второй (главный) вопрос? Мне почему-то показалось, что я на всё ответил.
Мне всегда казалось, что для того, чтобы участвовать в дискуссии вокруг какой-либо статьи и вести конструктивный диалог, первым делом неплохо было бы прочитать эту самую статью. Иначе получается разговор ни о чём. Без обид и ничего личного :)
Отвечаю на вопрос: да. Собственно, примерно обо всём об этом и написана (и переведена) статья.
С местом про C++ и статическую типизацию с дальнейшим переходом на описание автотипов согласен, можно придраться, хотя стоит ли? :)
А вот про Python и явную типизацию не соглашусь — там всё правильно написано. Обсуждалась статическая типизация, да, а в итоге предлагают реализовать явную (и MyPy и PEP-3107), там так и написано же, разве нет?
Автор так и пишет, например, что auto C++ — неявная статическая типизация. Да и у меня в переводе, вроде, так и написано. Если я где-то ошибся, прошу поправить.
С явной/неявной типизацией не всё так просто и однозначно, хорошие примеры есть в статье.
Проблема несколько глубже, проблема не в классификации языка по системам типизации (тут всё просто), а в особенностях (читать как «недостатках») существующей реализации Python. Статья, по большей части, об этом.
Совершенно согласен, и ведь многие вещи сам замечал, но просто проходил мимо, считая, что «так и надо», и исходники CPython изучал. Глаз замыливается, увы. А такие статьи заставляют задуматься и расти в профессиональном плане =)
Парни, спасибо за комментарии. Никакого конструктива я не увидел, и поэтому лично я пас.
Это не официальная позиция компании, просто лично мне надоело кормить троллей и получать сплошной негатив и минусы. Я тут никому ничего не должен и мог бы просто всё проигнорировать и никому не отвечать с тем же результатом, однако искренне надеялся на конструктивный диалог. Забыл, что я в интернете, а это вовсе не бложек друзей.
Мы в календаре столько настрадались со всеми этими названиями и сокращениями таймзон. Так, например, MS Outlook в разное время, в разных версиях и в разных локализациях ОС выдаёт таймзоны вида:
— (GMT+03.00) Moscow / St. Petersburg / Volgograd
— (GMT+04.00) Moscow / St. Petersburg / Volgograd
— (UTC+04.00) Moscow / St. Petersburg / Volgograd
— (UTC+04:00) Волгоград, Москва, Санкт-Петербург
— Волгоград, Москва, Санкт-Петербург
— Moscow, St. Petersburg, Volgograd
— Russian Standard Time
— Russian
И ещё огромную кучу других вариантов. Поди потом найди соответствие нужному часовому поясу и разберись, что же этот аутлук имел в виду. А если всмомнить ещё про проблему с переводом часов в Windows — вообще за голову хватаешься.
Вот цитата из рассылки о pytz (оригинал тут: http://mm.icann.org/pipermail/tz/2004-June/012495.html):
Вот первая ссылка с правилами перехода, которую я нашёл (не ручаюсь за её достоверность): gist.github.com/NZKoz/5259788
И ещё интересная ссылка с чуть более подробным описанием: blogs.kde.org/2005/11/25/timezones-and-experiment
Pylint, конечно, хорошо, однако не панацея ни разу. Да, часть проблем (в основном, результат обычной невнимательности) он решает, однако взамен он привносит огромное количество геморроя. Вариант с явной или статической типизацией ведь всегда будет лучше, чем гадание на кофейной гуще, коей является pylint?
Другое дело, что не существует общепринятого стандарта, ну и докстринги — они ни на что не влияют в чистом Python, это просто документация для разработчика.
Повторите, пожалуйста, ещё раз второй (главный) вопрос? Мне почему-то показалось, что я на всё ответил.
Отвечаю на вопрос: да. Собственно, примерно обо всём об этом и написана (и переведена) статья.
А вот про Python и явную типизацию не соглашусь — там всё правильно написано. Обсуждалась статическая типизация, да, а в итоге предлагают реализовать явную (и MyPy и PEP-3107), там так и написано же, разве нет?
— www.mypy-lang.org/
— legacy.python.org/dev/peps/pep-3107/
На практике всё не так радужно.
Проблема несколько глубже, проблема не в классификации языка по системам типизации (тут всё просто), а в особенностях (читать как «недостатках») существующей реализации Python. Статья, по большей части, об этом.
Это не официальная позиция компании, просто лично мне надоело кормить троллей и получать сплошной негатив и минусы. Я тут никому ничего не должен и мог бы просто всё проигнорировать и никому не отвечать с тем же результатом, однако искренне надеялся на конструктивный диалог. Забыл, что я в интернете, а это вовсе не бложек друзей.
Всем хороших выходных!
И да, «сходил в карму» на всякий случай (лично от себя и с превеликим удовольствием), однако там уже :)