LINUX.ORG.RU

Текстовая обработка в языке Python


0

0

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

>>> Подробности

Ответ на: комментарий от anonymous

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

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

как уже верно заметил выше товарисч жаба-програмер, кошернее и идеологически правильнее писать соотв. get/set методы.

isden ★★★★★
()
Ответ на: комментарий от isden

> как уже верно заметил выше товарисч жаба-програмер, кошернее и идеологически правильнее писать соотв. get/set методы.

Это кто тут лезет со своими жабабыдлокодерскими замашками в наш Питон? Юзай проперть и уткнись.

ero-sennin ★★
()
Ответ на: комментарий от anonymous

> Например, Google Groups написан на Питоне.

Вот вам, всякие быдлокодеры и не осилившие Питон: http://www.michael-noll.com/2006/04/04/python-at-google/

Сам пишу 90% кода на Питоне и посмеиваюсь когда идут горячие споры о великих .Net, Java или ещё всякой хрени. Perl ушёл в себя, Ruby ещё года три на латание нужно.

anonymous
()
Ответ на: комментарий от yk4ever

> - Мальчик, а почему ты бабочек в противогазе ловишь? > - Я пионер, я трудности люблю!

:) Вот это точно про анонизмуса, у которого аллергия на высокоуровневые языки. Ну ничего, с опытом это обычно проходит.

anonymous
()
Ответ на: комментарий от ero-sennin

а не пойти ли вам и покурить мануалы на предмет идеологии ООП и потом самому уткнуться? :)

PS: на жабе ниразу не програмил. будут еще гипотезы? =)

isden ★★★★★
()
Ответ на: комментарий от isden

> покурить мануалы на предмет идеологии ООП и потом самому уткнуться

Эта... Во-первых, OOP и encapsulation - совершенно ортогональные концепции. Во-вторых, геттеры-сеттеры надо писать только тогда, когда они делают что-то кроме самого получения/присваивания значения переменной.

Ну и так, к слову: :) I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind" - Alan Kay, OOPSLA '97

anonymous
()
Ответ на: комментарий от isden

> а не пойти ли вам и покурить мануалы на предмет идеологии ООП и потом самому уткнуться? :)

На какой странице в этой иделогоии ООП написано, что надо всё делать чережжопу? :D

Давайте попробуем трезво поразмыслить. В С++ и Яве принято для всех полей класса делать пустые геттеры и сеттеры для того, чтоб потом можно было добавить в них какой-то код, не ломая обратной совместимости. В Питоне есть проперти. Таким образом, если нам надо предоставить доступ к какой-то переменной-члену, мы берём и предоставляем. Ибо с вероятностью 90% геттер и сеттер нам просто не понадобятся. А если и понадобятся, мы эту переменную превратим в проперть. Старый код при этом будет работать как ни в чём не бывало. Ну если хочется, можно эту проперть сделать deprecated и рекомендовать обращаться к этому свойству через соответствующий геттер и сеттер напрямую, сугубо для ясности.

В Яве и С++ пропертей нет, и пустые сеттеры-геттеры - это хоть и необходимый, но КАСТЫЛЬ.

ero-sennin ★★
()
Ответ на: комментарий от ero-sennin

> В Яве и С++ пропертей нет, и пустые сеттеры-геттеры - это хоть и необходимый, но КАСТЫЛЬ.

ну и таки, где же ООП правильное? в C++ или в Питоне? :)

2 anonymous :

> Во-первых, OOP и encapsulation - совершенно ортогональные концепции.

да ладно? а нас еще в универе учили, что инкапсуляция есть одна из составляющих ООП.

> Во-вторых, геттеры-сеттеры надо писать только тогда, когда они делают что-то кроме самого получения/присваивания значения переменной.

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

isden ★★★★★
()
Ответ на: комментарий от isden

> да ладно? а нас еще в универе учили, что инкапсуляция есть одна из составляющих ООП.

Не знаю, чему вас учили, но, например сейчас, вообще принято считать (и учить!), что ООП - это то, что есть в C++. К этому смотрите мою предыдущую цитату Alan Kay. Далее, энкапсуляция является концепцией такой методологии как Абстрактные Типы Данных, которая предшествует ООП. Наконец, надо разделять две концепции, которые опять же теперь часто путают: encapsulation и enforced encapsulation. Enforced encapsulation - это и есть "компилятор не даст вам добраться до данных в другом модуле/файле/объекте". (У того же Alan Kay, кстати, где-то тоже было про разницу между этими понятиями). Крики про то, что где-то нет энкапсуляции как правило имеют в виду именно второе. Это, кстати, довольно глупо, так как по-настоящему enforced encapsulation вообще не существует почти нигде.

anonymous
()
Ответ на: комментарий от anonymous

да, судя по всему, мне следует покурить свежайшие мануалы по ООП :) как далеко однако шагнула вперед наука за последние 9 лет...

isden ★★★★★
()
Ответ на: комментарий от isden

Наоборот, поинтересуйтесь, что было годах так в 80-х, до того, как слово "ООП" захватили себе си-плюс-плюсники.

anonymous
()
Ответ на: комментарий от anonymous

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

isden ★★★★★
()
Ответ на: комментарий от isden

> смысла в этом особого не вижу, т.к. это знание будет лежать мертвым грузом

Ну, тут трудно что-то сказать, конечно. Ведь, возможно, вы действительно все это знаете и ничего нового вас не ожидает. В то же время, есть ведь немало людей, которые не имеют никакой информации (потому что их так учили и маркетинг поддерживает их в этом), кроме "ООП - это как в C++" и не знают, что бывает что-то другое. Для таких людей (ну или для той части из них, кто способен воспринимать что-то новое), может оказаться большим открытием, что так называемые "современные" технологии во многом отстают от достижений 80-х.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.