Обсуждение:Python/Архив/2007

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Примеры кода[править код]

Для них есть отдельная статья Python примеры программ РоманСузи 19:42, 9 февраля 2007 (UTC)[ответить]

Надо бы поместить примерчик кода, чтобы был понятен начинающим, но не примитивен (без Hello world всяких там). Вероятно что-то отражающее специфику языка — словари и списки и их обработка, определение какой-нибудь функции, что-нибудь с lambda и пр. Какие будут предложения? — Эта реплика добавлена участником Сибирский Лайка (ов) 23:13, 29 августа 2004 (UTC)[ответить]

Думаю нужно добавить раздел "примеры кода" и в него поместить несколько различных программок, демонстрирующих различные аспекты языка. В качестве начала могу предложить традиционный поиск факториала, а также простых чисел. Обе эти программы есть в python tutorial. Если согласны, то я добавлю. --skyrider 00:32, 31 Авг 2004 (UTC)

Да без вопросов. Давай сюда свои примеры. Ещё хорошо бы небольшой туториал добавить по Qt и wxWidget. fantom-lab@mail.ru ВАлерий Шипков. 07 нбр 2005 — Эта реплика добавлена с IP 217.168.78.28 (о) 15:04, 7 ноября 2005 (UTC)[ответить]


Рефакторинг статьи[править код]

Немного подправил текст во многих местах. Считаю, что не нужно так хвалиться (хотя и понимаю, что очень хочется). Википедия должна подавать информацию нейтрально - факты. Надеюсь, что после исправления стало лучше. 62.248.239.110 16:04, 27 января 2007 (UTC) Роман Сузи.[ответить]

Полагаю, что информацию о самом Питоне (и станд. библиотеке) нужно сильно переделать. В настоящий момент информация, содержащаяся в статье, очень несбалансирована. Такое ощущение, что где-то должна быть другая статья, которая описывает обычные возможности Питон. Но ведь это не так. В результате у тех, кто первый раз читает статью может сложится превратное ощущение, что самое главное в Питон - генераторы, функциональное программирование и тому подобные "нетривиальные" штучки. Убежден, что это неправильно. Должна быть краткая и точная информация о языке, с указанием всего, даже очевидного. И для такого изложения не нужно существенно больше места. Например, синтаксис можно проиллюстрировать одним большим примером. Типы данных помимо перечисления могут содержать срез некоторых важных моментов (например, изменчивость-неизменчивость). Слова о пространстве имен и области видимости не помешает. Пара предложений об операциях над типами, листинг с примерами литералов - и читатель получит представление об этой теме. Если нет возражений, я постараюсь найти время для этих изменений. РоманСузи 11:27, 28 января 2007 (UTC)[ответить]

Предлагаю вынести в отдельный раздел информацию по альтернативным реализациям питона. Сейчас она разбросана по нескольким разделам что не позволяет их(реализации) хорошо описать. Я хотел добавить описание по stackless но так и не нашел где это сделать. Так-же сильно неполное описание, ИМНО, по такому весьма важному проекту как PyPy. Возможно имеет смысл вынести PyPy и stackless в отдельные статьи.koder 13:48, 30 января 2007

Также я думаю что необходимо перестроить подборку ссылок на внешние ресурсы. Сейчас там все свалено - так например в разделе "Расширения и библиотеки" приведена ссылка на форумы по питону. Для начала я вынес ссылки на альтернативные реализации в отдельную группу. Наверное нужно указать ссылки на какие ресурсы имеет смысл добавлять внизу статьи - т.к. просто билиотек и расширений в питоне очень много. Например преименовать раздел в "Наиболее важные/полезные/большие/???? расширения и библиотеки" koder 15:19, 30 января 2007

Возможно стоит позаимствовать некоторые идеи из стать по Руби? Например добавить краткое описание средств разработки и раздел с отрицательными сторонами. Если никто не против то я добавлю. K.Danilov aka koder 17:19, 2 февраля 2007 (UTC)[ответить]

Может быть, стоит выделить описание средств разработки в отдельную статью? Что касается отрицательных сторон, то я полагаю, что не нужно выделять их в отдельный раздел как это было (положительное размазано по всей статье, отрицательное собрано). Думаю, в разделе сравнения с другими языками самое место критике Питона и для других оценочных высказываний. А конкретные отрицательные стороны можно по ходу повествования давать. РоманСузи 18:47, 2 февраля 2007 (UTC)[ответить]

> Может быть, стоит выделить описание средств разработки в отдельную статью?

Наверно, а то действительно может сильно раздуться. А по поводу отрицательных сторон - например IMHO нужно написать что модель питона не позволяет перегрузку фукций / методов, управляемую компилятором, а все нужно делать руками, но для этого существуют уже готовые решения (замедляющие выполнение кода). Но где это написать я не вижу. K.Danilov aka koder 10:57, 3 февраля 2007 (UTC)[ответить]

Есть мысль добавить (возможно отдельной статьей) програму строк так на 80 - 100, которая покажет всю мощь питона по сравнению с С++/Java(например минимальный RPC сервер/клиент прим в 100 строк влезет) а там будет и pickle и интроспекция и многопот и замыкания др. K.Danilov aka koder 12:09, 3 февраля 2007 (UTC)[ответить]

Также отдельной статьей нужно, по-моему, более подробное описание модулей стандартной библиотеки. Разумеется, не для замены документации, а для освещения наиболее характерных вещей. Например, difflib, elementtree, email, sqlite и т.п. хорошие кандидатура, как и множество других полезных модулей, о которых можно хотя бы параграфом рассказать. Насчет "модель питона не позволяет перегрузку фукций / методов, управляемую компилятором" нужно доступнее написать. РоманСузи 09:13, 4 февраля 2007 (UTC) Спасибо, прочитал. Честно говоря, никогда с такой проблемой не сталкивался. Вилимо, она очень специфична именно для межъязыкового общения. РоманСузи 20:45, 6 февраля 2007 (UTC)[ответить]

Сделал статью для примеров.Python примеры программ. Ее нужно дооформить(как минимум). Усе приглашаются к написанию. K.Danilov aka koder 11:02, 5 февраля 2007 (UTC)[ответить]

Базовая статья уже больше 75к при рекомендуемом размере не более 50к. Может вынести описание сторонних библиотек в отдельную статью? K.Danilov aka koder 14:18, 5 февраля 2007 (UTC)[ответить]

Кажется, недостаток перегрузка (а, наверное, точнее - диспетчеризация) на основе сигнатуры сильно раздута в тексте. Может быть, ее куда-нибудь выделить и/или подсократить? Лично мое мнение, что это вообще очень мелкая проблема, которая может быть уложена в пару предложений и ссылок на понятия типа сигнатура и т.п. Тем более, эта проблема будет скоро решена: http://www.artima.com/weblogs/viewpost.jsp?thread=155514 РоманСузи 15:11, 8 февраля 2007 (UTC)[ответить]

Относительно терминов. В ООП применяются разные термины - поля, свойства, атрибуты, члены и т.п. В этой статье они все используются (или у меня такое ощущение). Предлагаю как-то унифицироваться или хотя бы где-то написать, что это одно и тоже. Сам я употребляю методы (те, что можно вызывать) и атрибуты (все атрибуты, в тч методы). Свойства только в случае явного оформления. А ведь еще есть слоты... Поля вообще не употребляю - так как в документации по Питону такого нет. Члены тоже странно звучат. РоманСузи 15:11, 8 февраля 2007 (UTC)[ответить]

По поводу полей/методов/etc - ок, давайте все переименуем. По поводу перегрузки - если человек серьезно писал на С++ то перейдя на Python это первое и основное что СИЛЬНО достает. А насчет ее решения - даже PEP'а еще нет. А блог - он блог и есть (к тому-же годичная давность). Но вот по пов. размера я согласен. Давайте перенесем из основной статьи большую часть про выражения, перегрузку,etc. а оставим только аннотацию - примерно как с ООП. А для полного варианта сделаем отдельную статью, например Расширенный обзор возможностей ЯП Python K.Danilov aka koder 15:59, 8 февраля 2007 (UTC)[ответить]

Я создал примерный вариант сокращенной статьи Python/Temp , в ней еще нужно(IMHO) почистить блоки Выражения и Профилирование и оптимизация кода. Расширенной статьи нет, поэтому если будем перехдить на сокращенный вариант, то нужно сначала создать ее и соответвтующие ссылки. K.Danilov aka koder 18:04, 8 февраля 2007 (UTC)[ответить]

Я успел немного подправить основную статью ;-) сорри. По поводу статьи я полагаю, что в целом скелет должен остаться, где будут изложены самые основные положения (например, как про ООП). Наверное, логично вынести в отдельную статью обзор стандартной библиотеки. Почти все примеры, кроме самых коротких (меньше 3-4 строк), тоже в Примеры. Но при выносе можно делать ссылки. Функциональное программирование тоже можно вынести по аналогии с ООП. И описание языка (операторы, выражения, и тп.). Вообще я думаю, что статья про Питон полезна для Википедии именно в силу того, что она привносит много своей терминологии, разбавляя бульон (или винегрет ;-) под названием С++,Джава,Дельфи. Поэтому я считаю, что терминология из документации по Питону имеет очень важное значение так как несет культуру рассуждения о языках программирования. Поэтому если перегрузка сильно достает, давайте напишем отдельный раздел для "иммигрантов" из Java, C++, Delphi... Я уже 8 лет на Питоне программирую и никогда не чувствовал проблемы по поводу перегрузки функций! (Мне даже сам этот сишный термин не нравится, так как он говорит не о том, что должно быть, а о том, что нужно сделать, чтобы было! Как будто это какой=то клудж (исторически он такой и есть)!) Еще я предлагаю использовать (там где уместно) статьи про конкретные понятия. Я видел примеры на Delphi,Java,C++, но Питона я еще не видел - но уже кое-где добавил ;-) Про методы и поля - переименуем в какую сторону? Нужно к единому мнению прийти. РоманСузи 17:54, 9 февраля 2007 (UTC)[ответить]

Посмотрел Python/Temp. Полагаю, что нужно сокращать объем не совсем так, сминая, скажем, "другие" возможности в одну секцию. Думаю, что лучше программу забросить в Примеры и об этом где-нибудь сказать - что примеры там-то. РоманСузи 18:08, 9 февраля 2007 (UTC)[ответить]

Ну пусть будут методы/атрибуты мне все равно )). Часть про перегрузку я укоротил до минимума. Если Появится раздел "для эмигрантов" то ее конечно можно перместить туда, только я боюсь придется в этот раздел большую часть статьи перенести )), Python, однако, сильно не "С". > Еще я предлагаю использовать (там где уместно) статьи про конкретные понятия это про генераторы отдельно, про замыкания отдельно? Правильно я понял? Тогда я думаю все-же лучше их в одну согнать. Сложно будет про итераторы целую статью написать IMHO. По поводу стандартной библиотеки +1 и статью про мудули тоже. Хотя внешние модули в основной статье мне нравятся в текущем состоянии. Просто в отдельной статье можно больше написать. По пов. Python/Temp - ну так поправьте на свой вкус )) K.Danilov aka koder 18:40, 9 февраля 2007 (UTC)[ответить]

> это про генераторы отдельно, про замыкания отдельно? Правильно я понял? Тогда я думаю все-же Нет. Я имею в виду, что статья про Питон должна их упоминать и где возможно - иллюстрировать. Про итераторы не сложно статью написать. Вместо Python-Temp - поправил в основной - кажется, до 75 Кб уменьшилась. Наверное, можно немного успокоиться. Убрал все большие примеры в... Примеры. В общем, если не считать несколько раздутых Оптимизации и Недостатков, вроде статья общими стараниями приобрела подобающий вид. РоманСузи 18:53, 9 февраля 2007 (UTC) Ок тогда Python/Temp удаляем.[ответить]

> Раздел про Недостатки не нравится... Какие-то оправдания сплошные...

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

> все недостатки сводятся к быстродействию

И отсутствию статической типизации. А больше объективных я не вижу. Ок будем считать что рефакторинг окончен, кроме части про библиотеку и расширения K.Danilov aka koder 19:12, 9 февраля 2007 (UTC)[ответить]

Стандартную библиотеку выделил в отдельную статью (она того заслуживает). А вот расширения - точно не знаю, как это назвать правильно в Википедии (Программное обеспечение для Python? Модули для Python? Обзор библиотек модулей Python?). Этих расширений тьма-тьмущая. Нужно с самого начала какое-то подразделение сделать. Думаю, тут тоже нужна отдельная статья и из стандартной библиотеки туда будет много ссылок типа: например, sqlite имеет привязки в стандартной библиотеке, а вот о привязкам к другим БД см. там-то. Выдумывать классификацию для софта не нужно - можно взять из PyPi http://cheeseshop.python.org/pypi?%3Aaction=list_classifiers РоманСузи 19:40, 9 февраля 2007 (UTC)[ответить]

Собственно, было бы неплохо сказать пару предложений про модули и пакеты в Питоне вообще... И про zip... И про дистрибуцию модулей как-то умолчали - distutils, eggи ... Правда, нужно самое главное сказать... А это главное не просто выделить. РоманСузи 21:00, 9 февраля 2007 (UTC)[ответить]

Заменил сценарный на скриптовый - если уж даже категория называется скриптовые языки, а судя по гуглу "сценарный язык" встречается намного реже. РоманСузи 19:04, 31 августа 2007 (UTC)[ответить]

Что такое?!!![править код]

Что такое? Я взял ваш код - и вот что получил: Traceback (most recent call last):

 File "<stdin>", line 5, in ?
 File "/usr/lib/python2.3/urllib2.py", line 129, in urlopen
   return _opener.open(url, data)
 File "/usr/lib/python2.3/urllib2.py", line 326, in open
   '_open', req)
 File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain
   result = func(*args)
 File "/usr/lib/python2.3/urllib2.py", line 901, in http_open
   return self.do_open(httplib.HTTP, req)
 File "/usr/lib/python2.3/urllib2.py", line 895, in do_open
   return self.parent.error('http', req, fp, code, msg, hdrs)
 File "/usr/lib/python2.3/urllib2.py", line 352, in error
   return self._call_chain(*args)
 File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain
   result = func(*args)
 File "/usr/lib/python2.3/urllib2.py", line 412, in http_error_default
   raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)

urllib2.HTTPError: HTTP Error 403: Forbidden

Это что, сюрприз, да? — Эта реплика добавлена с IP 195.19.204.69 (о) 16:56, 24 июля 2006 (UTC)[ответить]

Нет. По всей видимости, запрещено так просто брать страницу с википедии. Я исправил URL на python.org -- заработало 62.248.239.110 18:56, 27 января 2007 (UTC)[ответить]

Лишний else[править код]

Господа, исправьте, ради Бога, ваши коды! Какой может быть "else" после "return" - и в Си, и в Питоне? Си:

int factorial(int x)

   {      
       if (x == 0) 
           {return 1;}
       return x * factorial (x - 1);
   }

Питон:

def factorial(x):

   if x is 0:
       return 1
   return x * factorial (x - 1)

— Эта реплика добавлена с IP 217.148.216.218 (о) 11:13, 18 января 2007 (UTC)[ответить]

А в чем проблема-то? else может быть, а может и не быть. Можно и от if избавиться и в Си, и в Питоне... Суть примера не в этом. 62.248.239.110 19:02, 27 января 2007 (UTC)[ответить]
Более того, else может использоваться для улучшения читаемости, он просто ничего не меняет с точки зрения компилятора. — doublep 11:59, 30 января 2007 (UTC)[ответить]

Компактность записи кода[править код]

По-моему, пример функции, считающей факториал, на C неудачен. Короче написать так:

int factorial(int x)
 {
     return (!x) ? 1 : x * factorial(x-1);
 }


194.85.82.254 00:40, 7 февраля 2007 (UTC)Случайный прохожий[ответить]

Написан самый компактный из легко читаемых. В питоне тоже можно написать

def f(x) : return ( x and f(x - 1) * x or 1 )

или ( для 2.5)

def f(x) : return ( 1 if x == 0 else f(x - 1) * x )

K.Danilov aka koder 08:42, 7 февраля 2007 (UTC)[ответить]

Кстати, неудачно само сравнение… Чувствуется, что пример, мягко говоря, искусственный. «Этот „трюк“ позволяет заметно сократить количество строк и символов в программе» — но здесь легко можно обойтись без нескольких скобок, разве нет?

Программа на C Эквивалентная программа на Python
 int factorial(int x) {
     if (x == 0)                     
         return 1;
     else
         return x * factorial(x-1);
 }
 def factorial(x):
     if x == 0:
         return 1
     else:
         return x * factorial(x-1)

Понятно, что в других ситуациях Питон выигрывает сильнее, но тогда и нужно приводить именно другие ситуации. — Александр Крайнов 00:22, 2 декабря 2007 (UTC)[ответить]

В более длинных примерах выигрыш питона уже не так заметен, не считая того, что строк вообще может не стать больше - скобки можно писать и в одной строке. Более того, операторные скобки позволяют более чётко контролировать логику программы на больших фрагментах при редактировании, чего питону зачастую не хватает. В целом - холиварный вопрос и не стоящий выеденного яйца, показывающий лишь однобокость позиций отдельных, фанатично настроенных товарищей. --Aleks Revo 06:26, 22 марта 2011 (UTC)[ответить]

О недостатках Питон[править код]

Раздел про Недостатки не нравится... Какие-то оправдания сплошные... В основном, все недостатки сводятся к быстродействию и отсутствию статической типизации (даже пресловутые перегрузки!). Питон не лишен недостатков, но может быть где-то в Сети есть уже готовый список? Иначе в разделе одни оправдания... РоманСузи 19:04, 9 февраля 2007 (UTC)[ответить]

Через 7 лет мне он все еще не нравится.

Почему слово Питон нельзя склонять?![править код]

Например слово интернет можно склонять, а питон вдруг на этой странице оказывается несклоняемым. Прошу вас подумать над этой проблемой. — Эта реплика добавлена с IP 213.159.245.126 (о) 15:42, 10 февраля 2007 (UTC)[ответить]

Питон или Пайтон это транслитерация английского слова(кстати никакого отношения к змее не имеет). Это слово не является русским, это просто "калька". Слово же интернет есть в русском словаре(хотя и заимствовано). Насколько я понимаю именно поэтому Пайтон не склоняется, в отличии от интернета. P.S. подписывайтесь, пожалуйста. K.Danilov aka koder 12:58, 11 февраля 2007 (UTC)[ответить]

даже, если это фамилия вымышленного персонажа, не факт, что она обозначает не вид змей. Те, кто используют название Питон - подразумевают именно прямой перевод Python в этом смысле, а не звукоподражание непереводимой фамилии. Другой вопрос, почему нельзя склонять "пайтон"? В русском языке хватает звукоподражаний, которые успешно склоняются, так как слово имеет вполне удобную для этого форму. Со временем эти слова попадают в словари или забываются. Отказ же от склонения, потому что кто-то что-то "свыше" не одобрил ещё - исключительно религиозный вопрос. Язык живой и определяется его носителями, а не законодателями. Кстати, англоязычные имена и фамилии склоняются "на ура", вспомним, хотя-бы, Шерлока Холмса и Доктора Уотсона. Да и в статья про Летающий цирк Монти Пайтона тоже склонять не стесняются. А тут, среди программистов вдруг начались странные по своей природе споры. --Aleks Revo 19:27, 22 марта 2011 (UTC)[ответить]

Эта проблема достаточно интересна. Если кто помнит, сколько было копий сломано как же правильно писать BASIC: бэйсик-бейсик, Бейсик-Бэйсик, Basic, BASIC и склонять ли его, писать ли в кавычках или без. Если уж перевели название на русский, то наверное можно начать и склонять - во всяком случае, Паскаль и Бейсик давно склоняют. Сам я то и дело делаю ошибку со склонением потому привык писать Python. По данным опроса общественного мнения http://pythonbook.it-arts.ru/node/82 - все-таки люди хотят склонять, либо писать по-английски. Так что предлагаю склонять, хотя писать по прежнему с большой буквы - все-таки Питон пока не интернет ;-) Ну или по-английски писать - там где контекст неоднозначен. РоманСузи 13:36, 11 февраля 2007 (UTC)[ответить]

"Питон пока не интернет" - в чём суть разницы? По возрасту они близки, по распространению они никогда не будут близки в силу различий между ЯП и системой коммуникаций, те кто говорят "питон" по большей части ассоциируют именно со змеем, что достаточно отражено, в том числе, и в статье. --Aleks Revo 19:27, 22 марта 2011 (UTC)[ответить]

Сборка мусора и подсчет ссылок в Java[править код]

Я закомментировал предложение В отличие от Java, CPython использует для управления памятью и подсчет ссылок, и «сборку мусора» Т.к. оно AFAIK неверно - как раз эта комбинация в Java и используется. K.Danilov aka koder 08:26, 2 апреля 2007 (UTC)[ответить]

Почему "Литература" находится в разделе "Ссылки"?[править код]

ИМХО, это отдельный раздел. Alex977 09:45, 19 июня 2007 (UTC)[ответить]

Согласен, выделил в отдельный раздел K.Danilov aka koder 14:07, 19 июня 2007 (UTC)[ответить]

Кто на кого повлиял[править код]

Сейчас в статьях ЯП в разделах "Создан под влиянием" и "Оказал влияние на" творится что-то невообразимое. Во-первых - если пройтись по статьям других языком то окажется что на питон повлияли чуть ли не половина из них. С месяц назад подправил статью по Аде сейчас нашел в статье по Haskell (все что, как некоторые думают, Python взял из Haskell(а именно list comprehension) на самом дела туда(в Haskell) пришло из других языков без изменений).
Во-вторых - на каждом языке(в смысле английском,русском,etc) они разные. Может это можно как-то организовать? Предлагаю добавить в статью раздел(небольшой), описывающий как конкретный язык повлиял на Python и на основе этого раздела формировать список влияния. Из текущего списка для меня не понятно как на питон повлияли Tcl и Perl. Так-же в списке не хватает Java - из нее были стянуты: модель исключений, пакеты,immutable строки и часть стандартной библиотеки(unittest например). Индексация массивов очень близка к Fortran.
Хорощо еще было-бы заварганить бота, для автоматической проверки/построения зависимостей из статей.
K.Danilov aka koder 09:49, 25 июня 2007 (UTC)[ответить]

Про недостатки[править код]

Мне кажется, что "Отступление от объектно-ориентированной чистоты" и "Невозможность модификации встроенных классов" - это одна и та же проблема, а не две. (Само выражение "Отступления от объектно-ориентированной чистоты", на мой взгляд, смешно, так как Питон и не являет собой выражение чистоты какой-либо парадигмы). Вообще, говоря о недостатках и достоинствах сложно быть объективным, так как недостатки обычно играют роль только для части применений языка. Дизайн ЯП всегда компромисс, поэтому недостатки, на мой взгляд, должны быть написаны в формате, который обрисовывает обе стороны противоречия. РоманСузи 19:08, 8 августа 2007 (UTC)[ответить]

> "Отступление от объектно-ориентированной чистоты" и "Невозможность модификации встроенных классов"
> - это одна и та же проблема, а не две

IMHO нет. Возможность модификации классов во время исполнения - относится к динамическим возможностям языка а не к ООП. Например Java ООЯП до "мозга костей" но модифицировать там классы нельзя (по крайней мере приемлемыми средствами).

"Отступления от объектно-ориентированной чистоты" переименовал в "Отступления от принципов ООП". Было действительно криво. Если есть идеи получше - правьте )).

> Дизайн ЯП всегда компромисс, поэтому недостатки, на мой взгляд, должны быть написаны в формате,
> который обрисовывает обе стороны противоречия

Я старался. Но мне действительно сложно найти где len(x) лучше чем x.len(). Разве что на символ меньше. Но если у Вас есть примеры - укажите их в статье.

P.S. Я попробовал разделить понятия "язык"(как стандарт == описание) и "реализация". Но вышло, IMO, кривовато - посмотрите заголовок пож.

K.Danilov aka koder 10:05, 9 августа 2007 (UTC)[ответить]

> мне действительно сложно найти где len(x) лучше чем x.len()

Конечно, о вкусах не спорят, но следуя той же логике вместо 2 + 2 нужно писать 2.add(2). Просто присутствие встроенной функции len() подчеркивает, что она играет очень важную роль во всем языке, обслуживая встроенные структуры данных. Например, мне почему-то кажется, что (если уж на то пошло) вместо len(x) нужно писать x.length(). А это еще длиннее... РоманСузи 17:33, 29 августа 2007 (UTC)[ответить]

Предлагается поместить соответствующий раздел в основную статью (в английской википедии он отдельной, но кто-то предлагает объединить).РоманСузи 17:27, 29 августа 2007 (UTC)[ответить]