News

Aggiornamento del forum in corso, ne leggete qui: http://www.python-it.org/forum/index.php?topic=7051.0.

Topic: Web2Py vs. Django: Fight!  (Letto 3876 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline Markon

  • python sapiens sapiens
  • *
  • moderatore
  • Post: 4087
  • Punti reputazione: 5
    • Mostra profilo
    • Markon blog
Re: Web2Py vs. Django: Fight!
« Risposta #15 il: Febbraio 28, 2011, 08:44 »
Citazione
Per il sondaggio, e' una cosa che trovo misteriosa e distinta. Da un lato trovo strano che ci siano cosi' tanti utenti che votano web2py e *non* partecipano. Non fanno domande, non postano esempi. Come se non esistessero. In quest'ottica c'e' da pensare che qualcuno di pesantemente malato fa una roba del genere. Malato a livelli imbarazzanti. Pero' ecco, aspetterei prima di trarre collegamenti a lungo raggio.

...mah, ormai non mi scandalizza più nulla...  :thinking:
Possibile, certo, che qualcuno si sia confuso con web.py, questo va detto.
Però torniamo allo stesso discorso: chi sono questi utenti?

Offline ubuntu_of_fortune

  • python sapiens
  • *
  • moderatore
  • Post: 745
  • Punti reputazione: 3
    • Mostra profilo
Re: Web2Py vs. Django: Fight!
« Risposta #16 il: Febbraio 28, 2011, 21:16 »
Allora, la cosa interessante dal mio punto di vista era la discussione; al di la del fatto che al di la dei pregi/difetti di Web2py Mi sembra evidente che scrivere un altro linguaggio "python like" al 99%, seppur apparentemente non un gran problema, non e' comunque una buona idea.
Se non altro perche' se piu' persone lo facessero, diventerebbe un macello completo.

Esatto. Mi trovo perfettamente d'accordo con questa interpretazione - che poi e` la stessa di Kaplan-Moss
Un modo di fare in questa maniera ha il solo effetto di frammentare ancora di piu` la comunita` e quello che ne paga le conseguenze alla fine di tutto e` il Python stesso.

Io - ora - non conosco web2py (e vista questa presentazione, non credo che mi impegnero` piu` di tanto per approfondirlo) quindi non posso esprimere pareri tecnici di confronto ma, quel modo di programmare lo trovo assolutamente *assurdo* IMHO.
Inoltre, dico la mia dopo che ho letto del codice web2py per la prima volta:
"Giudizio: poco intuitivo! Non si capisce minimamente cosa faccia un frammento di codice senza sapere da dove arrivano le funzioni, gli oggetti, le variabili - un minimo di reverse engineering all'indietro cosi` e` impossibile. L'unica alternativa e` la ricerca esaustiva se non si conosce il codice di web2py.

Mi trovo assolutamente d'accordo (e sottoscrivo mille volte) con quello detto da JKM sul fatto che una programmazione siffatta e` assolutamente fuorviante - soprattutto per Python. In Python *non* si programma in questo modo e chi lo fa` e` additato come niubbo o come "cattivo programmatore" (a.k.a. il fullsystem/d_traveler della situazione).
In web2py questa e` la regola e questo non e` bene in quanto molti fanno il salto - web frameworks --> Python e in questo modo si aspetterebbero di programmare allo stesso modo.
Io in primis, ho iniziato ad utilizzare Python in modo "serio" (siete liberi anche di ridere :P) e ad approfondire le features del linguaggio proprio grazie a Django - che e` Python.
Avessi iniziato con web2py sarei stato disorientato!

La cosa triste e' come si e' polarizzata la discussione: tra l'altro i supporter di web2py aggressivissimi. Direi piu' di Massimo stesso.

Si infatti! Si sono rivolti proprio male e "sprucidi" - che significherebbe "antipatici", un'altra parola da aggiungere insieme a "pezzottato" alla lezione di NapoletanoFacile2Riko iniziata da Markon :D
C'e` pero` forse un minimo da "capirli". Stando a quanto dice Max Di Pierro, su Reddit la comunita` web2py e` sempre stata snobbata e criticata - quindi lo sca**o ad ogni minima cosa ci sta pure.
Non li giustifico pero`!

EDIT: Grazie riko per lo spunto di discussione! ;)

Offline ubuntu_of_fortune

  • python sapiens
  • *
  • moderatore
  • Post: 745
  • Punti reputazione: 3
    • Mostra profilo
Re: Web2Py vs. Django: Fight!
« Risposta #17 il: Febbraio 28, 2011, 21:19 »
Citazione
Per il sondaggio, e' una cosa che trovo misteriosa e distinta. Da un lato trovo strano che ci siano cosi' tanti utenti che votano web2py e *non* partecipano. Non fanno domande, non postano esempi. Come se non esistessero. In quest'ottica c'e' da pensare che qualcuno di pesantemente malato fa una roba del genere. Malato a livelli imbarazzanti. Pero' ecco, aspetterei prima di trarre collegamenti a lungo raggio.

...mah, ormai non mi scandalizza più nulla...  :thinking:
Possibile, certo, che qualcuno si sia confuso con web.py, questo va detto.
Però torniamo allo stesso discorso: chi sono questi utenti?

Secondo me` e` possibile - molto possibile! Ma il problema resta.... BAH!

Fosse così riko non rischierebbe un malore leggendo una variabile globale.  :party:
Eh ma mi sa pure Alfredo vista la sua firma :P

Offline billiejoex

  • python sapiens
  • *****
  • Post: 522
  • Punti reputazione: 1
    • Mostra profilo
Re: Web2Py vs. Django: Fight!
« Risposta #18 il: Marzo 01, 2011, 04:42 »
http://www.reddit.com/r/Python/comments/ex54j/seeking_clarification_on_pylonsturbogearspyramid/c1bo1v5

Sinceramente trovo abbastanza imbarazzante che non si sia accorto che lui per primo con le sue parole ha ammesso che Kaplan-Moss ha ragione.

There are keywords that cannot be renamed. Python defined if, else, try, in, etc. Web2py adds DAL, Field, request, response, session, cache, T, validators and helpers.

Urgh! Qua si superano addirittura certe brutture di Plone/Zope. =)
A parte tutto, problemi simili a questo li ho riscontrati un po' ovunque nel mondo dei web framework legati a Python.
Tutti quelli in cui mi sono imbattuto (zope, plone, grok e un po' di django) tendono a fare le cose a modo loro, dove per "modo loro" intendo un approccio non pythonico e ognuno totalmente a sè stante, che personalmente mi irrita non poco e non mi diverte particolarmente averci a che fare.

In generale (e qui magari scateno un flame) la mia percezione è che gli sviluppatori che stanno dietro a questi progetti non sono pythonisti veri e propri, quanto professionisti principalmente legati al web che solo in un secondo tempo si sono avvicinati a python e hanno infine deciso di legare le due cose.

Ad oggi io credo che il web sia una delle poche nicchie in cui python ancora deve dire veramente la sua.
Dico questo *non* avendo ancora approfondito django, ma il mercato dei CMS, per dirne una, a parte Plone non offre nient'altro, il che è un problema.

Citazione
Io in primis, ho iniziato ad utilizzare Python in modo "serio" (siete liberi anche di ridere ) e ad approfondire le features del linguaggio proprio grazie a Django - che e` Python.
Avessi iniziato con web2py sarei stato disorientato!

IMHO, lo sei anche con Django. Tali framework introducono un insieme di concetti, astrazione, black-magic e tipo di approccio che non esistono altrove per cui effettivamente ti ritrovi a "programmare in django/zope/webpy/[altro]" anzichè in python vero e proprio.
Non mi pronuncio su Django nello specifico, ma per citare una realtà con cui sono a contatto, posso dire di conoscere diverse persone che sono ottimi Plonisti / Zope-isti ma mediocri programmatori Python.
Che poi a uno piaccia fare web con python ben venga, anzi; quello che voglio dire è che esiste una separazione abbastanza marcata tra i due mondi *python* e *web*.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7317
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: Web2Py vs. Django: Fight!
« Risposta #19 il: Marzo 01, 2011, 11:35 »
A parte tutto, problemi simili a questo li ho riscontrati un po' ovunque nel mondo dei web framework legati a Python.
Tutti quelli in cui mi sono imbattuto (zope, plone, grok e un po' di django) tendono a fare le cose a modo loro, dove per "modo loro" intendo un approccio non pythonico e ognuno totalmente a sè stante, che personalmente mi irrita non poco e non mi diverte particolarmente averci a che fare.

Allora su zope e plone concordo con te. Pero' devo dirti che IMHO Django *non* e' su questa strada.
L'unico posto in cui fa un po' di black magic (a quanto ricordo) e' *esclusivamente* il PYTHONPATH, ma *non* importando roba, semplicemente lavorando sulle directory dove si trovano i py.

Pero' devo dire, e' tanto che non ci lavoro. Anche io, come te, non sono un estremo amante dello sviluppo web.

Citazione
In generale (e qui magari scateno un flame) la mia percezione è che gli sviluppatori che stanno dietro a questi progetti non sono pythonisti veri e propri, quanto professionisti principalmente legati al web che solo in un secondo tempo si sono avvicinati a python e hanno infine deciso di legare le due cose.

Non saprei. Io credo che la questione sia molto piu' complicata. All'epoca io ero appena entrato nella community... comunque Zope (2) e' un progetto vecchissimo. Zope 3 e' del 2004, per dire. Zope 2 e' molto piu' vecchio. Quello che e' oggi "buon Python" 13 anni fa non si scriveva in quel modo. Molte delle cose che siamo per garantite oggi, all'epoca non c'erano.

Visto con gli occhi di oggi, Zope e' un carrozzone sovraingegnerizzato: non dimentichiamo che e' roba di 10 anni fa, pero'. Cioe' all'epoca si andava ancora a botte di CGI oppure c'era quel cesso di PHP. Beh, anche i vari Java stuff di fatto nel 1998 non esistevano come li concepiamo oggi.

XP era una buzzworld che faceva parlare il mondo del software engineering. Scrivere come si scrive oggi Python era quasi impensabile. Per dire per Zope Corp c'e' passato anche GvR.

Poi ovviamente Zope 3 e' arrivato, e IMHO non ha mantenuto e non ha fatto quello che andava fatto (che e' stato poi fatto da Django molti anni dopo). Ma forse pretendo troppo... diciamo che se Zope3 fosse stato quello che avrebbe dovuto, avremmo battuto sul tempo Rails. Poi la mia idea e' che la Zope community (in questo sono con te) sia pesantemente diversa dalla Python community: Django non sarebbe piaciuto all'epoca.

Zope 3 e' molto piu' enterprisey. Direi che qui e' chiaro che uno zopista non e' un Pythonista:

Citazione da: Zope-Wiki
Python is a dynamically typed language and class definitions are not protected. By introducing interfaces a promise is made by any Class that declares that it implements a given interface to actually implement that interface. Python being a dynamic language, it is possible to implement only part or even none of an interface and still declare that an interface is provided by that Class. Sometimes this is done as a convenience in the prototyping phase of development, but feature complete code should always implement the full interface as declared. Any Zope 3 developer who is providing a baseline guarantee of quality for their code will always implement the full interface that they are declaring, as well as provide a level of assurance that the implementation is correct through automated testing suites.

In fact the interface solution is quite elegant. Because - by virtue of a shortcoming in Python, one could argue - Zope 3 now has a standard convention for components to expose their interfaces.

Other computer languages have the option of stricter class definitions - but many frameworks would actually benefit from such an interface specification.

I hope this helps you understand Zope 3 interfaces. To study how to implement them see ZopeGuideInterfaces.

Citazione
Ad oggi io credo che il web sia una delle poche nicchie in cui python ancora deve dire veramente la sua.
Dico questo *non* avendo ancora approfondito django, ma il mercato dei CMS, per dirne una, a parte Plone non offre nient'altro, il che è un problema.

Io invece non sono d'accordo su questo, mentre sul resto sono d'accordo. Nel Web Python *ha* detto la sua con Django. Django e' allo stato dell'arte; fra Django e Rails e' una pura scelta di gusto. Io posso dire che IMHO entrambi sono prodotti di alta qualita' per fare web. Per avere qualcosa che mi piace di piu', bisogna andare nel mondo funzionale... ma e' roba un po' troppo per lo sviluppatore comune.

Una volta Python era un linguaggio di eccellenza: ci arrivavano praticamente solo le elite, frustrate dalle menate degli altri linguaggi ad oggetti.

Guarda questo articolo:
http://www.paulgraham.com/pypar.html

Oggi, spesso non e' piu' cosi'. Molte persone arrivano a Python ma *non* sono Pythonisti nell'animo. E scrivono PHP anche in Python.
In questo senso il web e' quello che ha tirato Python fra i linguaggi piu' usati al mondo, ma e' anche quello che sta allargando la base d'utenza a persone che *non* sono Pythonisti.

Altro che dire la sua insomma... purtroppo questo sara' un problema per la community in the large: non siamo in grado di assorbire cosi' tanta gente sotto-skillata.



Citazione
IMHO, lo sei anche con Django. Tali framework introducono un insieme di concetti, astrazione, black-magic e tipo di approccio che non esistono altrove per cui effettivamente ti ritrovi a "programmare in django/zope/webpy/[altro]" anzichè in python vero e proprio.
Non mi pronuncio su Django nello specifico, ma per citare una realtà con cui sono a contatto, posso dire di conoscere diverse persone che sono ottimi Plonisti / Zope-isti ma mediocri programmatori Python.
Che poi a uno piaccia fare web con python ben venga, anzi; quello che voglio dire è che esiste una separazione abbastanza marcata tra i due mondi *python* e *web*.

Dipende cosa intendi: in un certo senso *ogni* comunita' che non e' pure Python e' un mondo a parte. Pensa pygame. La maggior parte dei progetti pygame *non* sono buon Python. Pensa a quelli che fanno GUI: pensa alle porcate che si leggono.

Eppure... e' tutto parte dell'ecosistema Python in the large. E in particolare il mondo di Django non e' particolarmente lontano dalla filosofia di Python, anzi.

Dopo di che ci sono determinati concetti, astrazioni e compagnia che *sono* parte del web. Come altri concetti sono parte del mondo delle gui, altri ancora di quello della programmazione di videogiochi. Ci sono poi le astrazioni che sono parte dello sviluppo di sistemi diversi ancora...

E Python e' molto versato nella black magic: basta isolarla per bene. Posso dire che fare certe cose senza black magic finisce per generare codice non DRY.

Offline ubuntu_of_fortune

  • python sapiens
  • *
  • moderatore
  • Post: 745
  • Punti reputazione: 3
    • Mostra profilo
Re: Web2Py vs. Django: Fight!
« Risposta #20 il: Marzo 01, 2011, 12:54 »
...
Quoto riko per intero. Sono pienamente d'accordo con la sua interpretazione!


A parte tutto, problemi simili a questo li ho riscontrati un po' ovunque nel mondo dei web framework legati a Python.
Tutti quelli in cui mi sono imbattuto (zope, plone, grok e un po' di django) tendono a fare le cose a modo loro, dove per "modo loro" intendo un approccio non pythonico e ognuno totalmente a sè stante, che personalmente mi irrita non poco e non mi diverte particolarmente averci a che fare.

A tal proposito mi permetto di fare una distinzione IMHO importante nel confronto Zope/web2py/Django
Zope ha introdotto il concetto di interfacce, cosa che non e` il "classico Python" (non sono tecnico di Zope ma la citazione di Riko a riguardo spiega tutto)
web2py ha introdotto pesantemente l'uso delle globals, cosa che in Python non si fa/non e` buona cosa fare - sul resto non mi addentro perche` non so.

In entrambi i casi sopra citati, si tratta di "fare a modo proprio" delle cose *non* supportate/*non* usuali per Python - quindi sono scelte di Design che influenzano il modo di programmare in Python direttamente.

Al contrario, Django ha fatto a modo suo per l'ORM e per il linguaggio di templating.
Sull'ORM, le motivazioni possono essere le piu` disparate e siamo d'accordo che e` stata una scelta discutibile - l'ORM di Django, infatti, e` stato per lungo tempo una limitazione forte per le sue funzionalita`. E su certe cose, lo e` ancora.

Per quanto riguarda il templating, Django ha fatto una scelta molto precisa: No Python code nei template - Scelta che condivido a pieno! - ma questa e` un'altra storia!
In entrambi i casi, Python non ne risente - ragione per cui, come riko, non metterei in mezzo Django insieme a Zope e Web2py
Rafforzo, infine la mia tesi, citando il summa theologiae Pythonico:
Citazione da: Zen Of Python
Special cases aren't special enough to break the rules.
(e per web2py)
Namespaces are one honking great idea -- let's do more of those!

Dico questo *non* avendo ancora approfondito django, ma il mercato dei CMS, per dirne una, a parte Plone non offre nient'altro, il che è un problema.
Sul fatto che non ci sia la stessa esplosione di CSM in Python come in PHP, secondo me e` un bene e non un male.
Inoltre il bacino di utenze in questa maniera sarebbe, a maggior ragione, sotto-skillato.
A differenza di PHP, in Python c'e` un proliferare di frameworks e non di CMS e forse questo non e` troppo un bene.
Qui, il summa theologiae mi viene ancora in soccorso:
Citazione
There should be one-- and preferably only one --obvious way to do it.
Posso dire che i diversi web frameworks non sono altro che un ventaglio di possibilita` a disposizione degli *sviluppatori*.
Forse e` questa la differenza piu` grande. Per PHP, il ventaglio di scelta e` a disposizione degli *end-user* - le differenze, sono principalmente in come sono organizzati
i contenuti e quanto e` semplice customizzare/estendere i CMS.
Per i web-frameworks, le limitazioni sono nelle funzionalita` offerte dal framework.

Infine, chiudo sulla questione dicendo che forse, una ragione per la mancanza di CMS Pythonici puo` essere ricondotta anche al fatto che i servizi di hosting che supportano Python sono ancora in minoranza rispetto alla controparte PHP. Anzi, il supporto a linguaggi come Ruby e Python sul web da parte degli hosting e` venduto come novita` e special-case - con un considerevole guadagno in piu` rispetto al classico PHP.

IMHO, lo sei anche con Django. Tali framework introducono un insieme di concetti, astrazione, black-magic e tipo di approccio che non esistono altrove per cui effettivamente ti ritrovi a "programmare in django/zope/webpy/[altro]" anzichè in python vero e proprio.

Su questo non sono d'accordo. Spiego meglio cosa intendevo dire e come la penso a riguardo.
Sul fatto che si stia utilizzando un web framework per programmare/realizzare una web app, sono d'accordo che non si sta "ufficialmente" programmando in Python ma si sta programmando con le regole del web framework. Questo, imho, e` inevitabile ed e` intrinseco proprio nel concetto di Web framework.
Utilizzare un framework, significa inevitabilmente, rispettare tutte le scelte di design del framework stesso - inoltre il *Convention over Configuration* di RoR rappresenta oramai un dictat in questo mondo.
Quello che intendevo dire, pero` era che, Django puo` essere lo spunto per approfondire come sono realizzate certe funzionalita` - Auth, ORM, Form.
Se si va a spulciare un po` di internals, quello che si trova e` pura e semplice programmazione Python - fatta come la farebbe un programmatore Python.
Quindi nessuna interfaccia, nessun utilizzo delle globals.

E` naturale dire che se programmi con Django *non* stai programmando in *pure Python*. Ma se approfondisci come *Django* e` stato fatto - con uso si polimorfismo e metaclassi, basta ad esempio dare un'occhiata a come sono fatte le form - ti rendi conto di come implementare concretamente alcune cose in Python e avere al contempo lo spunto necessario per poterle estendere/riutilizzare rimanendo sempre compliant con il modo di programmare del lingauggio.
(Spero di aver chiarito bene cosa intendevo).
Di contro aggiungo (e concludo) che il tuo ragionamento allora puo` essere esteso a qualsiasi framework - non necessariamente web - scritto in Python o in qualsiasi altro linguaggio. Quindi, utilizzare l'ambiente delle servlet in Java o JSP, non e` programmare in Java perche` c'e` sempre il bias della tecnologia specifica che si sta utlizzando. Sei d'accordo?

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7317
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: Web2Py vs. Django: Fight!
« Risposta #21 il: Marzo 01, 2011, 17:02 »
Aggiungo sul fatto che forse ho male interpretato il pezzo che ho citato di Zope.
Loro parlano di *components*, non di objects. Purtroppo la mia ignoranza su zope non mi permette di avere il contesto.

Avere un'interfaccia sui componenti mi sembra abbastanza accettabile e lightweight (e quante volte abbiamo scritto in casa qualcosa che fa circa quel mestiere?). Avere un'interfaccia sugli oggetti mi sembra di tornare a Java. E se devo lavorare in Java, lavoro in Java.

Offline billiejoex

  • python sapiens
  • *****
  • Post: 522
  • Punti reputazione: 1
    • Mostra profilo
Re: Web2Py vs. Django: Fight!
« Risposta #22 il: Marzo 01, 2011, 18:01 »
Citazione
Allora su zope e plone concordo con te. Pero' devo dirti che IMHO Django *non* e' su questa strada.

Ne sono felice.

Citazione
Dipende cosa intendi: in un certo senso *ogni* comunita' che non e' pure Python e' un mondo a parte. Pensa pygame. La maggior parte dei progetti pygame *non* sono buon Python. Pensa a quelli che fanno GUI: pensa alle porcate che si leggono.

Si, hai ragione.

Citazione
Zope ha introdotto il concetto di interfacce, cosa che non e` il "classico Python" (non sono tecnico di Zope ma la citazione di Riko a riguardo spiega tutto)

zope.interface, componenti e compagnia sono solo uno degli aspetti per cui Zope è tanto anti-pythonico e isolato dal resto dell'ecosistema python.
Non è l'aspetto per cui mi sento di condannarlo maggiomente dato che comprendo i benefici di tale approccio (anche se mentalmente lo trovo parecchio ostico) ma è un dato rilevante che la dice lunga sullo spirito che sta dietro al progetto che si può riassumere in: "facciamo le cose a modo nostro", e il "modo nostro" non esiste altrove, appunto.
Tra questi posso citare ZCA, ZCML, ZMI, ZODB, restricted python, massiccio uso di XML, DTML e buildout, anche se in maniera più marginale.
Chiunque si ritrova di fronte a questo mondo per la prima volta, come io 2 anni fa, semplicemente cade in depressione perchè:

1 - una precedente conoscenza di python, se presente, è quasi inutile, imo - tutte queste cose, a eccezione magari di buildout, non le ha mai viste altrove
2 - la documentazione è molto scarsa e sparsa un po' ovunque e lo spirito a riguardo molto semplicemente è: "se non sai come fare una cosa greppa nei sorgenti"

Una cosa che mi ha colpito particolarmente quando iniziai fu il fatto che (in Zope 2 mi pare, forse in Zope 3 non più) una vista non è visualizzabile finchè non la corredi di docstrnig.
Come esempio magari è stupido, ma secondo me la dice lunga riguardo questa tendenza di fare le cose a modo proprio e di spingere l'utente a programmare in zope anzichè in python.

Citazione
Sul fatto che non ci sia la stessa esplosione di CSM in Python come in PHP, secondo me e` un bene e non un male.

Sono d'accordo, ma chi necessita di un CMS ad oggi non può far altro che buttarsi su Plone, e portandosi dietro Zope un'alternativa farebbe sicuramente comodo per chi con Zope non vuole averci a che fare.
In Plone ti porti dietro tutto il mondo di Zope con in aggiunta un ulteriore layer ("from plone import ....") che non riesce (ma probabilmente neanche vuole) ad astrarre tutta la complessità sottostante e anzi, ne aggiunge di nuova.
Detto questo, le funzionalità di Plone in quanto CMS sono davvero notevoli, e più di una volta sono rimasto sorpreso dalle possibilità che offre.
Se ci fosse una seconda alternativa con funzionalità CMS analoghe e un "core" più semplice e slegato da Zope probabilmente assisteremmo ad un'adesione di massa persino superiore a quella che c'è stata con Django.

Citazione
Di contro aggiungo (e concludo) che il tuo ragionamento allora puo` essere esteso a qualsiasi framework - non necessariamente web - scritto in Python o in qualsiasi altro linguaggio. Quindi, utilizzare l'ambiente delle servlet in Java o JSP, non e` programmare in Java perche` c'e` sempre il bias della tecnologia specifica che si sta utlizzando. Sei d'accordo?

Si, sono d'accordo. Mi riprometto di approfondire Django e vedere se il discorso nel suo caso è diverso.

Offline gaiapuffo

  • python unicellularis
  • *
  • Post: 2
  • Punti reputazione: 0
    • Mostra profilo
Re: Web2Py vs. Django: Fight!
« Risposta #23 il: Novembre 08, 2015, 01:48 »
Ciao, Io utilizzo web2py è non capisco veramente le critiche....Sinceramente ho utilizzato diversi framework  java e ruby oltre che ad altissimo livello php (laravel)..

Java--Parlando di framework java, solo recentemente stanno diventando decenti per il web. Certamente se devi fare progetti grandi è importanti, Java è il mast con il solit Spring ecc..Ma per progetti piccoli-medi è da pazzi..Mille file di configurazione, a volte scritti in xml con mille configurazioni e installazione delle varie parti backend front end ecc...Insomma dalla mia esperienza è più il tempo a configurare che quello effettivo di programmazione....Va bene per progetti grandi.Vantaggio tanta documentazione, essere Java ..Ora con i nuovi framework vedi Play sta migliorando

Ruby--Velcece ed elegante.. Buono ma la cosa di dover installare le gemme che vanno in palla fra di loro ti fa sprecare sempre tempo e la documentazione fa cagare, oltre a versioni tra loro non sempre compatibili difficile l'aggiornamento dell app

Laraverl--Configurazione con operazioni anti intuitive, i comandi della view non mi piaciono e la parte mvc cmq non si discosta da tipo Play framework Java quindi tanto vale usare java la documentazione per me è fatta male..

Web2py--Punti a favore:

Documentazione è scritta veramente bene

Una buona console di amministrazione, puoi far partire l'applicazione specificando la porta e password, creare l'applicazione collegarla direttamente con mercurial a github..Caricala su OpenShift,,,Certo tutte cagate ma farlo in 2 sec quando parti da 0 senza conoscenze rispetto a farlo in seguito cercando nella doc non è male. La console di permette di scaricare plugin e di caricare file ecc...Oltre al fatto che non da poco conto fa anche da editor...Questa console è accessibile anche via remoto quando l'app è caricato sul server..Sinceramente leggermente meglio che utilizzare emacs via ssh vedi java o ruby...Inoltre vi è la console di amministrazione del database che è bene fatta con importazione ed esportazione csv del database...

Di default l'installazione su server è https con certificato la sicurezza non male....pacchetto di installazione fornito da web2py forum

Operazione predefinite registrazione, login, recupera password, profilo ecc.,..già create personalizzabile con registrazione invio email o attraverso linkedin facebook google
..Per il default non problem per la personalizzazione non ci vuole tantissimo..Non mi sembra poco..Possibilità di inserire captcha e altro.

Sistema di membership e gruppi facile da utilizzare, inoltre controllo login,registrazione ecc..con tabella è relativi indirizzi ip per controllo

Blocco d'accesso per funzione in base al login e ruolo semplice

Vi sono cose da non importare ma cavolo sono 6 variabili e sono quelle principali e spero ben di non doverle importare si usano sempre..request,response ecc...

Tantissimi tipi di database da poter utilizzare molti + di django

Le librerie più usate già incluse jquery,boostrap,font awesome,analytics ecc..già dentro

Un layout predefinito è perfetto da poter personalizzare a piacimento..altri layout web2py da scaricare

Possibilità di default di postare il sito da parte dell'utente su facebook e Google plus per pubblicità

Creazione di form con inserimento,cancellazione,aggiornamento semplice ad interfaccia con controlli su errori ..diverse modalità di creazione form automatica o personalizzata

Creazione di griglie tabella con stampa in csv,xml utlie per eventuali esportazioni oltre che sistema di ricerca avanzato di un singolo elemento integrato

Sistema email avanzato con diversi sistemi imap pop non tutti presenti in django

Comandi view che non cambiano rispetto al controller...Sinceramente lo preferisco di gran lunga..primo la sintassi è semplice quindi perchè imparare nuovi comandi separati..oltre che a facile sistema di include

Sistema di query più intuitivo di django andate a vedere la sintassi di web2py e django non cambia tanto ma a mio parere e più intuitiva

Importazione di plugin attraverso console che permette di ampliare la propria app facilmente

Forum molto disponibile e attivo mi è capitato di scrivere e quasi sempre mi hanno risposto e aiutato

Import ed export database semplicissimo

Caricamento di file molto semplice e con grafica carina attraverso plugin

Controlli molto restrittivi sui campi database attraverso file db.py tanti e utili..

Tutte le librerie python si possono importare e usare(logico ma ...tanto per dire)

Possibilità di scorporare l'app in moduli

Esportazione dell'app in plugin per unificarla ad un altra..

Queste sono le cose che di petto riporto su web2py..ps

SISTEMA DI MIGRAZIONE DATABASE CHE E' MOLTO MEGLI DI QUELLO DI DJANGO


Web2py non è il migliore ma certamente a mio parere può benissimo competere e battere gli altri..Contare che è molto molto giovane..è contare come è adesso rispetto a django con 4 anno i meno di sviluppo all'incirca e tanta roba
« Ultima modifica: Novembre 08, 2015, 02:03 da gaiapuffo »

Offline GlennHK

  • python sapiens sapiens
  • ******
  • Post: 1601
  • Punti reputazione: 1
    • Mostra profilo
    • La Tana di GlennHK
Re: Web2Py vs. Django: Fight!
« Risposta #24 il: Novembre 08, 2015, 08:21 »
Essendo con il cellulare sul treno non ho molto tempo per approfondire il confronto (non conoscendo web2py tra l'altro) ma ti posso assicurare che molti dei pregi che attribuisci a web2py django li ha già e anche migliorati

Online RicPol

  • python sapiens sapiens
  • ******
  • Post: 2567
  • Punti reputazione: 9
    • Mostra profilo
Re: Web2Py vs. Django: Fight!
« Risposta #25 il: Novembre 08, 2015, 11:57 »
mah sì infatti... e molti dei "pregi" che citi sono davvero delle pessime idee (jquery, bootstrap etc. già dentro di default? dio, spero proprio di no). Comunque, se web2py serve bene il tuo scopo, usa web2py.
Fine del figth.
(tra l'altro, è un thread vecchissimo, iniziato quando il panorama era diverso. Oggi, a dover fare l'eterno e inutile confronto tra "framework completo" e "framework minimalistico", i contendenti sarebbero flask, pyramid... mah).

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7317
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: Web2Py vs. Django: Fight!
« Risposta #26 il: Novembre 08, 2015, 12:51 »
Ciao, Io utilizzo web2py è non capisco veramente le critiche...

Mi dispiace. Sono molto puntuali e circostanziate. Basta leggere e meditare.
Citazione
Java--Parlando di framework java, solo recentemente stanno diventando decenti per il web. Certamente se devi fare progetti grandi è importanti, Java è il mast con il solit Spring ecc..Ma per progetti piccoli-medi è da pazzi..Mille file di configurazione, a volte scritti in xml con mille configurazioni e installazione delle varie parti backend front end ecc...Insomma dalla mia esperienza è più il tempo a configurare che quello effettivo di programmazione....Va bene per progetti grandi.Vantaggio tanta documentazione, essere Java ..Ora con i nuovi framework vedi Play sta migliorando

Ruby--Velcece ed elegante.. Buono ma la cosa di dover installare le gemme che vanno in palla fra di loro ti fa sprecare sempre tempo e la documentazione fa cagare, oltre a versioni tra loro non sempre compatibili difficile l'aggiornamento dell app

Laraverl--Configurazione con operazioni anti intuitive, i comandi della view non mi piaciono e la parte mvc cmq non si discosta da tipo Play framework Java quindi tanto vale usare java la documentazione per me è fatta male..

Si, capisco. Probabilmente fra i framework *non* Python web2py non e' troppo male. Ma preferirei  un qualunque framework Python invece che web2py ogni giorno della settimana. Tra l'altro il suo fingere di essere Python senza esserlo, me lo rende ancora piu' ostile.

> Documentazione è scritta veramente bene

Ormai questo vale per tutti quanti i progetti che sono in giro da un po'.

Citazione
Una buona console di amministrazione, puoi far partire l'applicazione specificando la porta e password, creare l'applicazione collegarla direttamente con mercurial a github..Caricala su OpenShift,,,Certo tutte cagate ma farlo in 2 sec quando parti da 0 senza conoscenze rispetto a farlo in seguito cercando nella doc non è male. La console di permette di scaricare plugin e di caricare file ecc...

Questo mi sembra il classico scegliere un linguaggio basandosi su quanto e' facile scrivere l'hello world.

Citazione
Oltre al fatto che non da poco conto fa anche da editor...Questa console è accessibile anche via remoto quando l'app è caricato sul server..Sinceramente leggermente meglio che utilizzare emacs via ssh vedi java o ruby...Inoltre vi è la console di amministrazione del database che è bene fatta con importazione ed esportazione csv del database...

Penso che sia chiaro che io e te abbiamo diverse idee di software engineering. Una feature del genere puo' avere una parvenza di senso se:
1) i tuoi sviluppatori non sono tanto a loro agio con Unix (altrimenti ovviamente e' piu' efficiente andare di ssh -- si, perche' tipo, avere un baco in produzione e non puoi fare rollback e' l'unico caso in cui e' sensato fare modifiche a mano su un server di produzione, e comunque in questi casi un minimo di shell serve per capire cosa e' successo e cosa sta succedendo).
2) stai facendo tipo il sito del salumiere, per cui hai *una* macchina. Io mi rifiuto di mettere su qualunque cosa cosa con una macchina (visto che non hai availability)... ne ho tipo almeno due. Piu' frequentemente molte di piu'. Ma *molte* di piu'. In primo luogo non e' nemmeno banale scegliere su che macchina arrivare (guarda caso... i miei sistemi hanno sempre qualche forma di load balancing...). Il che vuole dire che in tutti i contesti non amatoriali, questa feature e' inutile e quando usata e' dannosa. Fai te....

> Di default l'installazione su server è https con certificato la sicurezza non male....pacchetto di installazione fornito da web2py forum

Cosa vuole dire *pacchetto di installazione fornito dal forum*? Non e' che scritta cosi' sembri una grande diea.

Citazione
Operazione predefinite registrazione, login, recupera password, profilo ecc.,..già create personalizzabile con registrazione invio email o attraverso linkedin facebook google
..Per il default non problem per la personalizzazione non ci vuole tantissimo..Non mi sembra poco..Possibilità di inserire captcha e altro.

Mi sembra tutta roba relativamente standard. Loro hanno scelto di includere sta roba, altri la tengono in apps separate per una maggiore modularita'. Sulla breve l'approccio di PHP sembra avere vantaggi... alla lunga, non ne sono convinto.

> Sistema di membership e gruppi facile da utilizzare, inoltre controllo login,registrazione ecc..con tabella è relativi indirizzi ip per controllo

Scusa, ma non mi sembra sto gran motivo per scegliere... se usi le app di autenticazione di Django, te le trovi comunque.

> Vi sono cose da non importare ma cavolo sono 6 variabili e sono quelle principali e spero ben di non doverle importare si usano sempre..request,response ecc...

Eh, vedi... questo e' contro le idee fondamentali di Python. Ci sta', ognuno ha le sue opinioni. Ma queste opinioni non semplicemente contrarie all'ethos dell'ecosistema Python. Che va benissimo, figurati. A me tutto sommato python non dispiace. E il fatto che qualcuno non veda i pregi che questo porta e decide di forkare tutto... beh, a me dispiace.

> Tantissimi tipi di database da poter utilizzare molti + di django

E la maggior parte di questi hanno una user-base trascurabile. Quindi? Se non devo usare uno dei suddetti db non mi interessa.
E potrei sempre cavarmela con SQLAlchemy.

> Le librerie più usate già incluse jquery,boostrap,font awesome,analytics ecc..già dentro

Ma esattamente... chemmene frega? Tra l'altro avere la versione di jquery legata alla versione del mio app framework non e' una cosa che necessariamente voglio.

Comunque alla fine... a te piace l'approccio monolitico di web2py. Io preferisco l'approccio modulare di Python, e il fatto che Django sia inserito in questa linea.

> Possibilità di default di postare il sito da parte dell'utente su facebook e Google plus per pubblicità

Monolitico vs. modulare.

> Creazione di form con inserimento,cancellazione,aggiornamento semplice ad interfaccia con controlli su errori ..diverse modalità di creazione form automatica o personalizzata

Stai leggendo dalla documentazione di web2py o stiamo parlando delle differenze con Django? Perche' non e' come se Django non avesse un admin.

> Creazione di griglie tabella con stampa in csv,xml utlie per eventuali esportazioni oltre che sistema di ricerca avanzato di un singolo elemento integrato

Mononolitico vs. modulare. Tra l'altro, non e' che basti dire "avanzato" e fine, mission accomplished. Non devi fare un pitch a dei non tecnici.

> Sistema email avanzato con diversi sistemi imap pop non tutti presenti in django

Ehm... verrebbe da spiegarti che questa frase non ha un eccesso di senso. Tipo non mi e' chiaro perche' un application server dovrebbe avere supporto per *imap* (visto che per inciso Python per i fatti suoi parla imap e quello che ti pare...)

Inoltre... cosa ha di avanzato?

> Comandi view che non cambiano rispetto al controller...Sinceramente lo preferisco di gran lunga..primo la sintassi è semplice quindi perchè imparare nuovi comandi separati..

?

> oltre che a facile sistema di include

Immagino come al solito opaco, monolitico ed implicito.

> Sistema di query più intuitivo di django andate a vedere la sintassi di web2py e django non cambia tanto ma a mio parere e più intuitiva

Insomma, sono uguali, ma quell'altro e' un po' meglio (ma non e' dato di sapere perche'). Suppongo che sia "avanzato".

> Importazione di plugin attraverso console che permette di ampliare la propria app facilmente

Questa feature e' il classico esempio di cose non pensate. Una feature del genere ha senso esclusivamente in ambito amatoriale. In contesto reale e' inutile se non dannosa.
Sembra il tipico caso di "ottimizzare l'hello world" che e' relativamente facile da fare e garantisce afflusso di utenti (quelli che ci badano). Peccato che sia completamente inutile sul lungi termine...

> Forum molto disponibile e attivo mi è capitato di scrivere e quasi sempre mi hanno risposto e aiutato

Guarda, non e' che le varia community django siano scortesi e non rispondono...

> Caricamento di file molto semplice e con grafica carina attraverso plugin

Addirittura! Ma allora switcho subito! Mi offrono gia' pronto la cosa semplice. No grazie, preferisco avere django-storages...

> Controlli molto restrittivi sui campi database attraverso file db.py tanti e utili..

I controlli sono restrittivi quanto li vuoi che siano...

> Tutte le librerie python si possono importare e usare(logico ma ...tanto per dire)

Bah... si, dovrebbe. Sempre che non si inventino nuove bazze... tipo quando si erano inventati di local_import, che poi hanno dovuto (fortunatamente) deprecare perche' era proprio un'idea dell'accidenti.

> Possibilità di scorporare l'app in moduli
> Esportazione dell'app in plugin per unificarla ad un altra..

Si, tutto scontato.

> SISTEMA DI MIGRAZIONE DATABASE CHE E' MOLTO MEGLI DI QUELLO DI DJANGO

Fammi indovinare... e' "avanzato".

Citazione
Web2py non è il migliore ma certamente a mio parere può benissimo competere e battere gli altri..Contare che è molto molto giovane..è contare come è adesso rispetto a django con 4 anno i meno di sviluppo all'incirca e tanta roba

No guarda... la questione e' diversa. Sono progetti vecchiotti. Django ha 10 anni, web2py ha 6 anni. Quando esisti da 6 anni, non sono 4 anni di sviluppo che cambiano le cose. E' quanto grossa e attiva la comunita' e'. Il fatto fondamentale e' che la community di Django e' molto piu' grossa, forse anche piu' aperta... e quindi piu' gente ci lavora, piu' gente aggiunge cose. Non e' questione di 4 anni di vantaggio: e' questione che hanno il vantaggio sulla derivata.

Offline gaiapuffo

  • python unicellularis
  • *
  • Post: 2
  • Punti reputazione: 0
    • Mostra profilo
Re: Web2Py vs. Django: Fight!
« Risposta #27 il: Novembre 22, 2015, 00:34 »
Sinceramente è appunto una questione di gusti..Web2py riprende aspetti di Rails(lo si dice esplicitamente) è ci mette Python per questo è buono ma è personale. Per me non c'è di meglio che sono un programmatore Java, Ruby ma che trova quest'ultimo molto bello ma con tempi di sviluppo più lunghi dei framework Python e inutile per progetti medi quindi. Io lo "amo" perché è semplice, ma veramente semplice! Questo incide sulla giornata lavorativa è non ha nulla da invidiare per me.
(Annotazione per un punto precedente riguardo all' installazione su server. per pacchetto intendevo uno script da compilare su server che ti fornisce già l'ambiente web2py quindi poi tutto console e settare poi qualche permesso per rendere il tutto più sicuro(1 min è fatta) . Cmq tutti i framework python sono di livello e  non c'è dubbio che siano magari sotto certi aspetti meglio e diano le stesse funzionalità. Dico solo che io mi trovo bene con web2py visto che nessuno aveva scritto in merito. Su certe affermazioni sono in disaccordo:

Il discorso degli import, mi dispiace è ridicolo ci sono solo 6 import automatico delle cose principali come db,request,response e guardando la guida si capisce subito soprattutto per chi ha studiato almeno 2 settimane python. Crea icompatibilità con il mondo python? Bo non è assolutamente vero, io vengo dal mondo appunto Java e magicamente dopo che ho letto la guida 10 min l'avevo capito che ve ne erano 6 sottointesi e stranamente sono state capace di mettere da solo quelli che non c'erano senza farmi trippe mentali. Dai ho fatto un progetto grande con diversi import e veramente il fatto che non ne dovevo fare 6 non mi creava veramente nessuna trippa mentale, anche perché è impossibile confondersi perché sono veramente ma veramente quelli principali ripetutti 1000 volte nella guida..Allora Rails in confronto. Poi che palle dovermi importare 6 cose magari su 20 file diversi che sono appunto quelle che di sicuro troverai almeno in uno dei controller della pagina.

La documentazione è fatta bene per tutti i framework. Sono in disaccordo, ho studiato molto brevemente Laravel è fa abbastanza cagare o guardato quella di Flask è sinceramente non è il massimo con poi una certa similitudine con il sito di Sinatra Rails e ad entrambi un po' di impegno nell'interfaccia cavolo:), stessa cosa per Play Framework. Quindi non è assolutamente vero che tutti i framework hanno buona documentazione, il + grande esempio è Spring che già di per se è un casino e la doc non aiuta.

Un ultima annotazione su Django: Certamente è affermato ed è fatto bene, ma dapertutto è anche ribadito che non è conveniente per piccoli progetti e che ci vuole un po' per usarlo al meglio quindi non facciamo tutto bello. Oltre che tutti criticano il suo DAL. Ognuno ha i suoi difetti ma appunto era per farlo notare :)

Un ultima annostazione su Falsk: Fighissimo avere un microframework e costriuire  il tutto sopra, Sinceramente credo che questo non possa essere usato in un contesto lavorativo almeno che non ci sai fare..Se non hai anni di esperienza, lasciare ad una persona libero arvitrio sulla  struttura del Framework per me porta ad un fallimento sicuro. Certamente ora tutti bravi! Ma in un contesto lavorativo se ti danno un progetto ed hai un mese, non ti puoi permettere di provare due o tre librerie prima di trovare quella buona, cambiare una logica per un altra ecc..Vedo già ora che metà dei progetti iniziati dai programmatori falliscono , figurarsi cosi..Oltre a mantenere il Framework lineare, va bene se hai esperienza altrimenti dopo 6 mesi hai un mostro. Insomma mi sembra molto irrealistico e usabile solo in un contesto accademico o da un senior in quello reale. In questo caso, non siamo irrealistici! Veramente tantissimi progetti vanno in fallimento e figuarsi cosi! Crei una certa logica scopri che fa cagare cosa butti 2 mesi di lavoro, usi una certa libreria come parte fondamentale del layer e scopri che non va bene cosa fai? Cambi metà framework, quando ci sono i soldi in mezzo non si può fare una cosa del genere. Almeno che appunto non sei sicuro su quello che fai, ma quindi appunto per il 60% delle persone può essere solo amatoriale.

Va be raga non vogli alimentare polemica. Era solo perché nessuno aveva difeso web2py :) stasera non aveva nulla da fare quindi..
« Ultima modifica: Novembre 22, 2015, 00:46 da gaiapuffo »

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7317
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: Web2Py vs. Django: Fight!
« Risposta #28 il: Novembre 23, 2015, 17:27 »
Sinceramente è appunto una questione di gusti..

Fino ad un certo punto. Ci sono cose che sono questione di gusti. Cose che sono parte della filosofia di Python (ancora una volta gusti, se vuoi, ma la consistenza su una piattaforma e' un valore in se e per se). E poi ci sono questioni di buon o cattivo software engineering. Non e' tutto "gusto".

Citazione
Web2py riprende aspetti di Rails(lo si dice esplicitamente) è ci mette Python per questo è buono ma è personale.

Guarda, in un modo o nell'altro tutti hanno preso (o scoperto indipendentemente, a volte, nel caso di Django) da Rails. Generalmente qualunque cosa sia venuta dopo Rails ne ha dovuto tenere conto. E se fosse vero che Web2Py e' davvero piu' vicino a Rails, questo basterebbe a spiegare cosa non mi piace: a me Rails non piace. Troppa magia, alcune astrazioni sbagliati, troppo "one-size-fits-all".

Citazione
Io lo "amo" perché è semplice, ma veramente semplice!

Ma continui a non mostrare come sia piu' semplice di, per dire, Django.
Esattamente come quando continui a dire "avanzato" senza spiegare.

Citazione
(Annotazione per un punto precedente riguardo all' installazione su server. per pacchetto intendevo uno script da compilare su server che ti fornisce già l'ambiente web2py quindi poi tutto console e settare poi qualche permesso per rendere il tutto più sicuro(1 min è fatta) . Cmq tutti i framework python sono di livello e  non c'è dubbio che siano magari sotto certi aspetti meglio e diano le stesse funzionalità. Dico solo che io mi trovo bene con web2py visto che nessuno aveva scritto in merito. Su certe affermazioni sono in disaccordo:

Ehm... ma fuori dal mondo "ho una macchina e se va giu' mettero' il cartello 'work in progress'" (cosi' anni 90...) questa roba e' irrilevante.
Le mie flotte hanno qualche macchina in piu': ho bisogno di altri sistemi. E a quel punto fare un deploy di Django non e' particolarmente differente.

Citazione
Il discorso degli import, mi dispiace è ridicolo ci sono solo 6 import automatico delle cose principali come db,request,response e guardando la guida si capisce subito soprattutto per chi ha studiato almeno 2 settimane python.

Mi fa piacere di averti allietato la giornata. Ma non e' questione di "capire". E' questione che e' un'idea del ca**o.
E' la soluzione "PHP" ai problemi. No grazie... se uso Python e' perche' mi piace Python. Non ho bisogno che qualcuno disimpari a progettare ispirandosi a PHP.

Dal punto di vista del software engineering e' un'idea terribile. E' gia' stato testato che porta problemi sorprendenti in momenti inaspettati: non facciamolo gratuitamente. Specie in un linguaggio che ha come mantra "explicit is better than implicit".

Dopo di che, ognuno usi quello che gli pare. Ma non mi si venga a dire che questa cosa non violi pesantemente la filosofia di Python.

Citazione
Crea icompatibilità con il mondo python? Bo non è assolutamente vero, io vengo dal mondo appunto Java e magicamente dopo che ho letto la guida 10 min l'avevo capito che ve ne erano 6 sottointesi e stranamente sono state capace di mettere da solo quelli che non c'erano senza farmi trippe mentali.

Il fatto che tu possa girarci intorno non vuole dire che non sia una cattiva idea.
E no, fare buona ingegneria non e' una trippa mentale.

Citazione
Dai ho fatto un progetto grande con diversi import e veramente il fatto che non ne dovevo fare 6 non mi creava veramente nessuna trippa mentale, anche perché è impossibile confondersi perché sono veramente ma veramente quelli principali ripetutti 1000 volte nella guida..

Ma capisci che e' rompere le convenzioni in modo completamente gratuito? Non hai nessun vantaggio pratico. Vai contro tutta la tradizione di Python. Non e' una buona idea.

Citazione
Allora Rails in confronto.

E' un po' che non manifesto simpatia per Rails. Nel 2006 sembrava oro colato rispetto alle alternative. Nel 2015... i suoi vantaggi sono principalmente che e' molto usato (e quindi hai un sacco di expertise su cui costruire), ma in se e per se non sarebbe in generale la mia prima scelta.

> Poi che palle dovermi importare 6 cose magari su 20 file diversi che sono appunto quelle che di sicuro troverai almeno in uno dei controller della pagina.

Uhm... parametri formali... non e' che devi per forza *importare*. E poi voglio dire... che palle, os e altri moduli "core" li si importano praticamente sempre (magari non os, dipendentemente da quello che devi fare... ce ne sara' un altro). Quindi che facciamo? Un namespace piatto alla PHP tirando dentro tutto?

Ma davvero non e' bastata quell'esperienza per capire che non e' una buona idea?


Citazione
La documentazione è fatta bene per tutti i framework. Sono in disaccordo, ho studiato molto brevemente Laravel è fa abbastanza cagare o guardato quella di Flask è sinceramente non è il massimo con poi una certa similitudine con il sito di Sinatra Rails e ad entrambi un po' di impegno nell'interfaccia cavolo:), stessa cosa per Play Framework. Quindi non è assolutamente vero che tutti i framework hanno buona documentazione, il + grande esempio è Spring che già di per se è un casino e la doc non aiuta.

Guarda, stiamo parlando di Python. Non sono cosi' disperato da dovere fare PHP. ;)
La documentazione di Django e' eccellente. Quella di Flask io la trovo molto buona. Poi e' certo che riesci a trovare qualche framework che ha una cattiva documentazione (sicuramente quello che scrissi circa 12 anni fa come bridge sui cgi/fastcgi aveva una documentazione penosa: non credo che lo abbia usato nessuno al di fuori di me e di qualcuno che ha lavorato con me...) quindi si, tecnicamente non e' che *tutti* i framework python hanno una buona documentazione.
I maggiori pero' si.

Citazione
Un ultima annotazione su Django: Certamente è affermato ed è fatto bene, ma dapertutto è anche ribadito che non è conveniente per piccoli progetti e che ci vuole un po' per usarlo al meglio quindi non facciamo tutto bello. Oltre che tutti criticano il suo DAL. Ognuno ha i suoi difetti ma appunto era per farlo notare :)

Mah... non sono convinto che web2py sia particolarmente vincente sui progetti piccoli. Nel senso che se hai tante features (come ha Django e, come sostieni, web2py) alla fine dei conti hai potenzialmente un livello di complessita' leggermente superiore. Va anche detto che appena ti servono features riesci ad integrarle facilmente.

Io non mi sento di sconsigliare Django per un progetto piccolo. Poi chiaro, se a uno piace di piu' Flask, fa bene ad usare Flask. Ma un confronto fra Django e Flask e' un po' fuori dallo scope di questa discussione.

Strano parlare di DAL di Django... visto che essenzialmente DAL e' il termine che usa web2py per indicare il suo ... DAL. Nel senso che, sempre da documentazione, non ti danno un ORM ma una cosa un po' piu' di basso livello che chiamano DAL.

Dopo di che, l'ORM di Django viene criticato da:
1. persone che criticano gli ORM in quanto tali e/o quelli che supportano uno specifico pattern architetturale (io ci sono in mezzo: odio active record).
2. persone che trovano l'ORM di Django troppo limitato come features (il DAL di web2py ha, by design, *meno* features)

Non e' che in se e per se sia *male*. Diciamo che trovo sqlalchemy migliore. E sinceramente, l'idea di usare il DAL di web2py non mi piace. L'ORM di Django ha un set di problemi noti e facilmente controllabili, e' stato usato su tutte le scale. Se devo usare qualcosa di diverso, preferisco passare direttamente ad sqlalchemy. Cosa che posso fare con Django (e forse anche con web2py: ma ovviamente, essendo tutto molto piu' accoppiato, non e' detto che sia facile e/o conveniente; dipierro tendenzialmente lo sconsiglia).

Citazione
Un ultima annostazione su Falsk: Fighissimo avere un microframework e costriuire  il tutto sopra, Sinceramente credo che questo non possa essere usato in un contesto lavorativo almeno che non ci sai fare..Se non hai anni di esperienza, lasciare ad una persona libero arvitrio sulla  struttura del Framework per me porta ad un fallimento sicuro. Certamente ora tutti bravi! Ma in un contesto lavorativo se ti danno un progetto ed hai un mese, non ti puoi permettere di provare due o tre librerie prima di trovare quella buona, cambiare una logica per un altra ecc..Vedo già ora che metà dei progetti iniziati dai programmatori falliscono , figurarsi cosi..Oltre a mantenere il Framework lineare, va bene se hai esperienza altrimenti dopo 6 mesi hai un mostro. Insomma mi sembra molto irrealistico e usabile solo in un contesto accademico o da un senior in quello reale. In questo caso, non siamo irrealistici! Veramente tantissimi progetti vanno in fallimento e figuarsi cosi! Crei una certa logica scopri che fa cagare cosa butti 2 mesi di lavoro, usi una certa libreria come parte fondamentale del layer e scopri che non va bene cosa fai? Cambi metà framework, quando ci sono i soldi in mezzo non si può fare una cosa del genere. Almeno che appunto non sei sicuro su quello che fai, ma quindi appunto per il 60% delle persone può essere solo amatoriale.

Come dire? Noi qua usiamo tutto quello che ha senso usare. E no, noi le persone che "non ci sanno fare" tendiamo a non assumerle. Troviamo sciocco basare scelte tecnologiche sulla base del fatto che non abbiamo ingegneri abbastanza capaci: preferiamo assumere ingegneri capaci ed avere la liberta' di usare la cosa che funziona meglio per i nostri clienti.

Detto questo, la combinazione "incapace + progetto grosso" non finisce bene a prescindere dal framework. Ho fondati dubbi che un incapace si impicca con web2py come con Flask. Probabilmente in punti diversi... ma si impicca.

Incidentalmente, ho visto Flask usato anche da persone che di mestiere non sono sviluppatori senza grossi problemi. Credo che la sua semplicita' vinca sul fatto che determinate scelte siano facilmente modificabili: i default funzionano piuttosto bene. Se non funzionano, di solito e' perche' si e' in un caso particolare e la possibilita' di potere facilmente cambiare e' quello che puo' salvarti il processo, rispetto alle soluzioni 'one-size-fits-all'.

Perche' voglio dire... non e' che se non sei capace usi 15 sistemi di templating perche' il tuo framework te lo consente. Flask ti suggerisce jinja2 (che incidentalmente e' molto buono) e se non hai motivi per scegliere qualcos'altro userai quello. Se *devi* usare qualcos'altro e' solo un vantaggio che sia facile farlo.

Tra l'altro e' buffo citare il fatto che Flask sarebbe ok "solo in un contesto accademico o se hai un senior", quando web2py e' *scritto* in un contesto accademico e non mi e' assolutamente chiara quale sia l'adozione nell'industria (ne' quanto gli sviluppatori abbiano presente i problemi che abbiamo qua fuori).

Io posso dire che se mi venisse sottoposto da valutare un progetto che usa web2py scrutinerei molto piu' attentamente la cosa che se la scelta cadesse su Django o su Flask.

Online RicPol

  • python sapiens sapiens
  • ******
  • Post: 2567
  • Punti reputazione: 9
    • Mostra profilo
Re: Web2Py vs. Django: Fight!
« Risposta #29 il: Novembre 23, 2015, 19:06 »
Ora, capiamoci. Non c'è niente di male a voler continuare a usare gli strumenti che si conoscono meglio, almeno finché proprio non si sbatte contro qualche muro e allora conviene cambiare strada. Se l'OP è abituato con web2py, preferisce web2py, ha un "gusto" per web2py, etc., siamo tutti felici che continui a usarlo. E se ci ricava anche un sostanzioso stipendio, siamo ancora più felici per lui.

Quello che non va più tanto bene, è non vedere i problemi strutturali degli strumenti che si usano. Ancora meno bene, è non capirli. Molto molto male, difendere questi problemi strutturali come se fossero pregi.

Per esempio, è piuttosto noto qui che il sottoscritto usa wxPython per fare gui. Non ho proprio nessuna intenzione di cambiare framework per fare gui. La ragione è che le wx sono un grosso framework, ho fatto un discreto investimento per imparare a gestirlo, ho una codebase personale piuttosto consistente, una bella esperienza.
Ma non mi sognerei mai di dire che le wx hanno un'architettura migliore delle qt.
Conosco benissimo i limiti delle wx - anzi, proprio perché conosco i limiti delle wx penso di essere un discreto programmatore wx, e non mi sognerei mai di lasciare le wx. Meglio il nemico che conosci, etc. etc. [1]
Ma onestamente, per partire da zero, in generale consiglierei le qt, a meno di altre esigenze specifiche. E vivo in pace con questo.

Ora, web2py, onestamente... è invecchiato maluccio. Questa filosofia della limousine accessoriata che dieci anni fa spaccava, oggi abbiamo capito che è un po' una ciofeca. Django, al confronto, è invecchiato molto meglio, anzi è rimasto piuttosto un giovanotto.
Non c'è niente di male a dirlo, e anzi sarebbe probabilmente meglio capirlo. Non per abbandonare web2py, eh? Ma anzi, proprio per capirlo meglio.

Se fai sviluppo web nel 2015, hai bisogno di una serie di cardini mentali, per cominciare. E' inutile dire "flask è per chi già ci sa fare", perché comunque *devi* saperci fare. Se puoi permetterti di fare sviluppo web e non saperci fare, di non essere familiare con certi principi, allora sei al livello in cui, onestamente, una buona customizzazione di WordPress è preferibile sotto tutti gli aspetti a web2py, Django e Flask messi insieme. (livello inteso come tipologia di lavoro, non come livello di merito, beninteso)

Il mio umile parere sulla questione è che "visto che lo uso con successo, mi piace, quindi non può essere una cosa brutta, quindi lo difendo" è una linea di pensiero comprensibile, ma può essere un po' limitante per la propria crescita anche professionale. Il che non significa cambiare tecnologia una volta alla settimana per andare dietro a tutti, ci mancherebbe.


[1] edit... dimenticavo di dire... lavoro (prevalentemente) in windows. E credetemi, questa è davvero una scuola di umiltà e comprensione dei limiti del proprio mondo. ;-)
« Ultima modifica: Novembre 23, 2015, 19:09 da RicPol »