Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Carlo Miron]

2011/12/6 Carlos Catucci :
> Inoltre hai la concatenazione di stringhe con il . al post del logico +
> (fare overloading dell'operatore era cosa complessa si vede).

Piu` che altro il problema e` che

php > print '3'+2;
5
php > print '3a'+2;
5
php > print '3viso'+2;
5
php > print 'ciao'+2;
2

Non continuo, senno` Nicola sbocca.

-- 
Carlo Miron
Vomit Type System Solution Architect™
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Carlo Miron]

2011/12/6 enrico franchi :
> On Tue, Dec 6, 2011 at 11:27 AM, Nicola Larosa  wrote:
>> enrico franchi wrote:
>> > Python e' un linguaggio con relativamente poche features, ma *tutte*
>> > si potenziano a vicenda. L'integrazione e' splendida.
>> > Il modo in cui FOF, LOL,
>> Uhm... eh?
> First Order Functions, Let Over Lambda (ovvero le closures).

Curiosamente, secondo Urban Dictionary, FOF e` il contrario di LOL


©
-- 
Carlo Miron
Urban Dict Fun Solution Architect™
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] web: sync vs. async

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 06/12/2011 19:43, Roberto De Ioris ha scritto:
> [...]
>> Per il "Thundering herd problem", trovi una breve descrizione su
>> Wikipedia:
>> http://en.wikipedia.org/wiki/Thundering_herd_problem
>>
>> Vedi anche:
>> http://www.citi.umich.edu/projects/linux-scalability/reports/accept.html
>>
>>
>> Il problema è menzionato anche nel libro "UNIX Network Programming".
>> In particolare, oltre al problema di prestazioni che per pochi processi
>> non dovrebbe essere preoccupante, c'è un altro problema con quello che
>> fai: chiamare accept sullo stesso file descriptor ereditato potrebbe
>> **non** funzionare su alcuni sistemi; in questi casi hai bosogno di
>> serializzare la chiamata con un lock o mutex (che è quello che,
>> opzionalmente, fa Nginx [1]).
>>
>> Ti consiglio di fare dei test e di documentarti meglio (io non so
>> nemmeno cosa è cambiato in versioni recenti di Linux).
>>
> 
> 
> accept() non e' piu' soggetta al thundering herd da un po', 

Ma occorre sempre serializzare le chiamate, oppure ora è come su FreeBSD?
Perchè su Nginx abilita accept_mutex di default.

> mentre
> epoll_wait() lo e', e pure di brutto.
>

Si, avevo letto qualcosa su epoll.

> [...]
>
> Ad oggi ne' io ne' i ragazzi di unicorn (server ruby di cui gunicorn e' il
> porting in python) abbiamo rilevato un impatto del thundering herd tale da
> doverlo gestire diversamente. Di idea completamente opposta i ragazzi di
> passenger che invece preferiscono gestire tutto in user space con una
> porta aperta per ogni processo. Evidentemente si sentono stra-sicuri del
> loro load-balancer interno, o sanno qualcosa che io non so :)
> 

Purtroppo non avuto modo di vedere in dettaglio il codice di questi
progetti.



Ciao  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7ehiMACgkQscQJ24LbaUQPogCdFUzPjOLZwQZQ6/1CSpZxlEKv
RKkAn1V4B9WFz+7r6d78rmgXu2HkD1fb
=N7Bd
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Applicativo Python. Problema con risoluzione video

[Salvadori Giordano]

Ciao a tutti

 

Ho un problema con un'applicativo creato con python 2.5 wxPython 2.8.

In pratica utilizzando il programma con risoluzione 1440x900 o 1280x1024 il 
tutto viene visualizzato correttamente,

se invece vengono utilizzate risoluzioni più alte o più basse magari cambiano 
la percentuale di grandezza dei caratteri mi appaiono le scritte troncate, 
caratteri che non si riescono a vedere interamente e cose del genere.

C'è qualche metodo per adattarsi a tutte le risoluzioni automaticamente oppure 
devo utilizzare wx.GetDisplaySize() e adattare le lunghezze e dimensioni a 
quello che mi torna??

 

Grazie mille per l'aiuto

Salvadog

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] web: sync vs. async

[Giampaolo Rodolà]

Il 06 dicembre 2011 19:38, Manlio Perillo  ha scritto:
>> Riusciresti a darmi qualche dettaglio in più?
>
> Per il "Thundering herd problem", trovi una breve descrizione su Wikipedia:
> http://en.wikipedia.org/wiki/Thundering_herd_problem
>
> Vedi anche:
> http://www.citi.umich.edu/projects/linux-scalability/reports/accept.html
>
>
> Il problema è menzionato anche nel libro "UNIX Network Programming".
> In particolare, oltre al problema di prestazioni che per pochi processi
> non dovrebbe essere preoccupante, c'è un altro problema con quello che
> fai: chiamare accept sullo stesso file descriptor ereditato potrebbe
> **non** funzionare su alcuni sistemi; in questi casi hai bosogno di
> serializzare la chiamata con un lock o mutex (che è quello che,
> opzionalmente, fa Nginx [1]).
>
> Ti consiglio di fare dei test e di documentarti meglio (io non so
> nemmeno cosa è cambiato in versioni recenti di Linux).

Grazie, non ero minimamente a conoscenza del problema.
Leggerò partendo dagli spunti che mi hai dato.
Per la cronaca, tornado dovrebbe soffrire dello stesso "problema",
solo che anzichè utilizzare multiprocessing fa il tutto a mano con
fork(), che ipotizzo sia concettualmente identico:
https://github.com/facebook/tornado/blob/master/tornado/process.py#L64
https://github.com/facebook/tornado/blob/master/tornado/netutil.py#L151


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] web: sync vs. async

[Roberto De Ioris]

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Il 06/12/2011 18:34, Giampaolo Rodolà ha scritto:
>> Il 03 dicembre 2011 16:23, Manlio Perillo  ha
>> scritto:
 Una cosa di questo tipo non avrebbe ugualmente funzionato?

 # pseudo codice
 import multiprocessing
 from somehttpd import HTTPServer

 CPUS = multiprocessing.cpu_count()
 server = HTTPServer()
 # create child processes to act as workers
 for x in range(CPUS - 1):
 Process(target=server.serve_forever).start()
 # main process also acts as a worker
 server.serve_forever()


 Se si, ti saresti evitato l'onere di ascoltare su porte multiple e
 ovviamente tutta la complessità aggiuntiva che ne deriva.

>>>
>>> Questo è essenzialmente l'approccio usato da Nginx.
>>>
>>> Però c'è un dettaglio subdolo: con questo metodo ciascun processo
>>> figlio
>>> chiama la accept sullo stesso file descriptor ereditato dal padre e ci
>>> potrebbero essere dei problemi subdoli.
>>>
>>> Ad esempio il problema chiamato "thundering herd" oppure (ma su questo
>>> non riesco a trovare dei riferimenti, l'ho letto dall'autore di Nginx)
>>> il sistema operativo potrebbe **non** distribuire il carico equamente
>>> su
>>> tutti i sotto processi.
>>>
>>>
>>> Ciao  Manlio
>>
>> Riusciresti a darmi qualche dettaglio in più?
>
> Per il "Thundering herd problem", trovi una breve descrizione su
> Wikipedia:
> http://en.wikipedia.org/wiki/Thundering_herd_problem
>
> Vedi anche:
> http://www.citi.umich.edu/projects/linux-scalability/reports/accept.html
>
>
> Il problema è menzionato anche nel libro "UNIX Network Programming".
> In particolare, oltre al problema di prestazioni che per pochi processi
> non dovrebbe essere preoccupante, c'è un altro problema con quello che
> fai: chiamare accept sullo stesso file descriptor ereditato potrebbe
> **non** funzionare su alcuni sistemi; in questi casi hai bosogno di
> serializzare la chiamata con un lock o mutex (che è quello che,
> opzionalmente, fa Nginx [1]).
>
> Ti consiglio di fare dei test e di documentarti meglio (io non so
> nemmeno cosa è cambiato in versioni recenti di Linux).
>


accept() non e' piu' soggetta al thundering herd da un po', mentre
epoll_wait() lo e', e pure di brutto.

Dai test effettuati per uWSGI e' comunque meglio avere il thundering herd
(basta saperlo gestire nel codice) che un locking costante quando il
numero di epoll_wait() in ascolto non supera (o supera di poco) il numero
di core cpu. Se invece il numero e' abnorme (ad esempio quando si va in
preforking+multithread) su Linux e' meglio il locking (per lo meno dei
thread all'interno dello stesso processo)

Ad oggi ne' io ne' i ragazzi di unicorn (server ruby di cui gunicorn e' il
porting in python) abbiamo rilevato un impatto del thundering herd tale da
doverlo gestire diversamente. Di idea completamente opposta i ragazzi di
passenger che invece preferiscono gestire tutto in user space con una
porta aperta per ogni processo. Evidentemente si sentono stra-sicuri del
loro load-balancer interno, o sanno qualcosa che io non so :)

-- 
Roberto De Ioris
http://unbit.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] web: sync vs. async

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 06/12/2011 18:34, Giampaolo Rodolà ha scritto:
> Il 03 dicembre 2011 16:23, Manlio Perillo  ha 
> scritto:
>>> Una cosa di questo tipo non avrebbe ugualmente funzionato?
>>>
>>> # pseudo codice
>>> import multiprocessing
>>> from somehttpd import HTTPServer
>>>
>>> CPUS = multiprocessing.cpu_count()
>>> server = HTTPServer()
>>> # create child processes to act as workers
>>> for x in range(CPUS - 1):
>>> Process(target=server.serve_forever).start()
>>> # main process also acts as a worker
>>> server.serve_forever()
>>>
>>>
>>> Se si, ti saresti evitato l'onere di ascoltare su porte multiple e
>>> ovviamente tutta la complessità aggiuntiva che ne deriva.
>>>
>>
>> Questo è essenzialmente l'approccio usato da Nginx.
>>
>> Però c'è un dettaglio subdolo: con questo metodo ciascun processo figlio
>> chiama la accept sullo stesso file descriptor ereditato dal padre e ci
>> potrebbero essere dei problemi subdoli.
>>
>> Ad esempio il problema chiamato "thundering herd" oppure (ma su questo
>> non riesco a trovare dei riferimenti, l'ho letto dall'autore di Nginx)
>> il sistema operativo potrebbe **non** distribuire il carico equamente su
>> tutti i sotto processi.
>>
>>
>> Ciao  Manlio
> 
> Riusciresti a darmi qualche dettaglio in più?

Per il "Thundering herd problem", trovi una breve descrizione su Wikipedia:
http://en.wikipedia.org/wiki/Thundering_herd_problem

Vedi anche:
http://www.citi.umich.edu/projects/linux-scalability/reports/accept.html


Il problema è menzionato anche nel libro "UNIX Network Programming".
In particolare, oltre al problema di prestazioni che per pochi processi
non dovrebbe essere preoccupante, c'è un altro problema con quello che
fai: chiamare accept sullo stesso file descriptor ereditato potrebbe
**non** funzionare su alcuni sistemi; in questi casi hai bosogno di
serializzare la chiamata con un lock o mutex (che è quello che,
opzionalmente, fa Nginx [1]).

Ti consiglio di fare dei test e di documentarti meglio (io non so
nemmeno cosa è cambiato in versioni recenti di Linux).

> [...]


[1] http://wiki.nginx.org/EventsModule#accept_mutex


Ciao  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7eYTsACgkQscQJ24LbaUQWLgCfYc7xZCuMD04RscXG9cPSFyMD
vaYAniyZLqItKQ4xqjzwu8J1vBkijA4f
=J1vo
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] web: sync vs. async

[Giampaolo Rodolà]

Il 03 dicembre 2011 16:23, Manlio Perillo  ha scritto:
>> Una cosa di questo tipo non avrebbe ugualmente funzionato?
>>
>> # pseudo codice
>> import multiprocessing
>> from somehttpd import HTTPServer
>>
>> CPUS = multiprocessing.cpu_count()
>> server = HTTPServer()
>> # create child processes to act as workers
>> for x in range(CPUS - 1):
>>     Process(target=server.serve_forever).start()
>> # main process also acts as a worker
>> server.serve_forever()
>>
>>
>> Se si, ti saresti evitato l'onere di ascoltare su porte multiple e
>> ovviamente tutta la complessità aggiuntiva che ne deriva.
>>
>
> Questo è essenzialmente l'approccio usato da Nginx.
>
> Però c'è un dettaglio subdolo: con questo metodo ciascun processo figlio
> chiama la accept sullo stesso file descriptor ereditato dal padre e ci
> potrebbero essere dei problemi subdoli.
>
> Ad esempio il problema chiamato "thundering herd" oppure (ma su questo
> non riesco a trovare dei riferimenti, l'ho letto dall'autore di Nginx)
> il sistema operativo potrebbe **non** distribuire il carico equamente su
> tutti i sotto processi.
>
>
> Ciao  Manlio

Riusciresti a darmi qualche dettaglio in più?
Sono lì lì per portare questa modifica in produzione.
Effettuando dei test finora non mi è sembrato di notare alcunchè di
"subdolo" o fuori dalla norma.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Carlos Catucci]

A parte il fatto che Python è molto più figo di PHP quali sono nel

> dettaglio i motivi tecnici che spingono molti programmatori a
> considerare il PHP un linguaggio inferiore?
> E se ce ne sono, quali possono essere le cose che python potrebbe
> invidiare a PHP?
>

Qui non e' problema di flame, ma che wikipedia non basta a contenere tutto
:)

La filosofia alla bse dei due linguagg e' completamente diversa.
Python crea del bytecode (diciamo stile java anche se non e' vero) al volo
se il sorgente (qualora presente) sia piu' recente del compilato, mentre
php e' un inguaggio del tutto interpretato.

In python se non stai facendo uno script da shell sei portato a usare gli
oggetti, in PHP gli oggetti li usano solo programmatori che vogliono poi
dormire la notte invece che cercare i bugs in un mare di spaghetti code (e
son pochi, perche' se sono cosi' bravi difficile usino php se possono
evitarlo). E comunque comunque tu faccia, in python tutto e' un oggetto.

Python nasce come "linguaggio batterie incluse" (parola di Guido, amen), e
poi ha una miriade di libraries create da terzi.
PHP di suo fa molte meno cose e le librerie spesso sono ingfestibili
(qualche caso mi dicono anche in Python, come Elixir, non parlo per
esperienza diretta quindi non picchiatemi).

Python e' completamente dinamico. PHP direi di no.

La sintassi di python e' chiara. In PHP assegni elementi ad una hash con la
sintassi (non naturale) key=>value e accedi agli oggetti con
$obj->method(). Inoltre hai la concatenazione di stringhe con il . al post
del logico + (fare overloading dell'operatore era cosa complessa si vede).
In python hai i dizionari (che sono meglio di una semplice hashtable) che
gstisci con la sintassi (naturale e usata anche da javascript e json) {
key: value, }, accedi con obj.method() e il + capisce da se cosa deve fare.

Inoltre il fatto che non si usino { } per delimitare i blocchi (con la
guerra tra chi le apre subito dopo lo statement che inizia il blocco ed
altri a capo, in ogni caso creando confuzion) usa la spaziature, rendendo
quindi di conseguenza il codice legggibile anche se a scriverlo e' uno
sciagurato che non indenta.

Insomma la lista potrebbe andare avanti per chissa' quanto. Il fatto e' che
Python E' piu' figo di PHP e tanto basta. Non serve dimostrarlo.

Carlos
-- 
If you have no voice, SCREAM! If you have no legs, RUN! If you have no
hope, INVENT!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[enrico franchi]

2011/12/6 Marco Beri 

> On 06/dic/2011, at 10:05, enrico franchi  wrote:
> > Mi verrebbe da dire nessuna. Forse la facilità con cui si fanno acronimi
> di presa per il culo di PHP: ci si può divertire per delle ore.
>
> Poor young totally hopeless onanistic numb
>
>
LOL!

s/numb/nun/



-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[enrico franchi]

On Tue, Dec 6, 2011 at 11:27 AM, Nicola Larosa  wrote:

> enrico franchi wrote:
> > Python e' un linguaggio con relativamente poche features, ma *tutte*
> > si potenziano a vicenda. L'integrazione e' splendida.
> > Il modo in cui FOF, LOL,
>
> Uhm... eh?
>

First Order Functions, Let Over Lambda (ovvero le closures).


>
>
> > generatori, oggetti e moduli interagiscono e' semplicemente favoloso.
> > [...]
> > Forse la facilità con cui si fanno acronimi di presa per il culo di
> > PHP
>
> Perché ho la sensazione che questo sia collegato col dubbio precedente?


No... :)
Involontario.




Let over lambda:


(let ((x 0))
(lambda () x))


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Nicola Larosa]

enrico franchi wrote:
> Python e' un linguaggio con relativamente poche features, ma *tutte*
> si potenziano a vicenda. L'integrazione e' splendida.
> Il modo in cui FOF, LOL,

Uhm... eh?


> generatori, oggetti e moduli interagiscono e' semplicemente favoloso.
> [...]
> Forse la facilità con cui si fanno acronimi di presa per il culo di
> PHP

Perché ho la sensazione che questo sia collegato col dubbio precedente?

-- 
Nicola Larosa - http://www.tekNico.net/

Most of the people who rely on GPSD will never know it’s there. It’s
not a user-facing application that people actually see, it’s plumbing
that the programs they do see relies on. Like physical plumbing, it’s
unglamorous and out of sight and essential. I’m OK with that. There’s
a quiet kind of satisfaction - not really new to me, since some of my
other code is even more ubiquitous - to knowing that the world rests
on your software, even if most people will never understand how.
 - Eric S. Raymond, August 2011
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Roberto De Ioris]

> On 06/dic/2011, at 10:07, Roberto De Ioris  wrote:
>
>> Se ho scritto python in modo non elegante ricevero' una gangbang di
>> sputi
>> (scusate per la mia vena poetica, a volte mi faccio schifo da solo)
>
> Si chiama bukkake e non gangbang, ignorante.
>
> Si vede che programmi C.
>

Ho paura che qualsiasi cosa risponda potresti usarla per ricattarmi con
mia moglie. Facciamo che hai vinto.

-- 
Roberto De Ioris
http://unbit.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Marco Beri]

On 06/dic/2011, at 10:07, Roberto De Ioris  wrote:

> Se ho scritto python in modo non elegante ricevero' una gangbang di sputi
> (scusate per la mia vena poetica, a volte mi faccio schifo da solo)

Si chiama bukkake e non gangbang, ignorante.

Si vede che programmi C.

Ciao.
Marco.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Marco Beri]

On 06/dic/2011, at 10:05, enrico franchi  wrote:
> Mi verrebbe da dire nessuna. Forse la facilità con cui si fanno acronimi di 
> presa per il culo di PHP: ci si può divertire per delle ore.

Poor young totally hopeless onanistic numb
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Roberto De Ioris]

> 2011/12/6 Matteo Magni 
>
>> Perl e' caos. Ma in quel caos c'e' del genio.
>

Cacchio, questa me la tatuo...

-- 
Roberto De Ioris
http://unbit.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Marco Beri]

On 06/dic/2011, at 09:52, Simone Federici  wrote:

2011/12/6 Matteo Magni 

> A parte il fatto che Python è molto più figo di PHP quali sono nel
> dettaglio i motivi tecnici che spingono molti programmatori a
> considerare il PHP un linguaggio inferiore?
>

tecnici? prova tu stesso :-)

>>> "python" > "PHP"
True


Lollissimo :-)))
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Roberto De Ioris]

> Ciao a tutti,
> mi intrometto nonostante stia soprattutto lurkando questa lista molto
> interessante.
> Sono un "programmatore" che  aimé utilizza molto PHP e purtroppo molto
> poco Python, non fatemene una colpa :-)
> Mi piacerebbe che la discussione prendesse una maggiore "profondità".

Bah, 9 volte su 10 piu' "profonda" significa meno divertente...che noiosi
che siete :)

>
> A parte il fatto che Python è molto più figo di PHP quali sono nel
> dettaglio i motivi tecnici che spingono molti programmatori a
> considerare il PHP un linguaggio inferiore?

E' per natura un DSL (un linguaggio specifico per il web nel suo caso)
quindi gia' partirebbe svantaggiato in un qualsiasi confronto (sebbene
nessuno vieti di usarlo in altri contesti). Non fa dell'eleganza il suo
punto di forza (a meno che non vieni dal perl, ma a quel punto
diventerebbe talmente elegante da farti schifo comunque ;) Manca di alcuni
costrutti, ma non essendo un linguaggio nato ad oggetti mi sento di
perdonarlo (a maggior ragione che ancora la stragrande maggioranza delle
applicazioni php sono scritte in procedurale).

Basta per definirlo un linguaggio merdoso ? Secondo me no, ho visto codice
php bellissimo e codice python orripilante (scritto da me). Torniamo al
punto gia' ribadito che e' il programmatore il fulcro della questione. A
questo aggiungo lo "spirito" di un linguaggio.

Python e PHP hanno uno 'spirito' diverso. Io programmo in C la maggior
parte del tempo, se qualcuno mi dice che ho sbagliato una funzione o c'e'
un leak abbasso la testa e correggo (e mi stringo anche un po' il
cilicio), ma se qualcuno mi dice che una funzione non e' "elegante" rialzo
la testa e gli sputo in un occhio, perche' non ha colto lo 'spirito' del
C. Lo stesso discorso si applica a qualsiasi linguaggio.

Se ho scritto python in modo non elegante ricevero' una gangbang di sputi
(scusate per la mia vena poetica, a volte mi faccio schifo da solo)

> E se ce ne sono, quali possono essere le cose che python potrebbe
> invidiare a PHP?

che e' stato pensato fin dall'inizio per essere deployato subito e senza
smazzi. La sua architettura e' di una semplicita' disarmante:

allochi l'interprete all'inizio (quando parte il server), e per ogni
richiesta si crea un nuovo ambiente che poi viene distrutto alla fine.
Semplicemente perfetto (se programmi in stateless), una noia e un limite
inaudito se vuoi scrivere applicazioni di nuova concezione.

Il risultato e' che subito dopo la sua nascita la stragrande maggioranza
dei provider (anche low-cost) lo supportava, e in un modo tale per cui chi
era abituato a CGI si ritrovava ad usare le stesse tecniche di deploy ma
con le performance aumentate a dismisura.

Negli altri ambienti la soluzione e' sempre stata il server dedicato, e
quindi spendere di piu' e fare i sistemisti.

Le cose ultimamente sono cambiate da questo punto di vista, ma resta il
fatto che deployare applicazioni php ha sempre una curva d'apprendimento
meno ripida degli altri.

-- 
Roberto De Ioris
http://unbit.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[enrico franchi]

2011/12/6 Matteo Magni 

>
> A parte il fatto che Python è molto più figo di PHP quali sono nel
> dettaglio i motivi tecnici che spingono molti programmatori a
> considerare il PHP un linguaggio inferiore?
>

Il fatto che lo sia? E' brutale, ma e' cosi'. Ovviamente bisognerebbe dare
definizioni precise di "inferiore".

E bisogna anche vedere con chi si sta parlando... non so, io per esempio
apprezzo Python, ma sento la mancanza di un sacco di cose che ho trovato in
altri linguaggi Lisp/Scheme/Erlang/Haskell.

Non arrivo a dire che Python e' "inferiore" a questi linguaggi: compensa
eccellentemente la mancanza di queste features con altre features
decisamente utili, librerie di altissima qualità, coerenza e facilità di
utilizzo.

Il mio problema principale con PHP e' che e' una versione ristupidita di
Perl. Perl e' caos. Ma in quel caos c'e' del genio.
PHP e' caos, ma e' caos non come "tutto", ma come semplice mancanza di
ordine sulla pochezza.

Nota, non e' colpa di PHP: e' nato per fare un mestiere e gliene hanno
fatto fare un altro.

Per dire... il solo fatto che PHP ha guadagnato le closures e i namespace
con la versione 5.3 (senza nessun motivo rilevante per non averle prima) e'
dal mio punto di vista indice della sua pochezza.

In generale il problema e' che PHP condivide molti degli svantaggi dei
linguaggi meno flessibili (come Java) senza averne nessun motivo. Guarda il
modello ad oggetti: bene o male PHP e' un linguaggio dinamico. Non ha
bisogno di certe menate. E il problema e' che non puo' nemmeno guadagnarne
in performance, perche' al di la di tutto e' appunto un linguaggio dinamico.

La mia idea e' che PHP abbia sempre preso il peggio dei mondi su cui si e'
affacciato, piu' o meno seguendo le mode, senza mai capire come le features
si potenziano a vicenda.

Python e' un linguaggio con relativamente poche features, ma *tutte* si
potenziano a vicenda. L'integrazione e' splendida.
Il modo in cui FOF, LOL, generatori, oggetti e moduli interagiscono e'
semplicemente favoloso. Una volta capito il modello (relativamente
semplice) si implementa qualunque cosa in modo molto semplice.


> E se ce ne sono, quali possono essere le cose che python potrebbe
> invidiare a PHP?
>

Mi verrebbe da dire nessuna. Forse la facilità con cui si fanno acronimi di
presa per il culo di PHP: ci si può divertire per delle ore.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Simone Federici]

2011/12/6 Matteo Magni 

> A parte il fatto che Python è molto più figo di PHP quali sono nel
> dettaglio i motivi tecnici che spingono molti programmatori a
> considerare il PHP un linguaggio inferiore?
>

tecnici? prova tu stesso :-)

>>> "python" > "PHP"
True
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Carlos Catucci]

Non mi piace l'idea di riesumare questo thread (ma chi voglio prendere in
giro, manco da un pezzo sulla lista, mi piace riesumare thread), ma...

Se riesumi cose simili riesuma pure.

Carlos
-- 
If you have no voice, SCREAM! If you have no legs, RUN! If you have no
hope, INVENT!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: PHP critique [ERA] Re: Python e html

[Matteo Magni]

Ciao a tutti,
mi intrometto nonostante stia soprattutto lurkando questa lista molto
interessante.
Sono un "programmatore" che  aimé utilizza molto PHP e purtroppo molto
poco Python, non fatemene una colpa :-)
Mi piacerebbe che la discussione prendesse una maggiore "profondità".

A parte il fatto che Python è molto più figo di PHP quali sono nel
dettaglio i motivi tecnici che spingono molti programmatori a
considerare il PHP un linguaggio inferiore?
E se ce ne sono, quali possono essere le cose che python potrebbe
invidiare a PHP?

Non voglio assolutamente scatenare nessun flame o fare il difensore di
PHP, semplicemente vorrei sapere quali sono le caratteristiche che
usate in caso advocacy ;-)

Hola
Bonzo



-- 
http://www.ilbonzo.org - http://www.matteomagni.net
tel: 051 0546614 - mobile: 366 4336238
via Seminario, 24 - 40068 San Lazzaro di Savena (BO)
skype: ilbonzo.org - http://twitter.com/ilbonzo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python