Ну конечно. Если учесть, что super - это новый вариант вызова методов родительских классов, то могу я могу предположить, что ты неправильно понял, что тебе написал компилятор.
@dastik
Можно и одинарные. Формат xml позволяет использовать оба типа (хотя я, если честно, думал, что только двойные). Но, на мой взгляд, одиночные кавычки редко экранируют, в отличие от двойных. А если ты занимаешься в основном вёрсткой, то не всегда можно изменить то, что приходит с сервера.
Например, есть поле с именем. Бывают имена с апострофом (Жанна Д'Арк) который вводят обычно одинарной кавычкой. А у тебя всё сделано одинарными. В случае html-доктайпа ты можешь просто поменять пару одинарных на пару двойных в тех тегах, в которых ты допускаешь попадания одинарной кавычки в атрибут при рендере шаблона (в данном случае, значение с кавычкой как раз будет в атрибуте value для тега input). Но xhtml намного более строгий формат. Нужно по всему документу использовать только один тип. Поэтому ты не сможешь изменить только одну пару кавычек, нужно менять все. И есть вероятность (если страница большая), что простой replace заменит одинарные кавычки и в ненужных тебе местах. Придётся долго сидеть и разбираться.
Плюс, в случае html, шаблон отрендерится почти в любом случае, только разметка будет коцанной. В случае xhtml возникнет либо ошибка на сервере, так как документ xml будет невалидный, либо браузер ничего не отобразит по той же причине невалидности xml.
С двойными будет меньше проблем, они обычно всегда экранируются.
В общем, если ты не можешь влиять на серверную часть. лучше не надейся на экранирование, пиши всё в двойных, даже если стоит html-доктайп. Так будет намного меньше проблем во многих местах.
@Petroveg Да, с логической переменной я переборщил) Просто сложно выразить, когда конкретно нужен while, тут уж дело привычки и некая интуиция, выработанная годами кодинга.
Во многих языках в for можно вставлять сложные условия изменения переменной и/или условия завершения. В си-подобных циклах можно даже вычислять числа фиббоначчи и находить НОД, просчитывая значения только в определении цикла, а не в его теле. Но для просмотра всего массива намного нагляднее и понятнее использовать for, нежели while. Последний же, на мой взгляд, применяют реже.
Да и вообще, можно отказаться от циклов в пользу рекурсии (простой либо "итерационной").
@Petroveg Я имел ввиду немного другое.
Если использовать while как аналог for (т.е. берём длину массива, устанавливаем счётчик, в теле while его инкрементируем и сравниваем с длиной массива), то это чушь. For подходит намного лучше для таких целей. Потому что вместо 4-х строчек всё записывается в одну. Поэтому для прохода по массиву или объекту лучше брать for. Конечно, можно всё переписать и на while, но зачем?
While же удобно применять в несколько других случаях.
1) Проверка на некое логическое условие, которое не требует счётчика. Банальный пример: надо заполнить множество 100 случайными числами, значения которых будут от 1 до 200. Да, можно и в for это замутить, но нагляднее будет сделать это while'ом: while(set.length < 100) { set.add(random(200)) }. (это псевдокод, естественно). Ещё пример - получать данные, пока не будет получено сообщение о выходе или о конце файла/потока данных/etc: while(msg != 'exit') { msg = readData(source) }. Опять же, можно и for'ом сделать, но это while в данном случае, более наглядный и понятный.
2) Итераторы в Java стиле: while(iterator.hasNext()) { data = iterator.getValue(); doSomething(data) }.
@Tiendil Это пример того, в какую сторону мыслить, а не конечная реализация. @Deerenaros Я об этом написал. Не делал проперти, потому как не знаю на сколько будет понятен код автору, вдруг он питон в глаза не видел и не поймёт что как, а за декораторы долго объяснять.
Ты как маленький, всё надо разжевать и в рот положить.
В обычном MVC из вьюхи приходят данные этой вьюхи. Вьюха может быть, например, формой в десктопном приложении, или на сайте, тут будет меняться только способ отправки и приёма данных. Контроллер принимает эти данные, и отправляет их нужным методам модели. Вся логика по обработке или преобразованию этих данных в находится в моделях. Методы модели могут вернуть некоторые данные обратно в контроллер. Тут он опять выполнит функцию передатчика и отправит данные нужным вьюхам или другим моделям.
Понимаешь суть? Вьюхи знают только как отображать поступившие данные. Модели знают только как обрабатывать поступившие данные. Контроллеры знают только как перенаправлять данные в оба направления.
Получается такая цепочка: юзер -> V -> C -> M -> C -> V -> юзер.
А что, питон настолько сложный? И почему "конечно"? Слабая типизация и отсутствие быстрых веб-серверов могут сыграть злую шутку. На самом деле, чтобы писать большие и надёжные приложения на PHP, инфы изучать придётся намного больше, чем, например, в питоне.
Учи Java, автор.