albertn, имхо ты не до конца разобрался в ПХП зато покритиковать его завсегда гаразд.
Это нехорошо, товарищ. Тебе уже не раз обратили внимание что ты чего-то не понял в ПХП потому что по крайней мере не знал пары функций довольно распространенных.
Может хватит спорить просто ради того, что уже начал спорить? Язык надо знать очень хорошо, чтобы критиковать.

nerezus, 

А в чем трабл то? Легко себе представляю.

Вопрос стоял о взятии на работу человека не знакомого с языком который якобы асилит его за пару - тройку дней. Какие тут основы? И потом я сомневаюсь, что питон проще изучить чем PHP. Всё - таки человеку знакомому c C или Java с PHP будет попроще ИМХО.


означает ли это, что в том питоне непременно будут установлены фреймворки, необходимые для веб разработки?

А про объекты никто ничего и не говорил. Я в основном говорю про педедачу параметров через форму или подобным образом.

Я как раз это и имел ввиду. Зачем нужна эта нестрогая типизация, если все-равно приходится проверять параметры?

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

А никто не мешает все фреймворки скопировать в папку на сервере, и просто запустить их

Это сообщение отредактировал(а) albertn - 25.10.2006, 12:26

ну так проверять типы и проверять значения - не одно и то же. Повторю свой же вопрос:

Т.е. в языке со строгой типизацией тебе побоку, что 0 вызовет никому не нужный exception, пустая строка с именем файла может вызвать крах системы, зато типы совпадают? или как? а если проверяешь на валидность сами значения, то какая разница, под какими типами пришли "оригиналы"?

Это сообщение отредактировал(а) skyboy - 25.10.2006, 16:06

Если передается параметр допустим от тега select, в котором находятся только числа, то я просто использую его в каких-нибудь арифметических выражениях (с преобразованием в целый тип), а дальше допустим запихиваю в базу. Если вдруг кто-то преднамеренно передал что-то нехорошее, то естественно вывалится exception, так пусть он и будтет, нефиг сайты ломать.
Про крах системы это ты конечно загнул 
Возьмем даже другую ситуацию, если юзверь по ошибке передал не "1234", а "123к4", то PHP при преобразовании к целому получит 123, а при заливке в базу 
оригинала получит "123к4". Многозначность выходит. А Python не даст просто так преобразовать "123к4" к числу, и то, что вывалится exception будет вполне уместно.

albertn
а питон даст просто так сложить 

Или 
?

конечно. но строгая типизация не освобождает программиста от проверки входных данных.

зато если у тебя сместится смысл этого параметра от числа к строке(например, будет передаваться некий условный код), то при строгой типизации придется менять не только код, но и интерфейс. И все вызовы переписывать. А при нестрогой типизации - только код проверки. Кроме того, проверка по типам - это что-то вроде подспорья, ведь для компа пофиг нет ничего, кроме 0 и 1, потому byte/long/int или is_number(x) && x<255//is_number(x) && x<4294967296 - это все приходящее. 

если тебе надо число, и в результате преобразований ты получил число, то зачем заливать оригнинал?

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

Но зачастую она происходит при принудительном преобразовании строки к числу. А в строке в любом случае необходимо экранировать специальные символы (если это конечно не Zope)

Это уже вопрос правильности программирования. Я неоднократно видел как на Zope в исходниках происходила многозначная проверка параметров, и в зависимости от них выполняются те или иные действия. Но согласен в PHP при смене типов параметров проще. Но это происходит только при смене интерфейса, и изменения будут касаться только вызываемой функции.

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

фреймворки - это пакеты, их очень легко установить или даже 

даже с ПК с другой ОС



можно конечно:


или



exception легко обойти:

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

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

Заодно вопросы мне интересные по python:
Насколько прозрачно там работать в Сессиями. Естьи ли там gd или аналог. Как дела с unicode?
На счет связок с БД я надеюсь там все ок? (нативно i mean?)

p.s. Синтаксис у него не C-подобный как я понял? То есть никакой короткой записи и прочих приятный мелочей?

Не понял, что значит "а в ней уже". ты что, имеешь в виду, что уже при передаче в подпрограмму сразу "124к5" преобразуется в "124" безо всяких вычислений и прочих причин для смены типа? 

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

хорошо давай посмотрим:


если ты про сессии в веб, то сессии есть практически во всех фреймворках (Zope, TG, Django). авторизация,  работа с куками, сессии.

это что такое?

с unicode все прекрасно:

и это не предел.
можно работать с простой строкой, хотя в ней не латиница т.е. 

для этого нужно просто прописать в site.py что кодировка по умолчанию utf-8 или cp1251 или ещё какая-то


с БД проблем нет:
1) есть специальзированные пакеты для каждой СУБД (MySQLdb, psycopg, cx_Oracle и т.д.)
2) есть универсальные типа mx.ODBC или ODBC в PythonWin
3) есть "обёртки" типа SQLObject или sqlalchemy, которые можут работать с любой БД (СУБД), которые поддерживают SQL, а sqlalchemy может работать с ораклом
4) есть Zope, у которого есть своя БД, если именно про это интерестно, то можешь обратиться к albertn, - он спец по Зоп.

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

 И он есть, и имеджмеджик.


 На порядок лучше, чем в пхп.

nerezus, пожалуйста, объясни про что это вы?