🚀 go-pugleaf

On 2 Cze, 22:55, jarek.ro...@gmail.com wrote:
> Zaczynam dopiero przygode z pythonem (niestety z nawykami z innych
> jezykow). Poszukuje jakiegos wzorcowego projektu w pythonie, zeby
> zobaczyc, jak powinno sie podzielic aplikacje na obiekty/pliki/
> katalogi/itd.

IMHO istnieje wiele ,,nawykow'' z innych jezykow, ktore nawet w
Pythonie
pomagaja. Wiele osob, gdy pisze jakis powazniejszy projekt w Pythonie
(a nie jakis
prosty skrypt) to staram sie trzymac jedna klase w jednym pliku.

Proponuje osobny plik na kazda klase.
Katalog niech reprezentuje "pakiet".
Np.
graphics/Point.py
graphics/Square.py
graphics/Circle.py
graphics/__init__.py

W plikach {Point,Square,Circle}.py
tylko importy i jedna klasa.

A w tym ostatnim pliku np.  (przypominam, ze ten plik, chocby pusty,
musi
istniec):
#!/usr/bin/env python

from Point import Point
from Square import Square
from Circle import Circle

W ten sposob z innego modulu mozesz po prostu:
import graphics
i odwolywac sie przez graphics.Point
(a nie np. graphics.Point.Point :-))

Oczywiscie mozesz miec 1 plik graphics/Objects.py
z klasami Point, Square, Circle. Wtedy w graphics/__init__.py:
from Objects import Point, Square, Circle


> Jakbyscie zaczeli projekt prostej aplikacji do katalogowania
> posiadanych ksiazek ?
> [wiem, ze przyklad zenujacy, ale przynajmniej dziedziny zagadnienia
> nie trzeba tlumaczyc :-)]
> Aplikacja bedzie okienkowa, GUI w QT, prosta baza danych z
> wykorzystaniem SQLite, powiedzmy, ze obejdziemy sie bez ORMow.

2 moduly/pakiety:
(1) logika przetrzymywania ksiazek,
(2) GUI

gdzie w GUI po prostu przekazujesz dane z/do (1)

Ja bym zaczal od (2) -- ale zaraz potem zaczal rowniez (1),
zeby po jakims czasie juz cos dzialalo i zebys z poziomu GUI
wiedzial co dokladnie w (1) musisz zaimplementowac
(chyba, ze juz wiesz, bo masz jakies dokladne wytyczne itp.)

Mozesz tez najpierw po prostu wykonac (1)
(to raczej nie jest az takie duze zadanie).
Jak sie juz upewnisz, ze (1) dziala (testy), robisz (2).

>
> jak rozmiescic w projekcie klasy do obslugi bazy, gui, reprezentujace
> autorow, ksiazki, kategorie, itd?

db/Db.py
db/Author.py
db/Book.py
db/Category.py

gui/nie_wiem, zalezy od biblioteki, na QT sie nie wyznaje:)

>
> czy powinienem robic powiedzmy katalog database i w nim __init__.py,
> czy tez po prostu Database.py?

Zalezy co (ile) ma w nim byc.
Zauwaz, ze jesli najpierw zdecydujesz sie na pojedynczy modul,
np. database.py, a potem stwierdzisz, ze chcesz miec to w wielu
plikach,
to robisz katalog database/, wgrywasz tam obecny database.py, tworzysz
plik database/__init__.py z:
from database import *
i powinno dzialac :-)

> czy powinienem dla autorow, ksiazek, kategorii robic oddzielne pliki z
> klasami czy wszystkie te klasy wrzucic do jednego pliku?

moim zdaniem to zalezy jak duze beda to klasy.
na poczatku moga byc w jednym.
jak zacznie Ci to przeszkadzac, to przerzuc do wielu.

> jaki macie pomysl na zapis, odczyt dla obiektow autora, ksiazki, itd,
> na sztywno select/insert/update, czy tez moze klasa powinna
> przechowywac nazwe tabeli i liste atrybutow i za pomoca getattr,
> setattr i generowanych zapytan wczytywac i zapisywac dane?

Skoro to projekt do nauki, to moze sam pomyslisz jak to zrobic.
Mozesz zrobic na oba sposoby i potem wyciagnac wnioski.

>
> jak przekazywac polaczenie do bazy, bo wypadaloby gdzies na podstawie
> konfiguracji stworzyc jedno i pozniej je wszedzie uzywac. Czy
> przekazywac w kazdej jednej metodzie obiekt, czy jakos globalnie go
> udostepnic [jesli globalny obiekt jest ladnym rozwiazaniem, to jak to
> zrobic, zeby w roznych plikach to polaczenie bylo widziane]?

stworzyc i zainicjowac obiekt reprezentujacy polaczenie z db.
nastepnie przekazywac ten obiekt do innych obiektow
potrzebujacych db poprzez np. konstruktor.

[jesli chcesz jakies globalne rozwiazanie, to stworz modul globals, do
ktorego
bedziesz zapisywal/odczytywal dane. ale to nie jest ladne :P]

> Pozdrawiam!

rowniez pozdrawiam
pw

On 2 Cze, 22:55, jarek.ro...@gmail.com wrote:
> Witam!

Czesc, ja tak ogolnie:

> Zaczynam dopiero przygode z pythonem (niestety z nawykami z innych
> jezykow).

najpierw zapoznaj sie z manualem pythona (pakiety, moduly - rozdzial
6), to udzieli ci odpowiedzi na pytania ile/jakie klasy w ktorym/ilu
plikach.

> czy robienie "nakladki" na polaczenie do bazy, ktore zawierac bedzie
> metody powiedzmy begin(),commit(),rollback() do obslugi transakcji,
> execute(...) do wykonywania sql nie zwracajacych wynikow, select(...)
> do zwracania danych z selectow w postaci listy wierszy, jest dobrym /
> zlym nawykiem? Powinno sie opakowac taki "surowe" dbapi, czy tez
> bezposrednio w kodzie klepac dbapi, czyli .connect, .cursor, .execute
> itp?

dbapi ma ustandaryzowany interfejs (PEP 249), wiec niezaleznie do
jakiego silnika sie laczysz, api jest takie samo.

> jak przekazywac polaczenie do bazy, bo wypadaloby gdzies na podstawie
> konfiguracji stworzyc jedno i pozniej je wszedzie uzywac.

dobrym sposobem jest rejestr konfiguracji (dane o polaczeniach)  i
jakis obiekt application context (dyspozytor/fabrykant polaczen)

> jaki macie pomysl na zapis, odczyt dla obiektow autora, ksiazki, itd,
> na sztywno select/insert/update, czy tez moze klasa powinna
> przechowywac nazwe tabeli i liste atrybutow i za pomoca getattr,
> setattr i generowanych zapytan wczytywac i zapisywac dane?

imho najlepiej uzyc jakiegos orm`a. dobrego orm`a, jak sqlalchemy.


> Pozdrawiam!
> Jarek

marcin

Uzytkownik "marcinn" <marcin.j.nowak@gmail.com> napisal w wiadomosci 
news:8baddb38-5766-4b5f-90ca-a8fc063e231d@h18g2000yqj.googlegroups.com...
> On 2 Cze, 22:55, jarek.ro...@gmail.com wrote:
>> Witam!
>
> Czesc, ja tak ogolnie:
>
>> Zaczynam dopiero przygode z pythonem (niestety z nawykami z innych
>> jezykow).
>
> najpierw zapoznaj sie z manualem pythona (pakiety, moduly - rozdzial
> 6), to udzieli ci odpowiedzi na pytania ile/jakie klasy w ktorym/ilu
> plikach.
>
>> czy robienie "nakladki" na polaczenie do bazy, ktore zawierac bedzie
>> metody powiedzmy begin(),commit(),rollback() do obslugi transakcji,
>> execute(...) do wykonywania sql nie zwracajacych wynikow, select(...)
>> do zwracania danych z selectow w postaci listy wierszy, jest dobrym /
>> zlym nawykiem? Powinno sie opakowac taki "surowe" dbapi, czy tez
>> bezposrednio w kodzie klepac dbapi, czyli .connect, .cursor, .execute
>> itp?
>
> dbapi ma ustandaryzowany interfejs (PEP 249), wiec niezaleznie do
> jakiego silnika sie laczysz, api jest takie samo.
>
>> jak przekazywac polaczenie do bazy, bo wypadaloby gdzies na podstawie
>> konfiguracji stworzyc jedno i pozniej je wszedzie uzywac.
>
> dobrym sposobem jest rejestr konfiguracji (dane o polaczeniach)  i
> jakis obiekt application context (dyspozytor/fabrykant polaczen)
>
>> jaki macie pomysl na zapis, odczyt dla obiektow autora, ksiazki, itd,
>> na sztywno select/insert/update, czy tez moze klasa powinna
>> przechowywac nazwe tabeli i liste atrybutow i za pomoca getattr,
>> setattr i generowanych zapytan wczytywac i zapisywac dane?
>
> imho najlepiej uzyc jakiegos orm`a. dobrego orm`a, jak sqlalchemy.
>

He, ale sqlalchemy nie potrafi (albo ja) zrobic sesji 
master-detail-subdetails, mapper dziala fajnie dla relacji jeden-do-wiele 
przy jednokrotnym zlaczeniu.


>
>> Pozdrawiam!
>> Jarek
>
> marcin 

Grzegorz Czekaj:
> He, ale sqlalchemy nie potrafi (albo ja) zrobic sesji
> master-detail-subdetails, mapper dziala fajnie dla relacji jeden-do-wiele
> przy jednokrotnym zlaczeniu.

A eagerload_all() nie wystarczy? Albo odpowiednia konfiguracja relacji?

.pk.

Wlasnie potrzebuje jakis przyklad dla relacji, co eagerload_all nadaje sie 
do query, a ja chce zrobic cos takiego:
a = Tabela1Obj(..)
a.pozycja.append(Tabela2Obj(...))
for i in mojeListStore:
    a.pozycja.subpozycja.append(Tabela3Obj(..))
session.add(a)
session.commit()

Pozdr
Gcz

Uzytkownik "Piotr Keplicz" <keplicz@bigfoot.com> napisal w wiadomosci 
news:h05qun$m6k$1@nemesis.news.neostrada.pl...
> Grzegorz Czekaj:
>> He, ale sqlalchemy nie potrafi (albo ja) zrobic sesji
>> master-detail-subdetails, mapper dziala fajnie dla relacji jeden-do-wiele
>> przy jednokrotnym zlaczeniu.
>
> A eagerload_all() nie wystarczy? Albo odpowiednia konfiguracja relacji?
>
> .pk.
>