🚀 go-pugleaf

W dniu 2011-11-21 16:05, hubert depesz lubaczewski pisze:
> hej
> to chyba już ostatnia część pytań bardzo początkujących - późniejsze
> pytania już (mam nadzieję) będą na bardziej konkretne tematy.
>
> 3. co z polskimi znakami. Z tego co przeczytałem, teksty w apostrfach
> powinny być tylko w latin1, a jak chcę coś innego, to powinienem używać
> notacji u'...' i tam podawać codepointy unikodowe.
> i teraz nie wiem - czy źle przecyztałem/zrozumiałem, czy to faktycznie
> tak niewygodne?

http://www.python.org/dev/peps/pep-0263/

i teksty w cudzysłowach piszesz w zadeklarowanym kodowaniu (u"gęś")

PS. kodowanie obowiązujące dla terminala to

 >>> import sys
 >>> sys.stdout.encoding

On Mon, 21 Nov 2011 16:05:13 +0100
hubert depesz lubaczewski <depesz@depesz.com> wrote:

> hej
> to chyba już ostatnia część pytań bardzo początkujących - późniejsze
> pytania już (mam nadzieję) będą na bardziej konkretne tematy.
> 
> 1. czy jest jakiś standardowy, poleceny, "boilerplate"?
> przykład: w perlu, praktycznie zawsze używa się:
> use strict;
> use warnings;
> a jeśli ktoś pisze soft który ma obsługiwać utf, to boilerplate się
> "trochę" wydłuża
> (http://stackoverflow.com/questions/6162484/why-does-modern-perl-avoid-utf-8-by-default/#6163129)
> czy jest coś co każdy porządny program w pythonie powinien mieć na
> początku/końcu?

Nie ma czegoś takiego. Czasami, w zależności od przeznaczenia modułu,
będzie on zawierał linijkę shebang jako pierwszą linijkę skryptu
(zwykle '#!/usr/bin/env python' lub '#!/usr/bin/python'), ewentualnie
deklarację kodowania (np. '# vim: set fileencoding=utf8 :',
'# coding=utf8' lub '# -*- coding: <encoding name> -*-'), jeśli moduł
zawiera znaki spoza latin1[1] lub jest napisany dla pythona poniżej
wersji 3.0. Zwykle też, jeśli moduł ma być wykonywalny, dodaje się
jego wywołanie w postaci:

def foo():
...

if __name__ == '__main__':
    foo()

Po to, by móc zaimportować ten moduł bez wykonywania kodu w funkcji
foo[2].

> 2. jak pisać testy?

Python ma dwa framweorki w bibliotece standardowej do testowania:
unittest[3] i doctest[4]. Pomijając samo pisanie testów, istnieje
kilka narzędzi do ich znajdowania i uruchamiania, takich jak nosetest
[5] czy do zbierania i generowania raportów pokrycia[6]. Sporo
informacji na temat dostępnych narzędzi znajdziesz też tu[7]

> czy jest pythonowa implementacja TAP?

Jest zalążek TAP [8], ale nie wiem na jakim jest etapie.

> 3. co z polskimi znakami. Z tego co przeczytałem, teksty w apostrfach
> powinny być tylko w latin1, a jak chcę coś innego, to powinienem używać
> notacji u'...' i tam podawać codepointy unikodowe.

Możesz śmiało używać dowolnego kodowania, wystarczy zadeklarować owo
kodowanie na początku pliku (jak już wyżej pisałem) jeśli masz taką
potrzebę.

> i teraz nie wiem - czy źle przecyztałem/zrozumiałem, czy to faktycznie
> tak niewygodne?
> prosty test w python-shellu:
> >>> 'żółw'.upper()
> '\xc5\xbc\xc3\xb3\xc5\x82W'
> >>> print 'żółw'.upper()
> żółW
> >>> print 'żółw'.decode("UTF-8").upper()
> ŻÓŁW
> 
> pokazuje, że używanie utf-8 jest możliwe, ale dosyć upierdliwe (zawsze decode(...)).
> co przegapiłem?

$ cat t.py 
# vim: set fileencoding=utf8 :
print u'żółw'.upper()
$ python t.py
ŻÓŁW

W interpreterze trzeba temu pythonu powiedzieć, jakiego kodowania
używasz. W pythonie3 już nie trzeba, zakłada się, że używany jest
utf8:

$ python3
Python 3.1.4 (default, Oct 24 2011, 16:41:54) 
[GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
'starting up...'
>>> 'żółw'.upper()
'ŻÓŁW'
>>> 


[1] http://www.python.org/dev/peps/pep-0263/
[2] http://effbot.org/pyfaq/tutor-what-is-if-name-main-for.htm
[3] http://docs.python.org/library/unittest.html
[4] http://docs.python.org/library/doctest.html
[5] http://code.google.com/p/python-nose/
[6] http://pypi.python.org/pypi/coverage
[7] http://packages.python.org/testing/
[8] http://git.codesimply.com/?p=PyTAP.git;a=summary

-- 
      -^-  _        coś tam w tle sobie gra, np:
   _ /O)_\//        Clan of Xymox - Stranger
  (_(|__(_(_) grf.  

On 2011-11-21, Roman Dobosz <gryf_esm-no@spam-o2.pl> wrote:
> [1] http://www.python.org/dev/peps/pep-0263/

pepy pojawiają się często/gęsto.
wszystkich jest dużo, więc wizja przeczytania *wszystkiego* przed
zaczęciem pisania jest dosyć abstrakcyjna.
czy są jakieś pepy które trzeba *koniecznie* znać? albo takie, że po
prostu "nie wypada" nie mieć ich przeczytanych?

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/

On Mon, 21 Nov 2011 19:22:26 +0100
hubert depesz lubaczewski <depesz@depesz.com> wrote:

> pepy pojawiają się często/gęsto.
> wszystkich jest dużo, więc wizja przeczytania *wszystkiego* przed
> zaczęciem pisania jest dosyć abstrakcyjna.
> czy są jakieś pepy które trzeba *koniecznie* znać? albo takie, że po
> prostu "nie wypada" nie mieć ich przeczytanych?

IMHO: PEP 8. Podczas pisania kodu zawsze możesz się wspomóc
narzędziami (pylint, pep8, pyflakes), z których większość jest obecna
w popularnych edytorach jako rozszerzenia/wtyczki, pomagając w
pisaniu czytelnego i eleganckiego kodu.

Pozostałe PEPy przydają się czasami jako uzupełnienie dokumentacji.

-- 
      -^-  _        coś tam w tle sobie gra, np:
   _ /O)_\//        Clan of Xymox - A Day (Remix)
  (_(|__(_(_) grf.