Это не «пхп-среда», это апач-среда. Если у тебя не завёлся handler, apache будет показывать все файлы в document root. В том числе питонячьи

каким образом они туда попадут? никто не выкладывает python или ruby или подобное в document root веб-сервера. и, наоборот, для php это способ, который используется в 99%.

у меня веб-сервер вообще не видит ничего вне /var/www, чисто физически. и все python-приложения у меня в /home/*, как они попадут туда, кому вообще в голову придёт положить python-файлы к веб-серверу?

Мда

Внезапно, если у тебя сдохнет php-fpm — ты тоже ничего не увидишь.

модель *как в php* применяется только в php.

Да ты совсем поехавший. Тебя лично разработчики PHP бьют по рукам, запрещая пользоваться php-fpm? Или ты про это не слышал никогда? Ну ничего, бывает.

php использует такую модель, а все остальные - другую

сегодня в программе:

- сколько еще человек скажут буратинке, что у него каша в голове?
- когда буратинка перестанет путать «модель» web-сервера и языка программирования?

в защиту дерева( беречь лес вызов 21 столетия) сказано:

есть модели «по лучше» так что когда дерево решает (читай от дерева зависит) какую модель выбрать то php модель выбирается в нуле случаев из всех.

где виноват именно php, а всё рассказывает про странные настройки сервера

Ты странный — хотеть какой-либо объективности от фанатика-хейтера.

Потому что перед кодом алгоритма нужно еще столько же декларировать.

никто не выкладывает python или ruby или подобное в document root веб-сервера

тогда расскажи нам куда ты положишь свой .py-файл при работе с апачем

кто его запускает?

кто угодно. юзер в tmux, tcpd, supervisor, uwsgi при старте сервиса

.htaccess может тоже не обрабатываться. по причине от смены сервера, до неподхватившегося конфига

какой ещё .htaccess в python? зачем???

в php 99% запросов делаются так - а ну-ка исполни мне, файл /1/2/3.php. то, что сервер может преобразовывать запросы через .htacsess, делая иллюзию, что там файлы лежат совсем иначе, ничего не отменяет - юзер по-прежнему обращается к php-файлам, лежащим на сервере, подаёт их на интерпретатор и тот их исполняет. так рабоатет всё, и если ты попытаешься заставить php-юзеров вместо этого городить какой-то огород, они плюнут и уйдут писать cgi-скрипты на perl, а не париться

в python у тебя есть run.py и куча импортируемых модулей. с файлами, файловой структурой или чем угодно они ВООБЩЕ никак не связаны, зачем им нужны костыли в виде .htaccess, если всё задаётся роутером самого приложения. они вообще никак не связаны с файлами на веб-сервере... и вполне могут располагаться на другом компьютере

пхп экосистема всёж(в лучшем случае была в худшем всё ещё есть) своеобразна и многие wtf ровно из того врождённого своеобразия всей экосистемы в которой пхп гордость ея

тогда расскажи нам куда ты положишь свой .py-файл при работе с апачем

какой .py файл? и зачем он мне? я его могу хоть exe-файлом назвать и запустить

вот что является, по твоей классификации, .py-файлом в django?

а кладу я их, понятное дело, в /home/*/appname или /srv/appname. запускаю через supervisord, мне так проще, чем через разные wsgi. статику в /var/www, но никакого python-кода там быть и не может даже близко :)

php использует такую модель

Ты путаешь причину и следствие. Это PHP чаще всего таким образом используют. Потому, что так проще. Нужно по другому - добро пожаловать в суровый энтерпрайз.

запускаю через supervisord

почему для описания запуска php ты рассказываешь про апач, а при описании запуска питона - неапач?

Ты странный — хотеть какой-либо объективности от фанатика-хейтера.

это уже клиника. если бы я написал *php начинается с p*, меня бы тоже туда записали.

вопрос был *за что не любят*, я и написал, что основное различие - такое-то. это и достоинство: не нужно запускать приложение, можно его просто на веб-сервер бросить в доступный каталог и всё, оно уже установлено. и это недостаток, я перечислил почему это недостаток и за что его не любят.

в ответ от нефанатиков нехейтеров началась натуральная истерика - НЕТ ЭТО НЕ ТАК ЭТО НЕ МЫ МЫ НЕ ВИНОВАТЫ! я вообще никого ни в чём не обвинял, просто указал на различия в подходе, без каких либо выводов, в конце написал, что в остальном без разницы php или python или ещё что-нибудь, это на любителя.

но нефанатики нехейтеры - они такие...

юзер по-прежнему обращается к php-файлам, лежащим на сервере

И как же юзер обратится к моему классу AdminController.php, который лежит вне докрута?

Ты путаешь причину и следствие. Это PHP чаще всего таким образом используют. Потому, что так проще.

круто. а я что сказал?

И как же юзер обратится к моему классу AdminController.php, который лежит вне докрута?

причём здесь это? то, что можно что-то делать, это не значит, что это общеупотребительная практика. можно и на visual basic cgi-скрипты писать, я лично писал :) но факт в том, что в php у тебя в 99% случаев будет набор php-скриптов, доступный для веб-сервера - достаточно слить любой тарбол и убедиться в этом

вот что является, по твоей классификации, .py-файлом в django?

в моей классификации весь django со всеми своими файлами является инопланетным куском говна. уж лучше рельсы взять, если php не нравится.

почему для описания запуска php ты рассказываешь про апач, а при описании запуска питона - неапач?

Если ставить в одни и те же условия — неудобно получится.

почему для описания запуска php ты рассказываешь про апач, а при описании запуска питона - неапач?

(зевая) потому что php использует одну модель исполнения, а python - другую, о чём я говорил в своём первом, в своём втором, и в своём каком угодно сообщении.

вроде дерево, а ведёт себя как шланг

потому что php использует одну модель исполнения, а python - другую

это не php использует, а Ты используешь :)

при чём здесь это? то, что можно что-то делать, это не значит, что это общеупотребительная практика.

В нормальных фреймворках это как раз общеупотребительно. В некоторых CMS тоже. Тот же opencart теперь рекомендует размещать /system выше докрута.

И, да, то, как использую язык — это не проблема языка. Не любить язык за то, что 99% его использующих — макаки — клиника.

потому что php использует одну модель исполнения,

Ещё раз: ты всё перепутал. Это PHP так используют. Тебе никто не мешает использовать fpm

это не php использует, а Ты используешь :)

это используют все php-проекты, которые я вижу. ну дай мне ссылку на проект, который использует php как-то иначе, а я посмотрю. покажи мне пример хоть одного хоть немного популярного php-проекта, который НЕ использует модель *что вижу, то и пою*

при этом у тебя полетит нахрен вообще вся php-экосистема, и в этом случае непонятно, зачем делать так именно на php, а не на чём угодно, включая C

то, что php заточен на это, говорит наличие .htaccess-файла в каждом втором php проекте. поэтому и настроить тот же owncloud/nextcloud в каждой новой версии под сервер не apache не так уж и тривиально. и такая ситуация со всеми популярными php-проектами.

Ещё раз: ты всё перепутал. Это PHP так используют. Тебе никто не мешает использовать fpm

и что меняет fpm? модель *что вижу, то и пою* от этого не меняется, только сложность настройки возрастает

Ещё раз: ты всё перепутал. Это PHP так используют. Тебе никто не мешает использовать fpm

разумеется, это php так используют. иначе он все свои преимущества и растеряет. винду тоже можно портировать на mips - только без всех своих legacy-приложений она там нахрен не нужна.

можно сделать php, где нельзя заливать сайты по ftp, нельзя использовать все популярные, ориентированные на apache приложения, и т.д. и т.п., только он тогда никому нахрен не будет нужен :)

поэтому php так используют, и дальше будут продолжать использовать - в этом его фишка и есть.

то, что php заточен на это, говорит наличие .htaccess-файла в каждом втором php проекте

Ты дурак? Да, пожалуй, так.

ну дай мне ссылку на проект, который использует php как-то иначе

если ты про размещение сорцов за пределами document root - yii и laravel на вскидку

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

еще раз, это не php использует, это Ты используешь :)

то, что php заточен на это, говорит наличие .htaccess-файла в каждом втором php проекте

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

в отличии от того же питона, который в web'e просто непопулярен :)

И, да, то, как использую язык — это не проблема языка. Не любить язык за то, что 99% его использующих — макаки — клиника.

причём здесь любить или не любить? если мне нужен nextcloud, а он мне нужен, я не вступаю в разговоры, а поднимаю апач на XXXX-порту, скармливаю ему директорию nextcloud и вывожу это уже на свой сервер. потому что nextcloud, написанного *иначе*, у меня нет. и ни у кого нет. и не будет, потому что никто не будет писать на php, отказываясь от его преимуществ.

модель *что вижу, то и пою* от этого не меняется

еще раз, это не «модель» PHP, это «модель» апача без настроенного хэндлера :)

если ты про размещение сорцов за пределами document root - yii и laravel на вскидку

в смысле, там можно вообще ни единого файла .php в document root не выводить?

и да, это не проекты для end-user-ов - насколько это практично, может показать только проект для end-user-ов

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

и? а я что сказал?

в отличии от того же питона, который в web'e просто непопулярен :)

и? от этого у них что-то меняется в модели исполнения?

Так если дефолтные для уймы людей настройки сделаны для ССЗБ — обязательно найдутся ССЗБ, которые их пользуют.

еще раз, это не «модель» PHP, это «модель» апача без настроенного хэндлера :)

это модель, которым пользуется 99% всех скриптов php. это медицинский факт. php и вся инфраструктура просто заточены под эту модель. и никто не бежит от неё отказываться.

наличие phpdaemon не говорит, что его наличие кому-то интересно, или что реально начать портировать всю экосистему под такую модель - поэтому php использовали, используют и будут использовать в режиме *что вижу, то и пою*.

Зачем?

Зачем я это всё читаю?

Ну пхп не то, чтобы не любят, а его просто не используют, т.к. это архаика из 90-2000х. Пхп был актуален, когда веб-приложения писались на cgi, это был прорыв, ведь пхп стал первым шаблонизатором. Сейчас же, в эпоху микросервисов, реста, вебсокетов, сапов, облачных серверов и горизонтального масштабирования, пхп стал никому ненужен, т.к. он во все это не умеет, ведь это, по-сути, шаблонизатор, а такие есть уже в каждом языке. В эпоху докеров, кубернейтов и смузи, деплоить приложения загрузкой файлов по фтп, лал. Не говоря уже о том, что, концептуально, пхп плохой язык и платформа.

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

в смысле, там можно вообще ни единого файла .php в document root не выводить?

да, fpm'y пофиг где скрипты и статика - можешь смело раскатывать проект в хомяке, как ты любишь

и да, это не проекты для end-user-ов - насколько это практично, может показать только проект для end-user-ов

как и джанго или любой другой проект на питоне :)

хотя нет, джанго всё-таки дальше

и? а я что сказал?

ты сказал, что это проблема php как языка программирования

и? от этого у них что-то меняется в модели исполнения?

от этого я не могу использовать апач и его mod_python, мне придётся намного больше возиться с настройкой, не понятно зачем и почему. ну кроме того, чтобы осознать, что питон для web'a - довольно плохой выбор

да, fpm'y пофиг где скрипты и статика - можешь смело раскатывать проект в хомяке, как ты любишь

это не то, это ты просто место для php-скриптов переопрделелил, такого же эффекта можно добиться обычным симлинком :)

ты сказал, что это проблема php как языка программирования

чё? какая проблема, какого php? чё за бред я читаю? я сказал, что у php и того же python разные модели исполнения.

от этого я не могу апач и его mod_python

какой, нахрен, mod_python, ты из какого века? где вообще можно найти mod_python и как он работает? никогда не видел.

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

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

https://vk.com/jobs?w=job23

This site can’t be reached

google://psp python server pages

Правда это не принято использовать.

такого же эффекта можно добиться обычным симлинком :)

нет, неможно

я сказал, что у php и того же python разные модели исполнения

а тебе ответили, что это у тебя «разные модели исполнения»

где вообще можно найти mod_python

там же, где и mod_php

как он работает?

так же, как и mod_php. по той же «модели исполнения»

Правда это не принято использовать.

можно ещё в cgi-bin python-скрипт закинуть. :) правда, осталось найти хоть одно приложение, которое так заработает

Можно и просто

AddHandler cgi-script .py
Options +ExecCGI

Как и любой другой язык ПХП ненавидят за разработчиков на нём. Но теперь знамя ненависти у яваскрипта мне кажется. Бурления о Дельфи, Яве, ПХП уже успокоились немного.

где вообще можно найти mod_python

там же, где и mod_php

последняя версия mod_python вышла ещё при Брежневе

а тебе ответили, что это у тебя «разные модели исполнения»

то есть, все эти битриксы, owncloud-ы и прочее - это не php-шное, а моё? :) нет, не надо мне такого счастья. а для php все пишут для такой модели, причём здесь я? я на php писал с 2002 по 2011 годы, теперь же пишу на нём крайне редко.

нет, неможно

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

Правда тормозной питон станет тормозить еще больше, но мы таки запихнём питон в document root

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

переменные начинаются с $

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

10 LET A$="Text"

последняя версия mod_python вышла ещё при Брежневе

видимо у тебя некая альтернативная реальность, где Брежнев присутствует в 2013 году

для php все пишут для такой модели

Научу запускать «все эти битриксы, owncloud-ы» не под mod_php. Дорого.

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

поток бреда какой-то... «нам нужно выполнить php-файл, но не выполнить php-файл»

я вот не помню, а функции там тоже заканчивались на $ или нет?

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

например, в visual basic функция funkcia$ возвращала строку, а funkcia - Variant. то есть, это не только переменных касалось, но и функций, единообразие