Profilo di RicPol

Nome RicPol
Indirizzo email ric.pol@libero.it
AvatarAvatar utenti
Messaggi480
Firma forum
  • Re: Selezionare righe con condizioni 😭
    Forum >> Programmazione Python >> Database
    > senza screenshot

    Uno screenshot di sei virgola due megabyte preso scattando la foto dello schermo col telefonino.


    Peraltro.




  • Re: Traduzione Documentazione ?
    Forum >> Annunci
    Mah, sì... Intanto vedo che l'OP ha già pubblicato la sua traduzione nel suo blog https://leucalipto.blogspot.com/ quindi in modo sostanzialmente proprietario, non mettendo a disposizione il sorgente (almeno a quanto mi risulta). E siccome vedo che ha già una "roadmap" in mente, a questo punto credo che non sia interessato a collaborare a un progetto strutturato di traduzione da ospitare qui. Ma ci dirà lui che cosa vorrà fare, nel caso.


    Per quanto mi riguarda, quello che posso fare è creare un "manifesto" del progetto e metterlo sulla mailing list... diciamo con le coordinate generali di quello che si intende fare. In questo modo si può partire a discutere da una cosa concreta. Diciamo che ci penso nelle prossime serate.


    Successivamente, se sono io a coordinare la cosa, potrei fare un "tutorial" (anche piuttosto dettagliato, per chi non ha proprio idea di come funzionano gli strumenti) per come si può collaborare al progetto.


    Per quanto riguarda le cose tecniche... per adesso posso dire solo che:

    1) "Zanata" e affini... sorry, non voglio essere uno snob e dire che se non si fa come dico io... ma il problema è che semplicemente Zanata non fa quello che vogliamo noi. Zanata serve quando devi tradurre un documento in 10 lingue, ed è basato su Gettext (o cose analoghe). Inoltre ha un suo concetto di versioning, ma non è lo stesso di Git. Inoltre non supporta nativamente RestructuredText. Ora, qui il problema è che noi dobbiamo
    - fare il tracking di una repo Git
    - che ha diversi branch
    - i cui documenti sono scritti in RestructuredText
    - e dobbiamo tradurre in una lingua sola.
    Per tutto questo, Zanata non è lo strumento che viene naturale usare. Non sono io che mi incaponisco a volere Git e Sphinx. Il problema è che LA DOC DI PYTHON originale usa Git e Sphinx. E questo è un fatto che non possiamo cambiare. Quindi, tutto ciò che si allontana da Git e Sphinx richiede un "layer" di lavoro in più che onestamente non me la sentirei di progettare.


    2) Penso anche io che la cosa migliore sarebbe mantenere la repository della traduzione "a casa" di python.it. Fisicamente, credo che la cosa migliore sarebbe fare il "lavoro sporco" sulla mia repository e fare un clone sul GitHub di python.it dove fare push periodici. La repo su python.it sarebbe quella "ufficiale", con pochi commit.


    3) L'output html ottenuto con Sphinx si potrebbe senz'altro pubblicare su python.it, non c'è problema. La cosa ottimale sarebbe fare qualche hook GitHub per aggiornare il risultato pubblicato ogni volta che viene fatto un push sulla repository "ufficiale", ma se non si riesce ad automatizzare la cosa, si può benissimo anche fare tutto a mano... non prevedo comunque un traffico gigantesco. Ovviamente, se pubblichiamo su python.it, allora eliminerei la mia attuale pubblicazione su ReadTheDocs.


    E questo è tutto quello mi viene in mente per il momento... ma prometto che scrivo qualcosa di più dettagliato per la mailing list.




  • Re: Avviare un programma Python da Phyton su Linux
    Forum >> Principianti
    Ma vorrei veramente vederlo, un manuale serio che fa un'affermazione del genere... capirei il corso della domenica su YT, ma... Oddio, non è che mi stupisco più di molto ormai.


    Ovviamente Python (come Java, etc) cerca di essere "crosspiattaforma", ma altrettanto ovviamente le "piattaforme" su cui si trova a lavorare sono diverse, e fanno le cose in modo diverso. E certe cose non possono essere fatte da Python, devono essere delegate al sistema operativo sottostante... le operazioni con il file system, per esempio. Una path su windows è una cosa diversa da una path su linux, e anche se il modulo pathlib cerca di offrire un minimo terreno comune, resta il fatto che certe specifiche cose su windows le puoi fare, su linux no (e viceversa). L'alternativa sarebbe limitare il set di funzionalità a un minimo inservibile per tutti.

    La documentazione di moduli come os, sys, pathlib... è costellata di notazioni "availability: windows/linux" eccetera. Non può essere altrimenti. Molte cose poi non sono neanche molto documentate: per esempio, in windows se fai banalmente una cosa come
    >>> import os
    >>> f = open('miofile')
    >>> os.remove('miofile')
    


    ti becchi un errore. In Linux no. Perché? Perché in windows aprire un file (anche in sola lettura) crea un lock. E' semplicemente che il sistema operativo funziona in modo diverso. Che cosa vogliamo fare, togliere la possibilità di aprire un file con Python, in modo da rimanere "crosspiattaforma"?




    La verità è che non puoi sperare che Python ti esenti dalla faticaccia di studiare e capire, almeno un po', anche come funziona il suo ambiente di esecuzione (file system, sistema operativo, etc.). Questa cosa si chiama Law of the Leaking Abstractions. Nella sua formulazione originale, Joel Spolsky fa un ottimo lavoro per spiegare che cosa significa davvero "astrazione" in informatica. Una astrazione è "un modo semplice di usare una cosa complicata sottostante, a patto di aver capito come funziona la cosa complicata sottostante". Di solito uno pensa invece che "astrazione" significa "un modo semplice di usare una cosa complicata senza bisogno di capirla". Il motivo per cui tutti ormai oggi fanno questo tipo di confusione è complesso e dipende da molte cose che sono successe nel passato. Ne parlo (tra molte altre cose) anche qui https://pythoninwindows.blogspot.com/2020/03/come-imparare-python-senza-studiare.html





    Allo stesso modo, non basta aver visto in giro qualcuno che usava "os.startfile" per aprire un file, per usare "os.startfile" assumendo che funzioni e basta. Bisogna anche aprire la documentazione di "os.startfile", leggere la documentazione di "os.startfile", capire che cosa fa davvero "os.startfile", e solo a quel punto, eventualmente, usare "os.startfile".
    Ora, "os.startfile" è solo un wrapper che invoca la funzione "ShellExecuteEx" del sistema operativo... ShellExecuteEx è la funzione che, dietro le quinte, windows utilizza ogni volta che si fa doppio clic sull'icona di un file, per esempio. Ha una euristica tutta sua particolare, che decide che cosa bisogna fare a seconda del file. Se è un file eseguibile (un programma) allora lo esegue, altrimenti cerca di individuare il programma più adatto per "aprire" il file, in base alle estensioni e alle associazioni. E' il motivo per cui se fai doppio clic su un file ".doc", ti si apre Word.


    Quindi, in python puoi fare "os.startfile('miofile.doc')" e avviare Word, o qualsiasi altro programma Windows abbia associato ai file ".doc" su quella macchina. Naturalmente è una bella comodità, ed è carino che Python metta a disposizione "os.startfile"... su Windows! Perché ShellExecuteEx su Linux ovviamente non esiste, e non esiste nessuna funzione del sistema operativo che faccia una cosa del genere.


    Tutto questo... è documentato.

  • Re: Avviare un programma Python da Phyton su Linux
    Forum >> Principianti
    Si beh, questa è la solita confusione tra "programma" e "modulo". Un programma non è un modulo, un modulo non è un programma.


    Un "programma" è un software che si intende completo e concluso, con una sua funzionalità, che si desidera avviare (e magari mantenere in esecuzione) in un thead di esecuzione suo specifico. Un "programma" può ovviamente dialogare con altri "programmi" in esecuzione parallela nella stessa sessione del sistema operativo, ci mancherebbe. Un "programma" può essere avviato da altri "programmi", ci mancherebbe. Tuttavia, se è un "programma", si suppone che abbia una ragion d'essere sua propria, una sua propria autonomia, un motivo per cui il sistema operativo dovrebbe eseguirlo.


    Un "modulo" (o molti moduli che lavorano insieme: una "libreria", come si dice) è un pezzo di software fatto per essere utilizzato all'interno di altro software (di altri moduli, di altre librerie o, infine, di altri "programmi"), nello stesso thread di esecuzione (o comunque dello stesso processo, in caso di software multi-threading). Un modulo talvolta può essere eseguito autonomamente come se fosse un programma, ci mancherebbe. Ma la sua vocazione è quella di essere... sorpresa... importato da altri moduli.





    Quindi, se quello che hai in mano è un PROGRAMMA (che sia scritto in python, in lua, in java, in c++, in brainfuck non importa) e vuoi eseguirlo dall'interno del tuo software, tipicamente quello che vuoi fare è avviarlo con subprocess (e NON certamente con accrocchi terrificanti in stile tutorial html.it, come os.startfile) ed eventualmente poi comunicare con il suo processo, con le primitive che subprocess mette a disposizione (e se il processo ha qualcosa di interessante da comunicare, beninteso).


    Se invece quello che hai in mano è un MODULO, e vuoi utilizzarne le funzionalità all'interno del tuo codice, allora devi importarlo, e leggerti la sua documentazione e usare la sua api nel tuo codice.


    In sintesi, questo è. "Elegante", "meno elegante", e "la pelle" c'entrano pochino.




  • Re: installazione modulo larlib
    Forum >> Principianti
    eh... sono progetti abbandonati... forse la cosa migliore è prendere spunto da quel che c'è e riscrivere daccapo... o come dicevo, cercare altre librerie che facciano lo stesso mestiere.


    Poi, se vuoi solo provare, nulla ti vieta di installarti python 2 provvisoriamente... ma certo se hai in mente di usare questa cosa in modo stabile... allora ti conviene forkare.

  • Re: installazione modulo larlib
    Forum >> Principianti
    >
    da dove si vede?

    eh, solo dal codice sorgente, visto che l'autore non si è degnato di specificare dei metatags più accurati

    > quale è il modo migliore per ultilizzarlo


    chiedere all'autore di fare un porting per python 3, oppure farlo tu stesso. Oppure cercare qualche altra libreria che fa lo stesso lavoro...

  • Re: Traduzione Documentazione ?
    Forum >> Annunci
    > non hai citato che bisogna anche aggiungere la direttiva

    era due righe sotto... ;-) e comunque la documentazione di interpshinx è sempre a portata di mano, eh? https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html

    > Ora mi devo occupare dei pdf che anche qui mi da problemi.


    Nella traduzione del tutorial non mi sono preoccupato del problema, perché lascio che ci pensi ReadTheDocs a queste cose... che è una delle (molte) ragioni per cui consiglio di usare strumenti e flussi di lavoro già consolidati e testati, piuttosto di farsi le cose daccapo...
    Tuttavia nel processo di lavoro dei miei libri, effettivamente, devo generare il pdf a mano. I miei libri sono scritti con sphinx (guarda caso), e il pdf viene generato da sphinx (attraverso il latex builder). Ora, in generale "make latexpdf" funziona e basta, se hai una catena di produzione latex nella path di sistema (pdflatex, per esempio). Ovviamente poi latex è sempre una bestia molto complicata da capire e ha un sacco di problemi (compreso un supporto unicode... particolare, diciamo). Per l'output dei miei libri faccio un sacco di piccoli accorgimenti complicati, e la catena di produzione è piuttosto complessa in realtà. Ma per le cose semplici non dovrebbe essere troppo problematico. In ogni caso, la documentazione di sphinx è sempre a portata di mano. E in ogni caso, come ho già detto, avrebbe più senso lasciar fare a uno strumento come ReadTheDocs, che fa questo di mestiere.


    > Il mio script awk non azzererebbe la portabilità del lavoro ...

    Sì, invece la azzererebbe proprio. Perché se in futuro qualcuno volesse partire dalla tua traduzione e aggiornarla, dovrebbe avere anche il tuo script awk non-standard... devi pensare agli scenari futuri, quando pensi alla portabilità, non al presente. Comunque, ripeto, il punto più che altro è che con awk tu dovresti comunque replicare in qualche modo (sarei tra l'altro interessato a capire come...) l'algoritmo usato da intersphinx... ma allora tanto vale usare intersphinx.... ma credo che questo nel frattempo tu l'abbia già acquisito.


    > Non so se conosci awk

    Sì conosco...

    > Per "fuori dal sistema ufficiale di pacchettizzazione" intendo ...


    Allora... chiariamo.


    "Non essere root", per cominciare: questa sì che è "un'idea che la comunità linux si porta dietro da 30 anni", e del resto anche la comunità windows, e la comunità bsd, e la comunità os/2, etc etc. Tutto il resto, francamente, no.


    Usare un venv non è semplicemente "un po' meglio": è il modo corretto di lavorare con Python, da parecchi anni a questa parte, su windows come su linux. Dentro un venv puoi installare pacchetti con pip o con un altro packet manager (conda, apt... a te la scelta), a seconda di quello che devi fare. Quello che invece proprio non dovresti fare, è metterti a installare pacchetti alla selvaggia (che tu lo faccia con pip o con apt) nel python di sistema.


    Detto questo, ma CERTO che sphinx è anche su apt, ci mancherebbe!... ti pare che uno strumento stra-noto e stra-usato come sphinx possa non essere su apt? Sphinx è su apt, su yum, su conda, su homebrew... chi più ne ha più ne metta. https://www.sphinx-doc.org/en/master/usage/installation.html#debian-ubuntu

    Quindi se vuoi installare sphinx con apt, puoi farlo senza problemi.




  • Re: Traduzione Documentazione ?
    Forum >> Annunci
    Ho sospetto che per usare sphinx occorra prima studiare a fondo la documentazione di sphinx... non è quel genere di strumento che "funziona alla cieca", la prima volta che ci provi... come ti dicevo, non è un "programma" per l'utente finale, è una libreria per programmatori, e ha il suo modello concettuale da capire. Tieni conto che, probabilmente ti servirà anche l'estensione intershinx per risolvere i rimandi a oggetti che sono documentati nel resto della documentazione (inglese) di python.


    A dire il vero non ho trovato particolari difficoltà a risolvere i nomi del dominio "python" con sphinx e intersphinx, quando traducevo il tutorial. Mi è bastato aggiungere intersphinx alla macchina: https://github.com/ricpol/pytutorial-it/blob/master/tutorial/source/conf.py#L34

    > Con rst2html5 mi rende poi proprio il documento non fruibile in quanto piazza dei rettangoli di errore in mezzo al documento

    Questo sarà probabilmente un problema di encoding?

    > La cosa buffa è che ovviamente non digerisce nemmeno il documento originale di python.org

    Mi sembra abbastanza logico... se non ha un riferimento per dove trovare gli oggetti, non può inventarselo. E' anche per questo che viene comodo intersphinx.

    > Se proprio ci devo perdere del tempo mi faccio uno script awk per convertire tutti gli indirizzi.


    Ecco, questa sì che sarebbe una cattiva idea. Anche se ci riuscissi (e come, poi? dovresti in pratica replicare l'algoritmo di sphinx... ma allora usa sphinx), sarebbe una cosa che azzera completamente la portabilità del tuo lavoro. Il consiglio è sempre quello di imparare a fare le cose nel modo giusto (con il disclaimer già detto, ovviamente, che poi ciascuno fa come gli pare).


    > Sphinx però non l'ho installato con pip in quanto per me tutto quello
    che è fuori dal sistema ufficiale di pacchettizzazione è il diavolo.


    Ok, hai definitivamente delle idee... particolari, diciamo. Poi non capisco che cosa intendi con "fuori dal sistema ufficiale di pacchettizzazione"... Mah... comunque, sphinx si installa come tutti i pacchetti python: con Pip, dentro un virtual environment. Questo è il modo più "ufficiale" che c'è (e anche quello giusto, per quel che vale).




  • Re: Ma voi che editor usate ?
    Forum >> Programmazione Python >> IDE ed Editor
    visual studio code
  • Re: Ma voi che editor usate ?
    Forum >> Programmazione Python >> IDE ed Editor
    Francamente la guerra degli editor tra vim ed emacs, la trovo esaurita da più di dieci anni...


    Con tutto il (grande) rispetto per quelli che riescono ancora configurare queste bestie, ricordare gli incriccatissimi keybinding e a essere produttivi con questi strumenti oggi, ma non consiglierei più al mio peggior nemico di usare nessuno dei due. Voglio dire, siamo nel 2020, fate come fanno tutti e usate visual studio code, o sublimetext, o comunque qualche editor che non sia stato pensato negli anni '70 per l'uso su un terminale VT100 o qualcosa del genere.


    (poi ecco, non dico che un editor da terminale non sia utile... e infatti io lo uso, quando devo... ma nel 2020 per queste cose uso Micro).