Как вы вообще разрабатываете на питоне?

Согласен, для мелочи пистон рулит.

А переменные начинать с $ или ; в конце строки это нормально

Потому что нормальные люди пишут программы печатными символами, а не пробелами

Развели тут бюрократию. Для автора - ответ простой:

1. либо скрипты запуска в корне репозитория, а в подкаталогах - пакеты и тогда (будь готов устанавливать своим Makefile/скриптом, или тупо копированием всего каталога project):

project/
├── my_script.py
└── pkg
    ├── __init__.py
    └── mod1.py

2. либо всё как в документации по setup.py (setuptools, distutils):

project/
├── bin
│   └── my_script.py
├── pkg
│   ├── __init__.py
│   └── mod1.py
└── setup.py

тогда для разработки нужно python setup.py develop / pip install -e, и для продакшна можно собирать всё в пакет с помощью python setup.py sdist.

Внутри скрипта my_script.py импортируешь как import pkg.mod1 (можно оставить __init__.py пустым), или просто import pkg (если в __init__.py тоже есть код).

В обоих случаях, желательно всё делать внутри virtualenv (либо голый virtualenv, либо pipenv).

Но оба случая - жуткий головняк в разработке и деплое, по сравнению с golang.

Спасибо вам за компетентный и точный ответ по существу. Возникали такие же вопросы как у автора. Ушел читать про setup.py.

А я не понимаю как так вышло, что все вышеотписавшиеся не знали про -m. Предлагали менять sys.path или юзать ipython

питон сильно овасяннился. причина в том, что проще портировать с питона 2 на го, чем с питона 2 на питон 3. этим люди и занимались в последнее время, после того как питон, как язык, начали ломать (в новостях: «чинить»).

Вас почитать, так складывается впечатление, что питон вообще не нужен: все свалили на го

Да. И тебе советуют. Goша быстро учится.

Зачем такие костыли, если есть require_relative?

Что, и библиотек так же много? Неужели аналог numpy, scipy, matplotlib появился?

А что из перечисленного требуется ТС? Вроде бы он просто скрипты пописывает. Так пускай его скрипты работают шустро.

Эх. А ведь еще совсем недавно электоральное большинство визжало «где дженерики??» и «старые пердуны в 2k17 родили сишку с GC - не взлетит! Rust (или C++ 2038) всех порешает!»

фишка в том, что го - это хороший язык для написания бэкендов. т.е. того, для чего использовался питон. за исключением того, что го - это компилируемый язык не страдающий утиной типизацией, компилирующийся в нативный код и, как следствие, оптимизированый нативный код.

с теми задачами с которыми хорошо справлялся питон (бэкенды) он справляется лучше. на нём тоже можно написать веб-сервер в пять строк, но это будет нативный веб-сервер с быстрым нетворкингом, а не с GIL как в питоне. с другой стороны, питон 3 не предлагает никаких особых преимуществ по стравнению с питон 2. многие люди сделали выводы.

если тебе скрипты надо писать - пиши лучше на шеле. питон 3 очень неудобный язык. да, u"" больше не надо писать, а можно писать «» без u, но работа с бинарными данными - это мрак и ужас, теперь надо писать в 10 раз больше. питон - это всё ещё неплохой язычёк для начинающих, но к сожалению не тьюринг-полный. не могу советовать на нём что-то делать, они через год питон 4 начнут пилить и опять всё надо будет портировать. лучше что-нибудь другое возьми.

numpy, scipy, matplotlib

да-да. а 3/2 должно быть равно 1.5, а не 1. язык программирования для математиков, а не для программистов, в этом и проблема.

p.s. можешь не завывать про //, лучше попробуй предложить такой же оператор в джаве, джаваскрипте, си или с++.

ведь еще совсем недавно электоральное большинство визжало «где дженерики??»

В скриптах? Лол.

если тебе скрипты надо писать - пиши лучше на шеле. питон 3 очень неудобный язык. да, u"" больше не надо писать, а можно писать «» без u, но работа с бинарными данными - это мрак и ужас, теперь надо писать в 10 раз больше. питон - это всё ещё неплохой язычёк для начинающих, но к сожалению не тьюринг-полный. не могу советовать на нём что-то делать, они через год питон 4 начнут пилить и опять всё надо будет портировать. лучше что-нибудь другое возьми.

Надо же, сколько вранья в одном абзаце.

Вас почитать, так складывается впечатление, что питон вообще не нужен: все свалили на го

Ну да, кому нужен динамический язык, который вполпинка заменяется на «сишку с GC». Разве что чучоным из-за либ, но там особая атмосфера, там и фортран с паскалем живы.

да, алан тьюринг - был великим человеком, сколько уже лет прошло, а кое у кого до сих пор подбамбливает от упоминания его фамилии. передавай привет гвидо, мы все надеемся, что запланированая вечеринка по случаю смерти (!!!) питона 2 выдастся очень годной и от похорон останутся только положительные впечатления.

хороший язык для написания бэкендов... на нём можно написать веб-сервер в пять строк

Хороший - это PHP. Ничего не далаешь, а всё есть. Питон с джангой похуже, но тоже ничего. В го вроде как еще не определились кто здесь самый главный фреймворк. Веб-вервер в 5 строк никому даром не сдался

но работа с бинарными данными - это мрак и ужас, теперь надо писать в 10 раз больше

Совсем недавно не имея опыта с питоном переделал проект на тройку. Как оказалось, все не так уж и плохо. Основные правки:

data = '123' # py2 bytestring
data = b'123' # py3 bytestring

data[0] # py2 bytechar slice
data[0:1] # py3 bytechar slice

# bytechar to number
ord(data[0]) # py2
data[0] # py3

# number to bytechar
chr(data[0]) # py2
bytes([data[0]]) # py3

# py2 bytechar iteration
for i in data: # py2
  type(i) # bytechar in py2
#py3 convert number to bytechar
for i in data: # py3
  i = bytes([i])
  type(i)

# integer division (if any)
data[0] / 8 # py2
data[1] // 8 # py3

Ну да, кому нужен динамический язык

Стыжно признаться, но мне динамика больше по душе. Когда я вижу декларации типов с парочкой вложенных <> - у меня мозг отключается.

И питоновский синтаксис нравится больше, чем c-style. Выглядит чище, эстетичнее. Но это, конечно, вкусовщина

(Всё это, конечно, не оправдывает GIL и в 60 раз более худшую производительность)

Эх. А ведь еще совсем недавно электоральное большинство визжало «где дженерики??» и «старые пердуны в 2k17 родили сишку с GC - не взлетит! Rust (или C++ 2038) всех порешает!»

Ни Раст, ни Си++ не могут конкурировать с Го как замена Питона для того же скриптования.

Компилируемый язык с явной декларацией типов это вообще странный выбор для скриптования

Имей в виду, Хлебушка хлебом не корми, дай потроллить питон, Раст и Файерфокс.

Да пущай. Жалко чтоли

теперь попробуй написать что-то сложнее hello world. допустим данные приходят из stdin, но это не текстовые данные, а бинарные. добавь к ним строку и выведи в stdout тоже в виде бинарных данных. представь что ты делаешь

cat data.bin | ./myshit.py "append this string" >data_appended.bin

потом напиши тоже самое на с++11 и сравни на чём было сделать проще.

в питоне есть ;

for i in range(10):
     if i: print(1); break;

Валидный код. Но говнокод.

в одну строку писать не обязательно тоже, внутри скобочек можешь использовать переносы строк. Ещё есть \

x = \
33

class Foo:
    ree = BlaBla(
                 foo='z',
                 bar='b'
          )

Раст решил не троллить пока. Обдумываю какую бы задачу для него найти, чтобы прочувствовать грабли. Язык то нормальный в основном, только местами синтакс в стиле «кот на клавиатуре». Ну я на перле же писал, и ниче, почти здоров.

GIL вообще не проблема, если ты не пишешь на питоне многопоточные числодробилки, а если ты их пишешь - ты явно выбрал не тот язык.

Язык то нормальный в основном

Твоя болезнь прогрессирует. БЕГИ!!!1111

Компилируемый язык с явной декларацией типов это вообще странный выбор для скриптования

Всяко лучше питона, если ты пишешь не только для себя. Скрипт наверняка будет работать, а не срать стектрейсами. К тому же в го можно ослабить типизацию, и дженерики там таки есть встроенные. Всего этого вполне достаточно для написания утилит. Как там со строками правда я не очень в курсе.

# integer division (if any)
data[0] / 8 # py2
data[1] // 8 # py3

только до тех пор пока делится не какой-нибудь x приходящий как аргумент функции, который до этого питон преобразовал в число с плавающей запятой и применение оператора >> на него будет выдавать красивый стек-трейс по воскресеньям, когда интерпретатор питона решится зайти в эту ветку кода.

арифметика целых чисел и арифметика чисел с плавающей запятой - это разные вещи. 3/2 эквивалентно 3>>1, результат обеих операций равен 1 (единице). не 0.999999, не 1.000001, и тем более не 1.5, а ровно единице.

также как результат деления на единицу должен всегда возвращать тоже самое число, не важно целое или с плавающей запятой. деление на единицу не меняет делимое:

>>> 1/1
1.0

питон поломан.

3/2 выдаст 1 в pyton 2.x, в 3.x вернёт 1.5, а // - оператор целочисленного деления. К чему твои завывания непонятно. Ты считаешь, что кого-то должно волновать, что ты не знаешь синтаксис языка и его операторы и что кто-то должен что-то тебе предлагать из-за того, что ты не можешь чем-то пользоваться. В этом то и проблема.

А разве GIL не помешает многопоточным обслуживателям сокетов и БД раскрыть потенциал многоядерных процессоров?

не знаешь синтаксис языка и его операторы

А ниче, что такое микроскопическое изменение синтаксиса поломало вообще всё? В итоге второй питон до сих пор дистры тянут, а он ведь скоро рипнется. Немножко высокая цена за удобную арифметику, правильный принт и блатные строки, не?

На код завязанный на io он особо не виляет. Сишные библиотеки тоже. Плюс однопоточные программы работают быстрее.

Да и никто не машет тебе обмазаться asyncio, несколькими процессами, а лучше и тем и другим.

Кстати, в jython, ironpython и т.п. gil нет. И были реализации cpython без gil, но они медленней чем обычный.

Ну а что поделать? Shit happens и то, в данном случае, это не так уж страшно.

Скоро это в 2020 году? И до сих пор никто к этому никак не готовится?

Напомню, что gstreamer 0.10 не поддерживается с 2012 года и до сих пор прекрасно продолжает проживать в дистрибутивах. Да и в 2020 году python2 никуда сразу не исчезнет скорее всего.

Обдумываю какую бы задачу для него найти, чтобы прочувствовать грабли.

Любую. Вот тебе навскидку искусственная задачка:

Опиши структуру Foo с полем bar, в котором хранится строковый срез &str. Добавь блок impl (пустой) для структуры Foo. Расскажи, в чём смысл этой задачи.

Намекаешь, что грабли начинаются уже в хелловорлде? Это вот ты сам придумал, или это вопрос из ЕГЭ?

Ещё не знаю как с делением и строками, но новый printf можно и в python2 использовать посредством import from future.

Намекаешь, что грабли начинаются уже в хелловорлде?

Ты напиши, увидишь)

ЕГЭ

Есть ЕГЭ по Rust?

А ведь и точно! Век живи - век учись.

Заменил везде:

require File.expand_path('../utils.rb',  __FILE__)

на:

require_relative 'utils.rb'

Стало короче, но Geany (и LOR-code, кстати, тоже) не выделяет ключевое слово.

Зато, судя по описанию, «require_relative» работает быстрее, т.к. не шерстит по путям, как «require».

p.s. И здесь Ruby снова показал себя красивее, практичней и продуманнее, чем Python со своим нагромождением костылей.

Да и никто не машет тебе обмазаться asyncio, несколькими процессами, а лучше и тем и другим

Морально готовлюсь к такому обмазыванию

Это намного проще и удобней, чем треды(со всеми их гонками, локами, дедлоками и прочими прелестями).

Насколько я понимаю, если делать несколько тредов, в каждом из которых по ивентлупу, то от локов и гонок никуда не деться

Почему не сделать несколько процессов? Если надо обмениваться данными между ними(обычно не очень) есть куча механизмов.

uwsgi --processes

А asyncio умеет распараллеливаться на несколько процессоров? Вроде бы нет, так что тоже не панацея. Процессоров нынче много в компьютерах, хочется использовать.

Если надо обмениваться данными между ними(обычно не очень)

Как это не очень. Синхронизация стейта нужна всегда.Тот самый момент, когда начинают на пустом месте городить redis, celery, ZMQ, микросервисы или обмен через БД. ИМХО это всё имеет смысл только когда система переросла 1 сервер. Если же надо просто бек, который загрузит все ядра, то ничего лучше глобальных переменных не найти.. И вот тут GIL вставляет палки в колеса

Есть https://docs.python.org/3/library/concurrent.futures.html#processpoolexecutor...

У большинства веб и подобных приложений нет общего стейта, они работают с бд или другими сервисами. Так что можно сделать несколько процессов и балансировщик между ними. Даже nginx может. И эти процессы могут быть на разных серверах. Подпроцессы можно запускать в неблокирующем режиме. Например я так запускаю imagemagick и ffmpeg, чтобы генерить превьюшки.

См. выше. В большинстве случаев у тебя будет не один сервер. Стейт между вообще всеми пользователями редко общий нужен, если это не бд и подобное. Например, я делал игру на вебсокетах, там игроки в разных комнатах висят в разных процессах. Между ними стейт общий, но между вообще вмести игроками в этом смысла нет.

В большинстве случаев у тебя будет не один сервер

До таких объемов надо еще дорости. Хотя да, с питоном необходимость масштабирования наступит в 45 раз быстрее :)