Перейти до основного вмісту

Публікації

Показано дописи з лютий, 2011

Python і ланцюгова реакція і ... дескриптори

Хочу поділитись своїми думками з приводу одного прикольного стилю програмування класів - ланцюгові виклики. Для когось це буде не новим, комусь, може, не подобається, але я вважаю, що такому стилю можна знайти застосування, при цьому код програми буде виглядати більш зрозумілим і логічним. Цей стиль буде зручним для класівв моделей даних, методи яких містять деяку логіку, що змінює стан класу, наприклад, класи об'єктів в комп'ютерних іграх, абстрактні моделі в моделюючих системах різного плану. Проста задачка Розглянемо реалізацію простого класу, назвемо його "тупий охоронець". Уявимо собі, що ми робимо комп'ютерну гру. У нас є замок, а біля воріт патрулює охоронець: ходить туди-сюди, більше нічого не робить. Код на Python 3.1: class StupidGuard:     """     Stupid guard that moves around given route (way points).     """     direction = 0     position = {'x': 0, 'y': 0}     def go(self, steps):         self.positi

Це Python таке гальмо чи я?

Пролог Прискорюємо Python-код Цей невеликий пост хочу присвятити оптимізації швидкості виконання кода на Python. Часто кажуть, що Python - велике гальмо. При цьому надають куски коду, ось - спробуй таке прискорити. Так, справді, деякий код не можна прискорити, тому что... тому що гладіолус . Але у величезній кількості випадків стається так, що гальма програми зовсім не через мову, а... правильно, через розробника. І вся проблема криється в реалізації алгоритму. Хочу показати невеликий приклад оптимізації невеликої математичної задачки. Отже, почнемо. Задачка дуже проста, взята з projecteuler.net .  Постановка задачі Знайти найбільший паліндром, який є добутком двох тризначних чисел. Рішення в лоб Отже, не вдаваючись в дослідження математичних властивостей паліндромів, розв'яжемо задачку в лоб. Алгоритм приблизно такий: Цикл по числах від 100 до 999. Внутрішній цикл по числах від 100 до 999. Якщо добуток змінних ітерації зовнішнього і внутрішнього циклу - паліндром і він більш

Роздуми про ідеальну архітектуру додатків. Частина 2: Розвіюємо міфи?

Зміст Частина 1 Частина 2 Пролог Пройшло вже декілька дній з моменту публикації  першого посту по даній темі. Ох і наслухався я про себе за цей час, ну, не так про себе, як про саму ідею. На жаль, все "Фу..." не пішло в коментарі. Хтось писав в скайп і джаббер, хтось в особистому співлкуванні. Підбиваючи підсумки: всі засумнівались і посміхались. Але... Багато хто так і не зрозумів, що я хочу донести, тобто неправильно зрозуміли суть задачі, яку я пробую вирішити, і зараз я це хотів би поправити. це швидше моя помилка. Я не пробую створити універсальний  засіб вирішення інженерних  задач Це в корені оманливе твердження, яке я отримав в коментарях до попереднього поста. Універсальне рішення - це наш мозгок Але найбільш цікавий момент тут в тому, що він не призначений напряму вирішувати задачі. Схему його роботи шивдше можна подати як: "навчитись рішати" -> "рішити". А в наш час ще й створити засіб для того, щоб задачу, яку ми навчились рішати - вир

Роздуми про ідеальну архітектуру додатків. Частина 1: Чи можливо це?

Зміст Частина 1 Частина 2 Пролог Ні, тут я маю на увазі не мову програмування, а саме вступ до публікації. І термінатор тут дуже доречний, потому что ми будемо вирішувати саму задачу побудови "Термінатора", як мінімум T-100, а далі як піде. Постановка задачі "Чи існує ідеальна архітектура додатків, і чи можна створити фреймворк, який підходив би для вирішення всіх-всіх-всіх задач програмної інженерії?" Оце так постановка питання! Так? Чи існує відповідь на це запитання? Ну, судячи по ноявності мов програмування, фреймворків і рішень... мабуть, поки що ні. Чи варто працювати над цим? Тобто, чи варто шукати таке рішення? Припустимо, що так. Навіщо тоді ця стаття? Чи є всі існуючі рішення тим самим пошуком? Осмілюсь заявити, що ні. Є багато шаблонів проектування, рекомендацій на всі випадки життя, архітектур, які успішно і неуспішно використовуються при створенні додатків. Чому? Кожен інженер-розробник працює в своєму колі задач. Загальна множина задач росте з ко

Переходимо на Python 3. Де ж ти, reduce?

Це мій другий пост про освоєння Python 3. Почався він з того, що захотілось мені використати всім відому вбудовану функцію reduce, а я замість робочого коду отримав NameError . Виявляється в Python 3 вона вже не вбудована, а знаходится в модулі functools , в який, починаючи з версії Python 2.5, засунули декілька корисних речей для роботи з об'єктами-функціями. Тобто тепер функцію reduce потрібно імпортувати. from functools import reduce Варто зазначити, що специфікація функції не змінилась, працює вона точно так, як і в другому пітоні. Постало питання: "Навіщо?". (Більш детально про reduce читаємо в документації ). З чого все почалось? А почалось все з Гвідо ван Россума, який сказав наступне, коли тільки Python 3k починали розробляти. Ось довільний переклад: Близько 12 років тому в Python з'явились lambda, reduce(), filter() і map(); з'явились вони через (здається) Lisp-хакера, якому не вистачало їх в Python, і який надав працюючі патчі. Але, незважаючи ні на щ