7 bites ASCII karakterek a programszövegben és stringliterálokban, 8 bites ASCII karakterek kommentekben és stringliterálokban, de ezek értelmezése platformfüggő. A 8 bites karakterek helyes jelölése a nekik megfelelő oktális vagy hexadecimális escape-szekvenciákkal történik. A futásidőben elérhető karakterkészlet a különböző I/O eszközöktől függ, de általában az ASCII-nál bővebb.
Megjegyzés: csábító lehet pl. ISO 8859 Latin 1 kódolást feltételezni a 8 bites karakterek használatakor, de nem ajánlatos ebbe a csapdába beleesni. Várhatóan hamarosan egyre jobban elterjednek a Unicode szövegszerkesztők, amely szintén ASCII-nál bővebb halmazt reprezentál, de a 128-255 tartományban teljesen más kódolással.
A 2.0 verziótól használhatunk Unicode sztringeket is. Ezeknek az előnye nyilvánvaló az eltérően értelmezhető ISO 8859-? kódolásokkal szemben, hiszen egyértelműen meghatározhatjuk a karaktert, amit használni szeretnénk. Igazán azonban akkor lesz használható, ha olyan szövegszerkesztőt használunk, ami képes megfelelően kezelni Unicode karaktereket például UTF-8 kódolást használva. Sajnos egyelőre még várni kell arra, hogy általánossá váljon a Unicode karakterek, és a viszonylag könnyed átmenetet ígérő UTF-8 kódolás használata.
Unicode sztringeket reprezentáló objektumokat a következőképpen adhatunk meg:
Ezeknek az objektumoknak van egy encode() metódusa, melynek segítségével a sztringet jó néhány kódolással reprezentálhatjuk.
A unicode beépített függvénnyel megadott kódolással unicode sztringet készíthetünk. Például elővarázsolhatunk egy szép Latin-2 -es hosszú ő betűt:
Python sztringekben a '\' karakter jelentése speciális, escape karakterként funcionál. Emiatt, ha például egy reguláris kifejezésben szeretnénk egy '\' karakterre illeszteni, akkor azt a '\\\\' karaktersorozattal tehetjük meg, ami nehezíti olvasható kód készítését. Ilyenkor jól jönnek az ún. nyers sztringek (raw strings), melyekben a \ karakternek nincs speciális jelentése. Például:
Egy Python azonosító aláhúzással vagy betűvel kezdődhet, és utána tetszőleges hosszan állhat aláhúzás, betű vagy szám. Más szavakkal: érvényes Python azonosító az, amire a [a-zA-Z_][a-zA-Z0-9_]* reguláris kifejezés illeszkedik.
A Python VM-ben tárolt kifejezések mérete a 2.0-s verzióval 2^16-ról 2^32-re nőtt.
Nem kell deklarálni a változókat, első használatukkor automatikusan jönnek létre. Ha jobb oldalon hivatkozunk először egy változóra (ami még nem létezik), akkor NameError kivétel váltódik ki. A kis- és nagybetűket megkülönbözteti egymástól.
and, as, assert, break, class, continue, def, del, elif, else, except, exec, finally, for, from, global, if, import, in, is, lambda, not, or, pass, print, raise, return, try, while, with, yield
A
kulcsszavakon kívül bizonyos azonosítóknak speciális jelentésük van:
Azonosítók speciális jelentése |
|
Forma |
Jelentés |
_* |
Nem lett importálva a |
__*__ |
rendszer által definiált név |
__* |
osztályok privát nevei |
A logikai programsorokat egymástól egy NEWLINE token választja el. Az utasítások nem nyúlhatnak át logikai sorhatáron, kivéve, ahol ezt a szintaxis egyébként lehetővé teszi összetett utasításoknál. Egy logikai sor egy vagy több fizikai sorból áll, az explicit ill. implicit sorösszekapcsolási szabályoknak megfelelően.
Explicit szabályok:
Implicit szabályok:
· kölünbőző zárójeles kifejezések folytatódhatnak több fizikai sorban `\' használata nélkül;
· implicit összekapcsolt fizikai sorokban lehet komment;
· a folytatódó fizikai sorok indentációja irreleváns;
· a folytatódó fizikai sorok között nincsen NEWLINE token;
· triplaidézőjeles string is lehet implicit tördelt, ez esetben nem lehet benne komment.
Példák:
A fizikai sor végét platformfüggő karakterkombinációk jelentik (Unix: LF, DOS/Windows: CRLF, Macintosh: CR).
Csak szóközt, TAB-ot, lapdobást és esetleges kommentet tartalmazó sorokat a parser ignorálja (nem generál NEWLINE tokent). Interaktív használatkor az ilyen sorok (``üres'' sorok) értelmezése implmentációfüggő; a standard implementációban egy teljesen üres sor (whitespace és komment nélküli sor) terminál egy többsoros utasítást.
Nincs se BEGIN-END, se { } zárójelpár, ezért tömörebb, (rövid áttérés után) könnyebben olvasható kódot eredményez. A sor eleji whitespacek száma (indentációs szint) határozza meg azt, hogy az adott sor (utasítás) melyik blokkhoz tartozik. Először a TAB karakterek cserélődnek (balról jobbra) szóközökre úgy, hogy az összes lecserélt karakterek száma 8 többszöröse legyen. A sorban első nem-szóköz karaktert megelőző szóközök száma adja az adott sor indentációs szintjét. Indentáció nem terjedhet ki több fizikai sorra a `\' használatával; az első `\'-ig terjedő whitespace játszik szerepet az indentációs szint meghatározásában. A sor legelején álló lapdobás az indentációs szint kiszámításában nem játszik szerepet. Bárhol máshol a bevezető whitespace-ben előforduló lapdobás nem definiált hatású (pl. előfordulhat, hogy az eddig számolt szóközök számát lenullázza).
Megjegyzés: nem tanácsos szóközöket és TAB-okat keverni az indentációban. Más platformon a nem-Unix jellegű értelmezésből adódóan nagy kavarodás állhat elő.
Egymást követő sorok indentációja INDENT és DEDENT tokeneket generál egy verem használatával. Kezdetben a verem csak egy nullát tartalmaz, amit a parser a továbbiakban sosem vesz ki. A későbbiekben veremben elhelyezett értékek szigorúan monoton növekvő sorrendben lesznek. Minden logikai sor elején az adott sor indentációs szintjét a parser összehasonlítja a verem tetején lévő értékkel. Amennyiben egyeznek, semmi nem történik. Ha az adott sor indentációs szintje nagyobb, akkor az érték bekerül a verembe és egy INDENT token generálódik. Ha kisebb, akkor ennek az értéknek szerepelnie kell a veremben; az összes ennél nagyobb érték kikerül a veremből és mindegyikhez generálódik egy DEDENT token. A program végén a veremben lévő 0-nál nagyobb értékek mindegyikéhez generálódik egy DEDENT token.
Az indentációs szintek inkozisztenciájából eredő hibákat a parser és a lexikális elemző együttes munkája deríti ki.
A következő programrészlet pl. szintaktikus hibát eredményez:
Így például a csellengő else probléma egy különös megoldását láthatjuk:
A beljebbkezdéseknek nincs fix mérete, de a kiljebbkezdéseknek konzisztensnek kell lenni. Példa hibás Python kódra rossz beljebb- ill. kiljebbkezdések miatt:
Logikai sorok elejének és stringliteráloknak a kivételével mindenhol használható whitespace különböző tokenek elválasztására. Két token között akkor van szükség whitespace-re, ha a tokenek összekapcsolása egyébként legális tokent eredményezne. NEWLINE, INDENT, DEDENT tokeneken kívül a következő katégióriák vannak még: azonosító, kulcsszó, literál, operátor, elhatároló. A whitespace nem számít tokennek. Ahol ambiguitás lépne fel, a leghosszabb token elve érvényesül.
Nem stringliterálban szereplő `#' karakterrel kezdődő sorok, fizikai sorvégig tart. Ez logikai sorvégét is jelent, kivéve az implicit szabályok alkalmazásánál fellépő eseteket. A kommentek nem részei a szintaxisnak, nem generálnak tokent. Nincs blokk jellegű komment.
Függvény-, illetve osztálydefinícó után közvetlenül következő sorban lévő első sztring literál az adott osztály dokumentációs kommentje. Ez tetszőleges módon megadható, ahogy egy sztringet Pythonban megadhatunk (szimpla, tripla idézőjelek, aposztrófok). Ez azért speciális, mert ez tulajdonképpen nem komment, hanem stringliterál. A Python parser nem szedi ki a benne lévő indentációt, ezt a dokumentációs stringet feldolgozó segédprogramoknak kell megtenniük. A dokumentációs stringre lehet hivatkozni:
String- és numerikus literálokról beszélhetünk.