import datetime
from typing import Union
def foo(start_date: Union[datetime.date, str]) -> datetime.date:
if isinstance(start_date, str):
start_date = datetime.datetime.strptime(start_date, '%Y.%m.%d')
if isinstance(start_date, int):
raise RuntimeError('Invalid argument type')
return start_date
print(foo('2018.12.12'))
print(foo(datetime.datetime.now()))
print(foo(1))
Хотя тип int не объявлен в сигнатуре. А работает оно потому, что аннотации никак на выполнение не влияют. Вы можете в них что угодно прописать, там можно будет любой тип передать.
> Во-первых, хочу напомнить, что в питоне сильная типизация. Если Вы ожидаете в методе строку, вы не можете передать туда дату и надеяться, что все будет работать
Вы не правы) Вот этот код прекрасно работает
import datetime
from typing import Union
def foo(start_date: Union[datetime.date, str]) -> datetime.date:
if isinstance(start_date, str):
start_date = datetime.datetime.strptime(start_date, '%Y.%m.%d')
return start_date
print(foo('2018.12.12'))
print(foo(datetime.datetime.now()))
> 2. У вас есть функция, принимающая в качестве аргумент объект Date или целое число (timestamp) или строку ('2019.01.01') какой тип выберете.
Если у вас реально возникает такая необходимость, в питоне это решается объявлением списка типов, которые может иметь аргумент.
def foo(arg: Union[date, str]):
...
Подозреваю, что в JS/TS такой возможности нет, и это печально. Но это не проблема аннотации типов, а проблема реализации в конкретном языке.
> Упс интерфейсов тоже не завезли
Интерфейсы обычно используются, чтобы внести понимание, как можно с этим объектом работать и какие методы он имеет. В питоне для этого можно использовать абстрактные классы, либо те же тайпинги
Тут мы и объявили интерфейс SomeInterface и он уже выступает в качестве типа для тайпчекинга. Опять же, если в JS/TS или что вы используете в работе, такой возможности нет, это проблема конкретной реализации. В питоне это сделано грамотно и вызывает только положительные чувства и никем не навязывается.
Описание типов позволяет писать более понятный код и выловить ошибки при передаче неправильных параметров сразу на этапе написания кода, а не при прогоне тестов, или, что ещё хуже, на рабочем боксе.
Вы видимо, пишите его один раз и больше не меняете. Ну и работаете наверное с этим кодом один. При долгосрочной поддержке и командной работе с кодом такоц подход допустим только на этапе PoC или прототипа.
Я думаю, имелось ввиду, что человек заваливал кандидатов на тех интервью, а hr не могут брать кандидата, если он не прошел тех интервью. По сути, он принял решение о найме
А в программном плане что используете в качестве NAS? А то я со станционарника на FreeNAS хочу на такую вот или похожую плату переехать, но систему менять не хочется. Насколько я знаю, FreeNAS, который на FreeBSD, под арм работать не будет. Вот и интересуюсь.
"Вполне справляется" и "приятно пользоваться" — это разные вещи. У нас тоже справляется, но если у меня есть возможность лишний раз не запускать его на мобильнике, я с облегчением не буду этого делать. В отличие от того же телеграмма, когда там и запуск быстрее, и интерфейс намного отзывчивее и выглядит не как веб страница, и текст можно выделить и скопировать частями, а не все сообщение без возможности выделения.
Основной вопрос в том, какого качества получается этот "весь стэк". Сравните телеграм и слак для Андроид. Разница не то, что очевидна, слака прям плакать хочется. А альтернативы нет, поскольку корпоративный мессенджер. На том и играют. А пользователи страдают. По мне, так лучше качественный софт, чем тормознутый монстр
Знание теории не отменяет необходимости наличиеэя острого ума и умения решать практические задачи. Бывает такое, что человек на хорошо знает все эти алгоритмы и умеет определять сложность, но простые задачи на подумать и в уме просто построить алгоритм решения этой самой простой задачи уже не может.
По опыту паттерн "и швец, и жнец, и на на дуде игрец" приводит к тому, что человек знает всего понемногу, но не особого глубого. Как правило, инженер из него со временем станет так себе, коллеги-инженеры уйдут далёко вперёд, потому что все время тратят на профильные задачи, а не часть, как такой ТАМ. Но, как я понимаю, это и есть основная задача на данной позиций: понимать немного в инженерии и все остальное — работа с клиентами.
Так час работает веб версия телеграма. Однако, работает это все очень печально по сравнению с нативными приложениями. Например, уведомления приходят очень странно, причем от хрома, а не от приложения, иногда текст уведомления отображаться, иногда просто пишет, что есть какое-то уведомление, но что там такое, будьте добры зайти и посмотреть, показать не могу почему-то. Ну и не всегда приложение открывается на нужном месте по клику на самом уведомлении. В общем, сыро как-то
TS может сказать, что у нас будет отдельный модификатор для приватного поля, но мы поддерживаем и синтаксис js, однако рекомендуем использовать нормальный подход, который предоставляем мы. Я бы использовал их вариант.
Заменяете приватное свойство соглашением. Так уже давно используют нижнее подчеркивание. Мало того, что оно решает проблему (используешь приватные свойства — ССЗБ, разработчик кода не гарантирует совместимость). Так ещё и помогают, когда нужно поменять что-то в сторонней библиотеке, а нормальной возможности это сделать нет. Тогда на свой страх и риск. Но зато возможность есть, а это лучше ее отсутствия.
Вы явно объявляете свойство при объявлении класса. Не совсем понимаю, какие тут проблемы могут быть, если вы явно свойство объявили. Я так же не понимаю, чем объявление приватного свойства с префиксом с точки зрения реализации концептуально отличается от объявления с ключевым словом.
Вот так просто, и без необходимости разбираться с горой новый инструментов, можно собрать фронт.
Ну как минимум с gradle и kotlin/groovy разобраться придется. Бэк не джавой единой живёт, не все бэк разработчики пишут на ней и не все бэки реализованы на джаве. Я бы озаглавил статью вроде "Frontend для Java Backend девелопера", так будет честнее что-ли)
Вот это работает прекрасно
Хотя тип int не объявлен в сигнатуре. А работает оно потому, что аннотации никак на выполнение не влияют. Вы можете в них что угодно прописать, там можно будет любой тип передать.
Вы не правы) Вот этот код прекрасно работает
Если у вас реально возникает такая необходимость, в питоне это решается объявлением списка типов, которые может иметь аргумент.
Подозреваю, что в JS/TS такой возможности нет, и это печально. Но это не проблема аннотации типов, а проблема реализации в конкретном языке.
> Упс интерфейсов тоже не завезли
Интерфейсы обычно используются, чтобы внести понимание, как можно с этим объектом работать и какие методы он имеет. В питоне для этого можно использовать абстрактные классы, либо те же тайпинги
Тут мы и объявили интерфейс SomeInterface и он уже выступает в качестве типа для тайпчекинга. Опять же, если в JS/TS или что вы используете в работе, такой возможности нет, это проблема конкретной реализации. В питоне это сделано грамотно и вызывает только положительные чувства и никем не навязывается.
Описание типов позволяет писать более понятный код и выловить ошибки при передаче неправильных параметров сразу на этапе написания кода, а не при прогоне тестов, или, что ещё хуже, на рабочем боксе.
Вы видимо, пишите его один раз и больше не меняете. Ну и работаете наверное с этим кодом один. При долгосрочной поддержке и командной работе с кодом такоц подход допустим только на этапе PoC или прототипа.
Я думаю, имелось ввиду, что человек заваливал кандидатов на тех интервью, а hr не могут брать кандидата, если он не прошел тех интервью. По сути, он принял решение о найме
А в программном плане что используете в качестве NAS? А то я со станционарника на FreeNAS хочу на такую вот или похожую плату переехать, но систему менять не хочется. Насколько я знаю, FreeNAS, который на FreeBSD, под арм работать не будет. Вот и интересуюсь.
"Вполне справляется" и "приятно пользоваться" — это разные вещи. У нас тоже справляется, но если у меня есть возможность лишний раз не запускать его на мобильнике, я с облегчением не буду этого делать. В отличие от того же телеграмма, когда там и запуск быстрее, и интерфейс намного отзывчивее и выглядит не как веб страница, и текст можно выделить и скопировать частями, а не все сообщение без возможности выделения.
Основной вопрос в том, какого качества получается этот "весь стэк". Сравните телеграм и слак для Андроид. Разница не то, что очевидна, слака прям плакать хочется. А альтернативы нет, поскольку корпоративный мессенджер. На том и играют. А пользователи страдают. По мне, так лучше качественный софт, чем тормознутый монстр
Знание теории не отменяет необходимости наличиеэя острого ума и умения решать практические задачи. Бывает такое, что человек на хорошо знает все эти алгоритмы и умеет определять сложность, но простые задачи на подумать и в уме просто построить алгоритм решения этой самой простой задачи уже не может.
По опыту паттерн "и швец, и жнец, и на на дуде игрец" приводит к тому, что человек знает всего понемногу, но не особого глубого. Как правило, инженер из него со временем станет так себе, коллеги-инженеры уйдут далёко вперёд, потому что все время тратят на профильные задачи, а не часть, как такой ТАМ. Но, как я понимаю, это и есть основная задача на данной позиций: понимать немного в инженерии и все остальное — работа с клиентами.
Так час работает веб версия телеграма. Однако, работает это все очень печально по сравнению с нативными приложениями. Например, уведомления приходят очень странно, причем от хрома, а не от приложения, иногда текст уведомления отображаться, иногда просто пишет, что есть какое-то уведомление, но что там такое, будьте добры зайти и посмотреть, показать не могу почему-то. Ну и не всегда приложение открывается на нужном месте по клику на самом уведомлении. В общем, сыро как-то
Заменяете приватное свойство соглашением. Так уже давно используют нижнее подчеркивание. Мало того, что оно решает проблему (используешь приватные свойства — ССЗБ, разработчик кода не гарантирует совместимость). Так ещё и помогают, когда нужно поменять что-то в сторонней библиотеке, а нормальной возможности это сделать нет. Тогда на свой страх и риск. Но зато возможность есть, а это лучше ее отсутствия.
Вы явно объявляете свойство при объявлении класса. Не совсем понимаю, какие тут проблемы могут быть, если вы явно свойство объявили. Я так же не понимаю, чем объявление приватного свойства с префиксом с точки зрения реализации концептуально отличается от объявления с ключевым словом.
Ну как минимум с gradle и kotlin/groovy разобраться придется. Бэк не джавой единой живёт, не все бэк разработчики пишут на ней и не все бэки реализованы на джаве. Я бы озаглавил статью вроде "Frontend для Java Backend девелопера", так будет честнее что-ли)
Где-то и когда-то развитие языка свернуло явно не туда (
Мне одному кажется странным использование префикса вместо зарезервированного слова, как это сделано во всех остальных нормальных языках?
Думаю, тут проблема самого приложения, а не ОС. Скорее всего, это память занята данными, котики, видео и прочее.