Re: [Python] Writing Python like it's Rust

2023-05-24 Per discussione Jacopo Cascioli
No, se volessi usare la tipizzazione statica...scriverei in Rust.

Python è diventato uno dei linguaggi più usati perchè ha proposto un modo di 
sviluppare diverso, innovativo ed efficace.

Io mi trovo ad usare Python sempre di meno, proprio perchè queste funzionalità 
le posso trovare implementate meglio in altri linguaggi.

--- Original Message ---
On Wednesday, May 24th, 2023 at 10:25 AM, Luca Bacchi  
wrote:

> Sono incappato in questo articolo:
>
> https://kobzol.github.io/rust/python/2023/05/20/writing-python-like-its-rust.html
>
> e devo riconoscere che descrive un generale approccio allo sviluppo in Python 
> in cui mi sono molto riconosciuto.
>
> Nel mio caso però dovete sostituire Rust con TypeScript: da quando ho 
> cominciato a migrare da JavaScript a TypeScript il mio modo di sviluppare in 
> Python ne ha risentito.
>
> In pratica la tendenza è quella ad usare il più possibile tutti quegli 
> strumenti e quei costrutti che le ultime versioni di Python forniscono per, 
> passatemi il termine, rendere Python più nella direzione dei linguaggi 
> staticamente tipati. È una frase probabilmente molto inesatta ma spero di 
> aver colto nel segno.
> Nel mio caso mi riferisco soprattutto ai Type Hints e alle dataclasses.
>
> Qualcuno direbbe: se pensi che la tipizzazione statica sia migliore allora 
> perché non usare Java al posto di Python?
> A parte che dopo JavaScript, Python è il linguaggio con cui sono più a mio 
> agio, in realtà penso che la strategia di "sviluppare per iterazioni" in cui 
> prima sviluppo e testo se le mie idee sono corrette e funzionano; e poi 
> aggiungo i Type Hint e definisco meglio i tipi con delle classi o delle 
> dataclasses... In sostanza faccio refactoring e irrobustisco ciò che ho 
> fatto, non sua una stratagia che mi dispiace.
>
> Qualcuno nella lista si trova nella mia stessa situazione? Pensate anche voi 
> che lo sviluppo in Python moderno non possa effettivamente fare a meno di 
> questi strumenti?
>
> Ciao a tutti___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Docker, postgresql e barman: suggerimenti cercansi...

2020-05-19 Per discussione Jacopo Cascioli
Ciao Alessandro,

Se vuoi usare docker, devi imparare ad usarlo bene, e usare bene docker è 
complicato e difficile, perchè fa acqua da tante parti e quando qualcosa va 
male, i messaggi o non ci sono o sono prolissi.

È uno strumento punitivo e poco intuitivo, progettato per l'automazione più 
spregiudicata.

Se pensi di risolverti i mal di testa con docker, hai sbagliato strumento, 
soprattutto se si tratta di sistemi che non sono stati disegnati per funzionare 
con docker.

Dopo tutte queste premesse, docker ci va tranquillamente in produzione ed è 
anche piacevole vedere partire tutto con un solo comando...finchè funziona


Jacopo

‐‐‐ Original Message ‐‐‐
On Tuesday 19 May 2020 13:00, Alessandro Dentella  
wrote:

> Ciao a tutti,
>
> sto per cominciare a dockerizzare alcune applicazioni django + frontent in 
> vuejs
> e backend in postgresql.
>
> I db medi con cui ho a che fare sono piccoli, meno di 100 NB, alcuni arrivano 
> a
> qualche GB.
>
> All'inizio ho pensato di tenere un pg classico (non dockerizzato) e fare che
> tutti i siti utilizzino quello. Come vantaggio vedo il fatto di gestire un 
> unico
> backup via barman con meno controlli.
>
> Uno svantaggio però è che ogni volta che devo ripristinare un db devo
> ripristinare tutto il cluster. Questo è quello che ho sempre fatto e non mi 
> pone
> problemi particolari ma mi chiedo se sia la cosa migliore.
>
> Posso ovviamente avere tanti cluster su una macchina fisica e gestire i backup
> in modo indipendente ma mi chiedo se invece mi convenga pensare di usare anche
> per postgres delle istanze indipendenti via docker.
>
> Avete suggerimenti/bast practice da seguire?
>
> grazie in anticipo
> sandro
> *:-)
>
>
> 
>
> Sandro Dentella *:-)
> http://trepalchi.it Il portale degli artisti
> https://wikidattica.it Flashcard per la didattica
> http://www.reteisi.org Soluzioni libere per le scuole
> http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy
>
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python


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


Re: [Python] Come determinare le dipendenze di un progetto Python senza Pipfile o requirements.txt?

2020-04-10 Per discussione Jacopo Cascioli
Ciao Bruno,

Purtroppo Python ha un problema: il package management.

In tempi recenti, la PEP-517 è stata approvata 
(https://www.python.org/dev/peps/pep-0517/) e quindi sono usciti altri package 
manager che lavorano sulla 517, come https://python-poetry.org e 
https://github.com/takluyver/flit

Attenzione a pipenv, poichè non segue la PEP-517, ma viene comunque gestito 
dalla PyPA.

Infine qui (https://www.pypa.io/en/latest/history/) puoi trovare un un po' di 
storia sul package management in Python.

Jacopo Cascioli

‐‐‐ Original Message ‐‐‐
On Friday 10 April 2020 15:04, bruno bossola  wrote:

> Ciao a tutti,
>
> Riemergo sulla lista dopo qualche anno :) e come CTO di un'azienda. 
> [Meterian](https://www.meterian.com/), che si occupa di sicurezza. In pratica 
> il nostro tool, data una codebase, ne determina le dipendenze e verifica che 
> nessuna di esse sia vulnerabile, out of date o che usi una licenza non 
> business friendly. In pratica generiamo dei report tipo 
> [questo](https://www.meterian.com/projects/?pid=2285a757-857f-4bdf-9b5e-d1c5acb27751)
>  o 
> [questo](https://www.meterian.com/projects/?pid=495ac650-b512-498d-b58b-fb5aff4d0320).
>
> Abbiamo implementato il supporto per Python fino a un certo punto :), al 
> momento supportiamo Pipfile e requirements.txt (dove usiamo comunque pipenv 
> per rigenerare il Pipfile) ma direi che ci manca supporto a tutto il resto e 
> siccome io non sono un esperto di Python (cioe', conosco il linguaggio ma 
> professionalmente lo uso solo per scripting e QA al momento) avrei bisogno di 
> aiuto :)
>
> Intravedo per ora altri tre altri fondamentali sistemi per dichiarare le 
> dipendenze:
>
> - setup.py
> - Venv
> - Conda
>
> Per quanto riguarda setup.py credo sia sufficiente usare "python setup.py 
> egg_info" che genera il file .egg-info/requires.txt che a quel punto mi 
> posso andare a leggere. Unica cosa che ho notato e' che non sempre le 
> dipendenze dichiarano una versione, e poi non sono sicuro di riuscire a 
> generare il grafo quindi boh.
>
> Per quanto riguarda venv se ho capito bene crea un virtual environment con 
> tutto dentro, quindi dovrebbe bastare zomparci dentro e fare un pip freeze. 
> Pero' mi mancherebbe il vero grafo delle dipendenze.
>
> Per conda mi sto ancora studiando il tooling, ma mi sembra si possa ottteere 
> il grafo con "conda create --dry-run --json -n " oppure con il nuovo
> comando "conda.models.dag" (che pero' non sono riuscito a fare funzionare.
>
> Se avete suggerimenti li apprezzo molto volentieri. E se volete usare il tool 
> comunque e' gratis per progetti opensource :)
>
> Grazie in anticipo e buona Pasqua (anche se casalinga quest'anno!).
> Ciao,
>
> Bruno
>
> --
> Bruno Bossola
> CTO - [meterian.io](http://meterian.io/)
> [Scan your website now!](https://www.meterian.com/webscanner.html)
>
> [Scan your project now!](https://www.meterian.com/projectscanner.html)___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Generare Screenshot automatici per pagine web

2019-09-26 Per discussione Jacopo Cascioli
Ciao,

non credo ci sia altro modo per farlo. Per fare lo screenshot qualcosa deve 
fare il rendering della pagina - in genere chromedriver o firefoxdriver o altri.
Potresti dare un'occhiata ad API terze che permettono di fare cose simili, se 
funziona per il tuo caso.

Jacopo Cascioli
Freelance software architect
https://jacopocascioli.com

‐‐‐ Original Message ‐‐‐
On Thursday 26 September 2019 11:43, Lorenzo Macchiavelli 
 wrote:

> Buongiorno Lista,
>
> qualcuno potrebbe consigliarmi un modulo di python semplice,
> per generare degli screenshot automatici di pagine web?
>
> Ho provato ChromeDriver, ma mi sembra troppo macchinoso..
> dato che dovrei usarlo in un cron job che parte più volte al giorno,
> non vorrei finestre che si aprono..
>
> Qualche idea?
>
> Grazie
>
> Lorenzo Macchiavelli
> Web Designer - Media Developer
>
> Tel: 349 3411955 Mail: lmacchiave...@gmail.com
> Linkedin: https://www.linkedin.com/in/macchiavelli/___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Deploy Apache2

2019-09-19 Per discussione Jacopo Cascioli
Potresti usare gunicorn e impostare le app su porte diverse e usare nginx + 
proxy_pass per renderle accessibili da un dominio:

https://www.digitalocean.com/community/tutorials/how-to-serve-flask-applications-with-gunicorn-and-nginx-on-ubuntu-18-04

Jacopo Cascioli
Freelance software engineer
https://jacopocascioli.com

‐‐‐ Original Message ‐‐‐
On Thursday, September 19, 2019 4:12 PM, Luca Bacchi  wrote:

> Ciao a tutti!
>
> È possibile fare il deploy su Apache di 2 diverse applicazione WSGI (Flask) 
> che girino una su Python2 e una su Python3, usando mod_wsgi?
>
> Mi sembra di no! Da quanto mi par di capire devo scegliere se installare 
> libapache2-mod-wsgi o libapache2-mod-wsgi-py3. Pertanto la scelta del runtime 
> Python da usare non può essere specificata per il singolo progetto.
>
> Immagino quindi che devo optare per una qualche soluzione di deploy basata su 
> un Reverse Proxy e con un application server tipo uWsgi... immagino, ci 
> capisco il giusto in effetti.
>
> Ciao a tutti e grazie per la comprensione.
>
> Luca___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Servizio di logging da usare con Django

2019-08-31 Per discussione Jacopo Cascioli
Ciao,
putroppo, nel 2020 se uno vuole leggersi i log senza accedere al server, senza 
spendere troppo e senza impazzire con configurazioni di cluster e altra roba, 
non c'è molto.

Potresti provare https://logdna.com se non lo conosci già. Altrimenti, potresti 
provare con fluentd + postgres + superset.

Jacopo Cascioli
Freelance software engineer
https://jacopocascioli.com

‐‐‐ Original Message ‐‐‐
On Tuesday, August 27, 2019 7:44 AM, Karim  wrote:

> Salve lista, sto cercando un servizio online per poter mandare i logs della 
> mia app in django in modo da poter fare debugging senza diventare pazzo a 
> colpi di grep.
>
> Requisiti:
> 1. Budget: 50/70$ mese
> 2. Possibilita' di ricerca, selezione per data, filtro per level... (i 
> servizi per poter fare debugging adeguatamente)
> 3. Supporto python
> 4. Accesso per piu' utenti
>
> Ho avuto modo di guardare i seguenti servizi:
>
> loggly: ho alcuni problemi a farlo andare ed il supporto lascia a desiderare
> insightops: non supporta django
> elastic aws: costosissimo
> datadog: sto ancora valutando
>
> Altra possibilita' sarebbe quella di mettersi il servizio in casa propria con 
> graylog, ma oltre al mantenimento avrei dei costi di vps non indifferenti.
>
> Voi cosa usate?
>
> --
> Karim N. Gorjux___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] problemi con la funzione OPEN in ambiente MAC

2019-08-18 Per discussione Jacopo Cascioli
Se proprio vogliamo essere pignoli, l'uso corretto è:

```
import io
import os

io.open(os.path.join(os.getcwd(), 'miofile'), 'r')
```

- io.open è più facile da testare con patch (ti servirà per dopo)
- os.path.join si occupa di costruire il percorso corretto indipendentemente 
dal sistema
- os.getcwd restituisce il percorso da cui è stato lanciato lo script

A questo punto ti devi solo preoccupare di lanciare lo script nella cartella 
dove è il tuo file.

Jacopo Cascioli
Freelance software engineer
https://jacopocascioli.com

‐‐‐ Original Message ‐‐‐
On Saturday, August 17, 2019 11:51 PM, Francesco Tuccia 
 wrote:

> grazie, provo subito! :)
>
> Il giorno sab 17 ago 2019 alle ore 23:27 Marco Beri  ha 
> scritto:
>
>> On Sat, 17 Aug 2019, 23:13 Francesco Tuccia,  wrote:
>>
>>> ma niente, il messaggio di Python è sempre lo stesso:
>>>
>>> Traceback (most recent call last):
>>>
>>>   File "/Users/Francesco/Desktop/PYTHON /PYTHON MAGGIOLINA/MAGGIOLINA 
>>> LEZ.12.py", line 5, in 
>>>
>>> maschi = open ("'897453/Utenti/Francesco/Scrivania/NomiMaschili.txt", 
>>> "r")
>>>
>>> FileNotFoundError: [Errno 2] No such file or directory: 
>>> "'897453/Utenti/Francesco/Scrivania/NomiMaschili.txt"
>>
>> Non uso Mac ma l'errore ti aiuta. Metti il file nella stessa directory del 
>> file MAGGIOLINA LEZ.12.py e aprilo con questo nome:
>> "/Users/Francesco/Desktop/PYTHON /PYTHON MAGGIOLINA/NomiMaschili.txt"
>>
>> Ciao.
>> Marco.
>> ___
>> Python mailing list
>> Python@lists.python.it
>> https://lists.python.it/mailman/listinfo/python___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Semplice DB.

2019-08-16 Per discussione Jacopo Cascioli
Ciao,

mi sembra un caso da DSL, perciò potresti andare con
https://github.com/lark-parser/lark o strumenti simili (o fare riferimento
all'altro post sui parser)

Jacopo

Il giorno mer 10 lug 2019 alle ore 15:21 ㎝  ha scritto:

> Il giorno mer 10 lug 2019 alle ore 15:00 Gabriele Battaglia
>  ha scritto:
>
> > E' come se avessi:
> >
> > 
> > nome: xxx, cognome: yyy, data: zzz
> > 
> >
> > Ma anche:
> >
> > 
> > data: zzz, cognome: yyy, nome: xxx
> > 
> >
> > Perciò, quando assegno i dati alla tupla avrò che ogni record presenterà
> > campi diversi nella stessa posizione indicizzata: ad esempio db[0][0] ci
> > sarà il nome, mentre db[1][0] presenterà la data.
>
> Io ti consiglierei una lista di dict, o forse ancora meglio una lista
> di namedtuple
> ```
> >>> d1 = {'nome': 'xxx', 'cognome': 'yyy', 'data': 'zzz'}
> >>> d2 = {'data': 'zzz', 'cognome': 'yyy', 'nome': 'xxx'}
> >>> d1 == d2
> True
> >>> from collections import namedtuple
> >>> N = namedtuple('N', 'nome cognome data')
> >>> n1 = N(nome='xxx', cognome='yyy', data='zzz')
> >>> n2 = N(data='zzz', cognome='yyy', nome='xxx')
> >>> n1 == n2
> True
> >>> n1[0]
> 'xxx'
> >>> n2[0]
> 'xxx'
> ```
> ㎝
>
> --
>  THE -WARE LICENSE (Revision ㊷):
> <㎝@.it> wrote this . As long as you retain this notice you can
> do whatever you want with this stuff. If we meet some day, and you
> think this stuff is worth it, you can buy me a  in return. — ㎝
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] jcl parser in python

2019-08-16 Per discussione Jacopo Cascioli
Ciao,

non ci sono molte risorse sul parsing e l'implementazione dei linguaggi. È
un capitolo poco toccato al giorno d'oggi e ci sono davvero poche persone
che sanno implementare un parser per un dato algoritmo.
Il parsing non è difficile, perchè ci sono librerie e strumenti vari;
scrivere la grammatica è la parte che prende più tempo.

Quindi:
- https://github.com/lark-parser/lark (LALR+EBNF)
- https://medium.com/@gvanrossum_83706/peg-parsers-7ed72462f97c (Guido sul
parser di Python, LALR-simile, e perchè ha senso considerare PEG)
- https://martinfowler.com/books/dsl.html (Non ha bisogno di presentazioni!)
- https://docs.python.org/3/reference/grammar.html (EBNF di Python)
- https://github.com/storyscript/storyscript/ (esempio di grammatica EBNF)


Il giorno mar 6 ago 2019 alle ore 09:57 daniele visaggio <
visaggio.dani...@gmail.com> ha scritto:

> Suggerisco https://tomassetti.me/antlr-mega-tutorial/ per iniziare con
> antlr.
>
> Due libri utili sull'argomento sono "Language Implementation Patterns" e
> "The Definitive ANTLR 4 Reference", entrambi di Terence Parr.
>
> Il giorno lun 5 ago 2019 alle ore 22:39 Balan Victor <
> balan.vict...@gmail.com> ha scritto:
>
>> Il giorno lun 5 ago 2019 alle ore 21:47 Marco Beri 
>> ha scritto:
>>
>>> On Mon, Aug 5, 2019 at 9:43 PM Balan Victor 
>>> wrote:
>>>
 Ora, prima di partire in guarda e di incartarmi in una serie infinita
 di for & if, volevo sapere se qualcuno ha qualche approccio particolare da
 consigliare.

>>>
>>> https://fdik.org/pyPEG/
>>>
>>> Ciao.
>>> Marco.
>>>
>>> --
>>> http://beri.it/ - Un blog
>>> http://beri.it/i-miei-libri/ - Qualche libro
>>> http://beri.it/articoli/ - Qualche articolo
>>> ___
>>> Python mailing list
>>> Python@lists.python.it
>>> https://lists.python.it/mailman/listinfo/python
>>>
>>
>>
>> Grazie per il veloce ritorno.
>> Ho guardato un po la doc di pyPeg e googlando mi sono imbattuto anche in
>> un suo concorrente(pyParsing) e in ANTRL.
>>
>> Se volessi prendere un po di confidenza con concetti con il parsing in
>> generale hai qualche guida/libro(magari anche in italiano) da suggerire?
>>
>>
>> 
>>  Mail
>> priva di virus. www.avast.com
>> 
>> <#m_-8166951035987283104_m_6877984569640218483_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> Python mailing list
>> Python@lists.python.it
>> https://lists.python.it/mailman/listinfo/python
>>
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] [Django] [Django Rest FrameWork] upload & download files

2019-01-19 Per discussione Jacopo Cascioli
L'ultima volta che ho provato DRF l'ho scartato perchè è limitante e
complicato. Se vuoi rimanere in ambito Django, non so se ci siano altre
opzioni più utili; Flask comunque ha un ottimo supporto per REST; c'è anche
falcon ma richiede più smanettamento.

Uno dei vantaggi di REST è che essendo uniforme, puoi generalizzare e
generare moltissime cose (quasi tutte in effetti). Per le risorse più
complesse che usano dati da più tabelle non correlate puoi sempre fare
delle eccezioni e scriverle a mano. Putroppo la comunità REST non ha mai
prodotto un framework che sfrutti ciò a pieno anche per la questione
HATEOAS (ovvero come fornire i link a ciascuna risorsa): ci sono tantissimi
formati e anche molte opinioni, incluse quelle di chi suggerisce di non
usarlo. Evidentemente non hanno capito la specifica: REST deve usare un
sistema di HATEOAS oppure è semplicemente un API che produce JSON. Credo
che senza complicarsi troppo le cose ci siano due scelte HAL (se non vuoi
problemi) o Siren (se sei un perfezionista).

Per quanto concerne il futuro, GraphQL sta prendendo piede ovunque ma io mi
dissocio, considerate le premesse tecniche da film horror e chi lo
sponsorizza. Ultimamente leggo su twitter alcuni lamentarsi che GraphQL
produce un carico notevole a causa delle molte JOIN - un sorpresone, visto
che GraphQL intende risolvere il problema della gente che non sa
strutturare un database a forza di JOIN 
Quindi in sostanza per un API pubblica la soluzione rimane REST, mentre per
le API interne c'è grpc.

È sempre più conveniente mantenere ciò che già funziona, non lo facciamo
perchè vogliamo il giocattolino nuovo :)

Risorse:
- https://github.com/getefesto/efesto (API in Siren da un file YAML, su
falcon)
- https://github.com/falconry/falcon
- https://github.com/kevinswiber/siren
- https://gist.github.com/kevinswiber/3066768 (Siren vs HAL)
- https://flask-restful.readthedocs.io/en/latest/
- https://grpc.io/


Il giorno ven 18 gen 2019 alle ore 17:05 Luca  ha
scritto:

> Salve Lista,
>
> Negli ultimi 6 anni ho utilizato con successo JSON-WSP (
> https://en.wikipedia.org/wiki/JSON-WSP) tramite ladon lato server (
> https://bitbucket.org/jakobsg/ladon) e un mio client lato client (
> https://jsonwspclient.readthedocs.io/en/latest/).
> Ora sto cercando di passare il tutto sotto Django Rest Framework perchè mi
> piace l'idea.
>
> Mi sto guardando la documentazione di DRF e di Django.
> Se ho capito bene l'unico sistema che prevede DRF per inviare files è
> utilizzare un Modello con campo FileField e usare il FileUploadParser.
>
> Qualcuno di voi ha esperienze a rigurado ?
> Sa consigliarmi una via ?
> E' più conveniente mantenere le cose che già funzionano anche se il
> JSON-WSP sembra non avere un futuro ? E comunque io vorrei RESTare il tutto
> ?
> Avete esempi e/o documentazione ?
> Qualcuno ha visto dove ho dimenticato le chiavi di casa ?
>
> grassie in anticipo
> --
> Luca
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] evvai! finalmente funziona!

2018-07-24 Per discussione Jacopo Cascioli
Dovresti leggere l'input, capire che tipo di operazione è, e poi eseguirla.
Molto banalmente, dato un input potresti fare split per trovare gli
operatori e usare for per calcolare:

> input_calcolatrice.split('+', '*', '/', '-')

Non ho partecipato alla discussione, ma ho letto che sei non vedente e sei
su windows. Hai provato ad usare un cloud IDE da browser?

Jacopo

Il giorno 24 luglio 2018 12:08, laziale  ha
scritto:

> ma se io volessi fare una calcolatrice, di quelle normali, cioè, non
> scrivendo nel codice che operazione voglio fare, come devo fare?
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] REST security & co: qualcuno usa paseto invece di JOSE/JWT?

2018-03-18 Per discussione Jacopo Cascioli
Ma ribatto punto per punto l'ennesima specifica di cui non c'era bisogno,
bastava saper programmare:

- JSON Web Tokens are Often Misused: come da intro, se un programmatore non
ce la fa, non ce la fa nemmeno con una specifica più sicura e troverà il
modo di implementarla in maniera non sicura
- JSON Web Signatures Makes Forgery Trivial: in teoria la specifica dice
che i JWT vanno firmati con una chiave segreta, ma shhh che devono
promuovere il loro progetto. Bastava leggere la specifica.
- JSON Web Encryption is a Foot-Gun: Eh, la crittografia è difficile, a
meno che tu non sia un esperto in crittografia. Dopo questa fantastica
scoperta, diciamo anche che le specifiche possono essere aggiornate, così
da togliere algoritmi non sicuri in favori di quelli più sicuri.

Jacopo

Il giorno 9 marzo 2018 16:04, Ernesto Arbitrio 
ha scritto:

>
> 2018-03-09 15:58 GMT+01:00 Roberto Polli :
>
>> Ciao belli,
>>
>> qualcuno usa questo invece dei classici JWT/JOSE?
>>
>> https://github.com/paragonie/paseto
>
> mai visto, glie damo na letta!
> grazie Rob
>
>>
>>
>> Pax,
>> R:
>> ___
>> Python mailing list
>> Python@lists.python.it
>> https://lists.python.it/mailman/listinfo/python
>>
>
>
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Soap con XML: cosa suggerite

2018-03-18 Per discussione Jacopo Cascioli
Consiglio un nuovo commerciale :)

Jacopo

Il giorno 18 marzo 2018 09:09, daniele visaggio 
ha scritto:

> http://docs.python-zeep.org/en/master/
>
> È un client soap in python. In pratica, è l'unico attualmente disponibile.
>
> Ciao
>
> On Sun, Mar 18, 2018, 10:05 Fundor 333  wrote:
>
>> Il commerciale di dove lavoro ha preso un applicativo fichissimo,
>> modernissimo, ultra innovativo talmente figo che neanche Google ce lo ha
>> (circa) e devo collegarmi via webserver.
>>
>> Essendo un sistema innovativo e moderno si può accedere solo via Soap e
>> XML e quindi cosa mi consigliate per connettersi a questo sistema?
>> Dal nostro lato c'è un applicativo Django a cui devo connettere questo
>> "applicativo".
>>
>> Grazie mille
>> Fundor333
>> --
>>
>> Fundor333
>> https://fundor333.com
>> ___
>> Python mailing list
>> Python@lists.python.it
>> https://lists.python.it/mailman/listinfo/python
>>
>
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Ma non vi sembra che sia una epidemia?

2018-02-04 Per discussione Jacopo Cascioli
Siamo in tempo di esami. Anche noi siamo molto tonti: potremmo vendergli le
soluzioni, così loro sono contenti e noi pure :P

Jacopo

Il giorno 4 febbraio 2018 10:02, Carlos Catucci 
ha scritto:

> ​Tutti questi universitari ​che invece di provare a capire cercano
> scorciatoie, qualcuno che faccia i compiti per loro, possibilmente a
> gratis* ? Un tempo (va beh c'era meno telematica in giro) non mi sembra ci
> fosse questo probnlema. AL massimo il bimbominkia che non voleva studiare e
> chiedeva la soluzione "ready-to-go" sulla ML e sul Forusm o Newsgroup (si
> sono uno dei vecchi che usava Usenet)
>
>
> *
> ​ ​
> anche se io non glie li farei neppure a paga
> ​mento, se devi prendere una laurea si presume che hai studiato quello che
> il corso prevede che studi.
> Il fatto di dire "ma a me non interessa programmare in XYZ" non giustifica
> nulla, se in quel corso hann previsto un esame che lo richiede un mot​ivo
> deve esserci. Magari insegnarti a "pensare" e non limitarti a ripetere a
> pappagallo le cose scritte sul libro o sulle dispese dei professori.
>
> ​O no?​
>
>
> ​Carlos​
> --
> EZLN ... Para Todos Todo ... Nada para nosotros
>
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] [CGI]

2018-01-06 Per discussione Jacopo Cascioli
>
> Leggendo diversa documentazione, mi pareva di aver capito che posso
> usare direttamente uwsgi come server, ma vedo che invece tu hai optato
> per usare nginx + uwsgi. Pro e Contro sulle due diverse situazioni?


Sì, in effetti si può usare solo uwsgi e se non hai particolari necessità,
funziona. Ovviamente tutte le cose che normalmente configureresti in nginx
(caching, domini, riscrittura degli url, etc.) le perdi e non so quanto
uwsgi supporti queste opzioni o quanto facile possa essere configurarle con
uwsgi o in altri modi.

Jacopo

Il giorno 6 gennaio 2018 09:42, Raffaele Salmaso  ha
scritto:

> Ciao,
>
> 2017-12-27 17:35 GMT+01:00 Gollum1 :
>
>> Leggendo diversa documentazione, mi pareva di aver capito che posso
>> usare direttamente uwsgi come server, ma vedo che invece tu hai optato
>> per usare nginx + uwsgi. Pro e Contro sulle due diverse situazioni?
>>
> Non ne ho idea. È sulla lista delle cose da provare usare solo uwsgi come
> server,
> ma non so se è cmq utile/buona idea se non in casi specifici. Vedremo.
>
> Posso interpellarti, nel momento in cui fossi riuscito ad installare i
>> singoli pacchetti, per un aiuto sulla configurazione con i diversi
>> linguaggi? io ho necessità di fornire pagine statiche html, pagine
>> realizzate in php e in python (attualmente 2.7, ma in futuro spero di
>> riuscire a migrare a 3.x).
>>
> Non uso red hat, e sinceramente evito i lavori che mi impongono
> py2.6/py2.7 o non aggiornabili
> (qui è solo per l'interfaccia di mercurial, visto che la versione py3 non
> è ancora pronta).
>
> Nel caso specifico di uwsgi ho scaricato i sorgenti e ricompilo con questo
> script, dopo aver installato i pacchetti -dev necessari.
>
> #!/bin/sh
> python3.6 uwsgiconfig.py --build core
> python2.7 uwsgiconfig.py --plugin plugins/python core python27
> python3.4 uwsgiconfig.py --plugin plugins/python core python34
> #python3.5 uwsgiconfig.py --plugin plugins/python core python35
> python3.6 uwsgiconfig.py --plugin plugins/python core python36
> ./uwsgi --build-plugin "plugins/router_static"
> ./uwsgi --build-plugin "plugins/router_http"
> ./uwsgi --build-plugin "plugins/syslog"
> ./uwsgi --build-plugin "plugins/http"
> ./uwsgi --build-plugin "plugins/php"
> ./uwsgi --build-plugin "plugins/cgi"
>
> --
> | Raffaele Salmaso
> | https://salmaso.org
> | https://bitbucket.org/rsalmaso
> | https://github.com/rsalmaso
>
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Versioni dei moduli.

2017-11-06 Per discussione Jacopo Cascioli
Sì e no. È più una questione di evoluzione naturale del pacchetto.

La prima volta versione che pubblichi è 0.1 o 0.0.1, aumentando a mano a
mano che vengono aggiunte funzionalità o aggiustati bug. All'inizio,
sopratutto per pacchetti sviluppati da una sola persona, non c'è un feature
plan, quindi nemmeno l'autore ha deciso quando ci sarà un versione 1.0.
Molte volte c'è una questione di sperimentazione, perciò è impossibile
stabilire a priori quando qualcosa diventare stabile.

Se il progetto ha successo e si uniscono altri sviluppatori, le cose
cambiano e c'è un'organizzazione migliore da questo punto di vista, ma non
sempre. Flask per esempio è rimasto tantissimo tempo alla 0.11 e di fatto,
secondo l'autore, è stabile ma la versione corrente è ancora 0.12

Ogni progetto ha la sua politica per il versionamento, vedi Angular che usa
numeri interi o Django che sta per rilasciare la 2.0 senza cambiamenti
sostanziali nell'API.

Quindi:
- Sì lo 0.X si usa per indicare versioni instabili
- No, semplicemente c'è una tendenza a non fare il passaggio a 1.0 anche
quando il software è maturato, in uso da migliaia di persone e stabile, e
non solo in Python


Jacopo

Il giorno 6 novembre 2017 18:10, Gabriele Battaglia  ha
scritto:

> Sera.
> Ho una curiosità sull’utilizzo dei numeri di versione nei moduli per
> Python.
> Noto che si tratta sempre, o quasi, di numeri molto bassi e che hanno uno
> “0”, come major release.
> Cose come 0.11.0, 0.4.5, 0.6.1, solo per citarne 3 che ho visto
> recentemente. Ma questo ha qualcosa a che fare col fatto che si tratta di
> software inaffidabile, instabile oppure no? Questi numeri di versione mi
> ricordano rilasci beta, quando se non anche alpha.
> E’ così, oppure esiste una specie di convenzione diciamo non scritta, fra
> gli sviluppatori di moduli che adottano tutti quanti e che li consiglia di
> numerare così basse, le versioni che rilasciano?
>
> Grazie per l’eventuale chiarimento, se ce ne fosse.
> Chiaro che si tratta di una curiosità, in realtà, se il pacchetto
> funziona, non me ne può fregare di meno, del suo numero di versione.
> Gabriele.
> —
> Namasté!
> Sent from my iMac27. (Libero)
>
>
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Richiesta consiglo Nodejs vs Python HandMade

2017-10-18 Per discussione Jacopo Cascioli
>
>
> Grazie Jacopo,
>
> Ho guardato un po' di cose, grunt e il tuo file di configurazione.
> Alla fine smadonnando un po' sono riuscito a far fare quello che volevo a
> webpack.
>

Mi fa piacere che ti sia stato d'aiuto.


Ovviamente rimane una mia impressione, quest'ultima, ma per il primo
> punto la domanda rimane? Che senso ha?
>

Node è nato quando il supporto per le operazioni asincrone non era così
diffuso. Adesso è ovunque, ma prima a meno di usare linguaggi più esotici
non c'erano molte alternative.

Credo che da qualche parte su internet ci sia il creatore che spiega che
Node è un linguaggio pensato per le piccole aziende con pochi soldi, dove
supportare un linguaggio di programmazione in più può incidere tanto sui
costi. L'idea di Node è che sviluppare frontend o backend richiedesse solo
linguaggi diversi, quando invece ci sono problematiche completamente
diverse. Quando hai un frontend poco esperto che scrive anche codice
backend, hai un problema e questo è esattamente quello che è successo con
Node.

Questo non vuol dire che tra tre o cinque anni non risolvano questi
problemi. Nel frattempo, è uno strumento indispensabile per lo sviluppo
frontend e non ha avversari  che si candidino a togliergli il monopolio.

Jacopo

Il giorno 18 ottobre 2017 11:57, Carlos Catucci 
ha scritto:

> Nota: Il top quting e' male. Gollum veglia.
>
> 2017-10-18 10:09 GMT+02:00 salvatore monaco :
> > node.js è molto peggio di PHP, credo sia una sua metastasi
>
> Quello che mi ppongo come quesito io e':
>
> La motivazione di fondo di Node.js sarebbe che cosi' si ha un solo
> linguaggio di programmazione da ambo i lati (Frontend e Bacckend).
> Ora posto che non intendo dire nulla di male nei confronti di EC6 come
> linguaggio (quasi tutti i linguaggi hanno un prerche' di esistere), ma
> solo contro il framework,
> con l'attuale tendenza a usare sempre piu' (se non del tutto)
> architteture a microservices e/o API RESTfull, avendo anche  la
> possibilità di utilizzare servizi esposti da terze parti (che sono de
> facto delle black box) che senso ha preoccuparsi di avere lo stesso
> linguagio lato server?
> Senza avere pretesa di avere inventato nulla o di essere stato un
> precursore, tati altri lo hanno fatto ben prima di me, utilizzavo da
> anni (senza nulla sapere di microservices) chiamate ad API Rest
> scritte a volte in linguaggi differneti, per motivi prestazionali
> oppure per cose particolari (parallelismo ad esempio).
> Oltretutto ho notato una certa fragilità del sistema. Siccome e
> autoreferenziante, ovvero motli moduli usano altri moduli che sono
> stati inglobati nel framework, sebbene siano stati scritti da persone
> esterne che li hanno rilasciati (un poco come ha fatto, dopo lungo
> tempo Django con South per gestire le migrazioni dei models, solo che
> qui e' stata una cosa pianificata con cura e introdotta gradualmente,
> mentre in node ho visto casi di librerie o componenti presi senza
> neppure essere stati testati troppo a lungo e mesis dentro), si
> presentano casi come quello in cui un autore di uno dei piu'
> utiolizzati moduli, per una ripicca, aveva rimosos il modulo dai repo
> e pertanto aeva inchiodato tutti coloro che usavano la CDN di node.
>
> Ovviamente rimane una mia impressione, quest'ultima, ma per il primo
> punto la domanda rimane? Che senso ha?
> Come dice quel comico partenopeo che parla di musica:
>
> "La domanda non e' chi e', la domandfa e' pecche'?"
>
> Carlos
> --
> EZLN ... Para Todos Todo ... Nada para nosotros
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Richiesta consiglo Nodejs vs Python HandMade

2017-10-16 Per discussione Jacopo Cascioli
Allora, sinceramente non ho usato molto yarn/webpack, ma ho usato Grunt
parecchio. Il problema di questi strumenti è che fanno quello che gli dici,
ma per tirarne fuori un risultato ottimale serve davvero tanto tempo e
impegno per configurarli come si deve.

Ad esempio, io saprei configurare Grunt per fare quello che vuoi fare tu,
ma ci sono riuscito solo dopo averne preso familiarità.

Più in general, il problema di Node è una scarsa documentazione e un basso
livello di qualità del codice, anche nei principali framework o librerie.
PHP può avere tanti problemi, ma non si può negare che alcuni framework
siano veramente ben fatti.

I suggerimenti che posso dare sono quelli di insistere prendendo coscienza
delle limitazioni; provare anche altre soluzione come grunt, gulp,
ecc...almeno finchè rimani dell'idea di giocare con Node/npm.

Posso postare un esempio della configurazione di Grunt:
https://github.com/Vesuvium/dotfiles/blob/master/npm/Gruntfile.js


Jacopo

Il giorno 16 ottobre 2017 19:12, Carlos Catucci 
ha scritto:

>
>
> Il 16 ott 2017 5:55 PM, "Nicola Larosa"  ha scritto:
>
> Luca wrote:
> > Non sono a chiedervi dei consigli su nodejs
>
> Meno male.
>
>
> > (a meno che non siate compassionevoli).
>
> Nessuna pietà per gli autolesionisti.
>
>
> > grazie per la pazienza (e per la clemenza)
>
> Scarseggiano entrambe di questi tempi
>
>
> Vedo che Nicola la pensa come me di node.js, penso che forse sia pure
> peggio di PHP.
>
>
> Carlos
>
>
>
>
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Microservices: esperienze & feedback

2017-10-16 Per discussione Jacopo Cascioli
> Se posso chiedere quale/i sono stati i motivi per il rifiuto, e cosa ha
> portato poi in pochi mesi a dover rivedere la scelta?
>

Il principale motivo è la poca familiarità con la tecnologia, anche se ne
comprendono il funzionamento. Si tratta di un progetto grande, quindi prima
o poi sarebbe passato comunque ai microservizi: la questione era quando
sarebbe successo.


Per il momento, come standard, considero Token JWT generati da un
> microservice, l’unico in possesso della chiave privata per firmarli.
> La chiave pubblica viene sempre offerta da questo micro service.
> Il token dura generalmente da qualche ora ad un giorno.
>

 Va bene. A me piace calcare la mano sulla sicurezza, OAuth2 + JWT è un po'
più sicuro, ma soprattutto ti risparmi il problema di supportare client
precedenti che non usano Oauth2, semmai dovresti aggiungerlo. Nel mio caso,
so che OAuth2 verrà implementato comunque in futuro.

Altra domanda, a livello di database come l’avete risolto?
>
> Avete scelto una soluzione dogmatica, una database per ogni micro service?
> Una soluzione shared? Database dietro ad un microservice?


Nel mio caso è un po' più problematico, ma ogni microservizio dovrebbe
gestire i suoi dati o finisci per avere un problema di codice doppio. Puoi
scrivere una libreria solo per i modelli condivisi, ma poi hai un sistema
un scomodo da installare e gestire.
Ovviamente se hai un database per ogni microservizio, devi avere un sistema
di eventi con RabbitMQ o simili per non perdere performance sul servizio
che espone i dati, quindi il DB di quest'ultimo di fatto è in sola lettura
e viene modificato dagli altri quando ricevono gli eventi.

Jacopo

Il giorno 13 ottobre 2017 13:44, Christian Barra <barrac...@gmail.com> ha
scritto:

>
>
> > On 12 Oct 2017, at 23:31, Jacopo Cascioli <jacopocasci...@gmail.com>
> wrote:
> >
> > Ti interessano anche esperienze sulla difficoltà del convincere il team
> ad usare microservizi? :P
>
> Assolutamente!
>
> >
> > Posso dire che c'è grande scetticismo, soprattutto da figure di
> responsabilità all'uso di microservizi, nonostante siano indispensabili per
> qualunque progetto complesso, anche solo per alcune parti del sistema.
> > La mia brutta esperienza è averli proposti, vederli rifiutati e dopo
> pochi mesi doverli fare comunque. Se state facendo qualcosa di nuovo e
> sufficientemente grande, fatelo con la cognizione che ad un certo punto
> sarete comunque costretti ad avere microservizi.
>
> Se posso chiedere quale/i sono stati i motivi per il rifiuto, e cosa ha
> portato poi in pochi mesi a dover rivedere la scelta?
>
> >
> > L'ideale è avere un server OAuth2 che produca JWT come access token, ma
> in Python non esiste niente che lo supporti per intero. Quindi dovrete
> scegliere tra usare OAuth2 con l'introspezione (lento), JWT senza OAuth2
> (meno sicuro), scrivere il codice per supportarlo o usare altro (Auth0 o
> server OAuth2 in altri linguaggi).
>
> Per il momento, come standard, considero Token JWT generati da un
> microservice, l’unico in possesso della chiave privata per firmarli.
> La chiave pubblica viene sempre offerta da questo micro service.
> Il token dura generalmente da qualche ora ad un giorno.
>
>
> Altra domanda, a livello di database come l’avete risolto?
>
> Avete scelto una soluzione dogmatica, una database per ogni micro service?
> Una soluzione shared? Database dietro ad un microservice?
>
>
> Grazie per la risposta!
>
> ——
> Christian Barra
> Python Freelancer // Consultant // Trainer
> Board member of the EuroPython Society
> www.chrisbarra.xyz
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>


Il giorno 13 ottobre 2017 13:44, Christian Barra <barrac...@gmail.com> ha
scritto:

>
>
> > On 12 Oct 2017, at 23:31, Jacopo Cascioli <jacopocasci...@gmail.com>
> wrote:
> >
> > Ti interessano anche esperienze sulla difficoltà del convincere il team
> ad usare microservizi? :P
>
> Assolutamente!
>
> >
> > Posso dire che c'è grande scetticismo, soprattutto da figure di
> responsabilità all'uso di microservizi, nonostante siano indispensabili per
> qualunque progetto complesso, anche solo per alcune parti del sistema.
> > La mia brutta esperienza è averli proposti, vederli rifiutati e dopo
> pochi mesi doverli fare comunque. Se state facendo qualcosa di nuovo e
> sufficientemente grande, fatelo con la cognizione che ad un certo punto
> sarete comunque costretti ad avere microservizi.
>
> Se posso chiedere quale/i sono stati i motivi per il rifiuto, e cosa ha
> portato poi in pochi mesi a dover rivedere la scelta?
>
> >
> > L'ideale 

Re: [Python] Microservices: esperienze & feedback

2017-10-12 Per discussione Jacopo Cascioli
Ti interessano anche esperienze sulla difficoltà del convincere il team ad
usare microservizi? :P

Posso dire che c'è grande scetticismo, soprattutto da figure di
responsabilità all'uso di microservizi, nonostante siano indispensabili per
qualunque progetto complesso, anche solo per alcune parti del sistema.
La mia brutta esperienza è averli proposti, vederli rifiutati e dopo pochi
mesi doverli fare comunque. Se state facendo qualcosa di nuovo e
sufficientemente grande, fatelo con la cognizione che ad un certo punto
sarete comunque costretti ad avere microservizi.

In questo caso, o nel caso in cui stiate partendo da qualcosa di già
esistente, il problema principale non sarà tanto strutturare i
microservizi, quanto cambiare il sistema di autenticazione per gli utenti,
a meno che non stiate già usando OAuth2 o JWT.

L'ideale è avere un server OAuth2 che produca JWT come access token, ma in
Python non esiste niente che lo supporti per intero. Quindi dovrete
scegliere tra usare OAuth2 con l'introspezione (lento), JWT senza OAuth2
(meno sicuro), scrivere il codice per supportarlo o usare altro (Auth0 o
server OAuth2 in altri linguaggi).

Jacopo

Il giorno 9 ottobre 2017 20:59, Christian Barra  ha
scritto:

> Hello ML,
> sto buttando giu’ un paio di idee per un workshop ((Micro)Services with
> Asyncio and Docker) che vorrei preparare.
>
> Esperienze e feedback riguardanti l’implementazione di Microservices?
>
> Sia partendo da zero che il refactoring di applicazioni esistenti.
>
> Sia belle che brutte, quelle brutte solitamente sono più’ interessanti :p
>
> Saluti,
> ——
> Christian Barra
> Python Freelancer // Consultant // Trainer
> Board member of the EuroPython Society
> www.chrisbarra.xyz
>
>
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Aiuto inizio insegnamento python nel corso telecomunicazioni

2017-09-27 Per discussione Jacopo Cascioli
In questo caso io ti consiglio VisualStudio Code, perchè è meno complicato
di PyCharm, ma è meno da smanettoni di Atom.

Come materiale c'è anche Dive into Python 
che copre le basi ed è il più famoso tra quelli disponibili gratuitamente
(e forse lo trovi anche in italiano). Ci sono anche Learn Python the Hard
Way  e Hitchiker guide's to Python
, che parla più di come
strutturare un progetto e regole pratiche da seguire. Infine awesome python
, cioè una lista dei più
importanti e utili framework, librerie e strumenti di ogni sorta.
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] [OT] Dove siete tutti?

2017-09-27 Per discussione Jacopo Cascioli
Era il 16 :)
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] [OT] Dove siete tutti?

2017-09-27 Per discussione Jacopo Cascioli
Sono ancora tutti ubriachi per il mio compleanno :P
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] TemPy - OOP template engine in python - cerco opinioni e collaboratori

2017-08-12 Per discussione Jacopo Cascioli
Sembra interessante, ma non ci sono link. Sono io che non lo vedo?
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python


Re: [Python] Quale IDE

2017-07-01 Per discussione Jacopo Cascioli
Forse per qualcuno che inizia Visual Studio Code è più semplice, se non
altro perchè ha già alcuni plugin che su Atom vanno installati. Forse Atom
è un po' più personalizzabile. Questi sono due editor semplici, che però
richiedono un computer recente. Se hai un computer più vecchio, potresti
orientarti verso SublimeText.

PyCharm è utile più che altro per alcune funzionalità avanzate, ma io
personalmente non ne ho mai avuto bisogno.

Li puoi scaricare tutti gratuitamente e provarli. A questo potrebbe essere
interessante anche provare vim: ti tornerà utile quando farai operazioni su
server da terminale, oltre ad essere un editor storico che fa parte della
cultura tecnologica. Bonus points se riusci ad uscire da vim senza cercare
su Google!


Il giorno 1 luglio 2017 18:46, Francesco Maida 
ha scritto:

> Il giorno 1 luglio 2017 14:02, Carlos Catucci 
> ha scritto:
>
>>
>> PyCharm essendo java based a me non piace
>
>
>
> Evabbè, anch'io penso che Javascript sia simpatico quanto un mal di denti
> a ferragosto, però Atom e Visual Studio Code mi piaciono anche se sono
> entrambi basati su Electron = node.js = javascript :-)
>
> Come cantava Fabrizio De Andrè: "Dai diamanti non nasce niente, dal letame
> nascono i fiori." ;-)
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Che ne pensate?

2017-04-19 Per discussione Jacopo Cascioli
Sembra interessante, ma è da un po' che ci sono framework Python in grado
di superare le performance di Node, anche senza sfruttare roba asincrona.
Il vero confronto che oggi conta per Python in questi termini è quello con
go, ed è esattamente dove uvloop va a parare.
Inoltre, in generale, se si pensa a come funziona Node, credo che chiunque
con un po' di conoscenza informatica sarebbe arrivato a capire che era solo
questione di avere il framework giusto, piuttosto che di linguaggio.

Personalmente, io vedo l'asincronicità come un'ottimizzazione, perciò ha
senso solo e solo se il limite è effettivamente dato dall'I/O, perchè molte
volte il problema non è quello. I benchmark vanno presi con le pinze anche
per questo: a volte la velocità in più ottenuta è dovuta ad ottimizzazioni
che non hanno niente a che fare con l'asincronicità.

In questo hanno usato pypy per falcon, ma non cython, per il quale falcon
ha un supporto migliore. Hanno usato gunicorn e non uwsgi, che in genere dà
risultati migliori e ed è quello che verebbe usato: questo va ancora a
vantaggio di sanic, visto che non ha bisogno di nessuno dei due. Sanic usa
websockets, falcon no, flask neppure e il problema di websockets è che non
ci fai API RESTful, perchè funziona in maniera completamente diversa.
Ancora: sanic usa ujson, ma falcon no e il benchmark riguarda proprio JSON!
Quindi, non è chiaro a cosa sia dovuta la performance di sanic, ma io
conosco molto bene falcon, e sono sicuro che fare lo stesso test, lanciando
falcon con uwsgi + ujson, darebbe altri risultati, fermo restando che
confrontare un framework websockets con uno che usa http è ridicolo.

Il fatto che ci sia un framework che la fornisce già pronta è positivo,
così il modo in cui la comunità sta digerendo e processando l'async in
Python. Il fatto che la questione sincrono/asincrono venga portata avanti a
benchmark fatti male invece è un cancro che va estirpato.

Jacopo



2017-04-19 21:26 GMT+02:00 Carlos Catucci :

> Sorry, node.js, Python is faster!
>
> For a very long time now, node.js has evolved nicely. This was
> because, right from beginning, it was designed to run smoothly, non
> blocking, async mode.
>
> Green threads - instead of pthreads with giant overhead - were the
> right way for low latency applications.
>
> But now there is libuv module for Python 3. Means: Python still runs
> single thread with GIL, but libuv C module runs in a multi-threaded,
> interleaved way to serve tens of thousands of TCP/UDP clients
> smoothly.
>
> https://github.com/channelcat/sanic/blob/master/README.rst
>
>
> Carlos
> --
> EZLN ... Para Todos Todo ... Nada para nosotros
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Framework e-commerce

2017-04-11 Per discussione Jacopo Cascioli
Ciao Piergiorgio,

è difficile fare delle valutazioni senza conoscere i requisiti tecnici,
senza sapere quanto tempo hai a disposizione e che tecnologie conosci,
perciò prendi quello che dico come indicazioni generiche.

Innanzitutto dovresti scegliere un'architettura per l'applicazione e poi
passare a scegliere un framework. Alcuni framework supportano più
architetture, mentre altri sono specifici.
Detto questo, oggi l'architettura che è de facto standard per il web
development di un applicazione singola è REST, perchè ti permette di fare
le cose in meno tempo e di scrivere un'unico backend per sito e app.

Questo vuol dire che dal frontend avrai bisogno di usare Angular, Ember o
framework javascript simili. Se non hai familiarità con nessuno, impararne
uno non è difficile ma sicuramente ti rallenterà.

In questo va inserito anche il discorso dei microservizi, che rende le cose
facilmente scalabili e manutenibili.

Personalmente, farei tre microservizi: autenticazione (OAuth2 + JWT), dati
(REST API) e wrapper (REST API), rispettivamente con django-oauth-toolkit,
falcon e ancora falcon. La documentazione in materia è enorme, ma la trovi
liberamente su internet.
Il modo più veloce sarebbe di usare django-oauth-toolkit + django-rest, ma
perdendo in scalabilità e modularità. In termini di performance django-rest
è più lento di falcon, ma c'è una chiamata di rete in meno, quindi non
saprei dire chi la spunterebbe.

Jacopo





Il giorno 11 aprile 2017 18:36, Piergiorgio Pancino <
piergiorgio.panc...@gmail.com> ha scritto:

> Ciao a tutti,
> volevo avere qualche indicazione su un possibile framework per realizzare
> un sito di e-commerce.
> Che opzioni ci sono?Quali utilizzate? Quali consigliate?
> Indifferente che sia Django, Flask o altro.
> Grazie
> Piergiorgio
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Ragazzi, figo proprio questo pycon8!

2017-04-10 Per discussione Jacopo Cascioli
Il Pycon 8 è una figata pazzesca!

Posso fare solo gli applausi agli organizzatori che hanno pensato a tutto e
soprattutto a mettere cibo tre volte al giorno

Jacopo

Il giorno 10 aprile 2017 08:43, Paolo Melchiorre  ha
scritto:

> On Mon, Apr 10, 2017, 07:26 Michele Gatti  wrote:
>
>> 2017-04-09 12:28 GMT+02:00 Valerio Maggio :
>>
>> On Sun, 9 Apr 2017 at 12:26, Ernesto Arbitrio 
>> wrote:
>>
>> Roby qui si è tutti tristi. É già finito :(
>>
>> +1 
>>
>> On Apr 9, 2017 11:05, "Roberto Polli"  wrote:
>>
>> Ciao belli,
>> ancora deve finire ma già ci manca... pycon8!
>> Grazie a tutti quelli che ci sono :D
>>
>> Molto molto interessante e sempre con gente interessante
>>
>
> Buongiorno a tutti,
> Mi unisco al coro di apprezzamenti per il pycon di quest'anno é sempre
> bello incontrare persone così appassionate in quello che fanno e che siano
> disposte a condividere liberamente la loro esperienza con la comunità.
>
> Per la prima a volta ho cercato di contribuire anche io e per chi volesse
> vedere le slide del mio talk "Ricerca Full-Text in Django con PostgreSql"
> le trovate qui
> https://speakerdeck.com/pauloxnet/full-text-search-in-
> django-with-postgresql
>
> Alla prossima,
> Paolo
>
> P.S. per chi invece vuole avere un l'elenco di momenti interessanti li ho
> raggruppati per i 3 giorni su Twitter
>
> https://twitter.com/i/moments/850493111931478016
> https://twitter.com/i/moments/850861187785003009
> https://twitter.com/i/moments/851089311089000448
>
>>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Scegliere un linguaggio: un'ottimizzazione prematura?

2017-04-10 Per discussione Jacopo Cascioli
Ciao,
mi aggiungo anche io.

In generale concordo con l'articolo. I primi punti dovrebbero essere
abbastanza ovvi per chiunque si occupi di management, forse sono oscuri
solo ai programmatori. Suppongo che un manager di alto livello (CTO) sappia
quali siano i costi maggiori nella società in cui lavora e possa sapere se
il problema è il costo delle macchine o quello del personale, in ogni caso.

Il tempo mediano per risolvere un problema e gli studi sulla produttività
mi mancavano. Naturalmente lo so che Python è produttivo, ma vederlo
quantificato da uno studio è diverso!

Nel web development abbiamo un problema in più: non conosciamo a priori il
modo in cui gli utenti interagiscono con la piattaforma/applicazione. Un
esempio banale si può fare con le piattaforme che hanno un sistema di
messaggi. Io non so quanto verranno usati i messaggi, quindi non
necessariamente avrò bisogno di ottimizzare quella parte.
Questo è un esempio semplice: nella realtà le interazioni che rappresentano
un problema in termini di performance sono più complesse e perciò più
difficili da prevedere.

L'esperienza può aiutare e magari dirti che determinate cose potrebbero
essere un problema dal punto di vista della performance, ma non ci sarà mai
la sicurezza (vedi esempio)

Comunque l'articolo è davvero interessante, soprattutto per gli studi che
mette, visto che in parte anche io mi preoccupo del time-to-market e
dell'efficienza nello sviluppo.

Jacopo


Il giorno 10 aprile 2017 16:16, Carlos Catucci 
ha scritto:

> 2017-04-10 14:28 GMT+02:00 Davide Olianas :
> > Dell'articolo io più che altro contesto il "continua a buttare hardware
> al
> > problema", indipendentemente dalla scelta del linguaggio.
>
> Si in effetti marca troppo su quell'aspetto. Ok che oggi il ferro
> costa poco, le risorse si trovano a buon mercato e sono "facilmente"
> (beh non e' corretta al 100% questa affermazione) upgradabili, ma non
> si puo' imputare tutto all'HW. Magari voleva solo far notare che non
> serve di lavorare per forza a basso livello, e non ha saputo spiegarsi
> bene o comunque fornire altri esempi aggiuntivi.
>
> Resto ccomunque curioso di sapere da Roberto i perche' del suo dissentire.
>
> Carlos
> --
> EZLN ... Para Todos Todo ... Nada para nosotros
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python