Profilo di RicPol

Nome RicPol
Indirizzo email ric.pol@libero.it
AvatarAvatar utenti
Messaggi66
Firma forum
https://pythoninwindows.blogspot.com/p/blog-page.html
Le mie guide: Come installare e usare Python su Windows - Progetti Python multilingua
  • Re: memorizzazione immagini
    Forum >> Principianti
    OH ECCO!!! grazie, avevo cominciato a fare degli esperimenti ma non sapevo bene cosa escapare di preciso... buono a sapersi...




    https://pythoninwindows.blogspot.com/p/blog-page.html
    Le mie guide: Come installare e usare Python su Windows - Progetti Python multilingua
  • Re: memorizzazione immagini
    Forum >> Principianti
    Sai, il problema non è essere principianti (e ci mancherebbe). Il problema è essere principianti e voler fare cose da non-principianti. Il principiante impara che cosa è una lista python, per dire, e dice "ok, sono pronto: adesso faccio un'intelligenza artificiale che trasforma frasi italiane in azioni disegnate" (non scherzo, c'è davvero un thread del genere qui).


    Occorre andare per gradi, con calma e molta pazienza. E' ovvio che ti vengono in mente decine di applicazioni pratiche da fare "subito", ma non c'è niente da fare: dopo aver imparato la lista, impara il dizionario (per dire). In particolare, ogni cosa che riguarda una interfaccia grafica richiede nozioni di programmazione a oggetti. Sì, è vero che puoi abborracciare una finestra in tkinter così alla buona, un po' copiando in giro. Ma al primo ostacolo "da mondo reale" sei già in acque profonde. Naturalmente non è che uno debba leggersi tutto il GOF prima di affrontare la prima interfaccia grafica della sua vita, eh. Ma almeno avere un po' di dimestichezza con le variabili, le funzioni, le classi, i metodi.
    Tra l'altro, la spiegazione che ti ho dato è già molto semplificata e tagliata sul tuo caso specifico. In generale, il problema dei rapporti tra oggetti è una questione di design pattern complessa. Ma non è il forum la sede per imparare queste cose. Hai già visto quante parole ho dovuto metterci per spiegarti questa piccola questione.

    Purtroppo la tragica verità è che imparare a programmare è frustrante, non è divertente. O per lo meno, bisogna imparare a divertirsi con poco, per un bel po' di tempo. E' come un gioco di ruolo alle prime avventure: tu *sai* che è possibile castare magie del nono livello e andare a caccia di draghi, ma nel frattempo devi accontentarti di dare la caccia ai goblin e castare magic missile.





    > mi è venuto il dubbio se nel caso il modulo PIL abbia già qualche funzionalità nativà per tale scopo....
    Beh, certo che sì. Una volta che hai prodotto un oggetto PIL.Image caricandoci dentro un file immagine, puoi usare PIL.Image.filename per ri-ottenere il nome del file che ci hai caricato dentro: https://pillow.readthedocs.io/en/5.3.x/reference/Image.html#PIL.Image.filename (beh, certo: ovviamente quello *non* è l'oggetto-file, è solo la stringa-path del file... ma da quello hai comunque le informazioni necessarie per ri-aprire l'oggetto-file, se vuoi).



    --- Ultima modifica di RicPol in data 2018-10-13 09:42:38 ---
    https://pythoninwindows.blogspot.com/p/blog-page.html
    Le mie guide: Come installare e usare Python su Windows - Progetti Python multilingua
  • Re: memorizzazione immagini
    Forum >> Principianti
    Guarda, abbi pazienza ma è che proprio stai facendo un'insalata di concetti diversi. Confondi le cose, non sei preciso. Intanto liberati per prima cosa di quei "print". Non usare più "print", non pensare più a "print", lascia perdere "print". Questo "print" è una delle prime cose che i principianti imparano (o credono di imparare) ed è anche la singola cosa più dannosa che rovina la comprensione di un principiante. Non puoi confondere un riferimento a un oggetto con la stringa che l'oggetto emette in risposta a un __repr__() (e quindi a un print). Quella stringa non è un riferimento all'oggetto, è solo... decorazione, niente.


    Come seconda cosa, lascia perdere anche tkinter. Finché non hai chiaro che cos'è una variabile, che cos'è un oggetto, come si usano gli oggetti... non so, stai andando a tentoni invece di procedere per gradi. Per esempio, quando scrivi

    > img = [PhotoImage(file="a.gif"), PhotoImage(file="b.gif")]
    > (...)
    > come si nota in questo codice ho messo i files in una lista

    Ma no!, come si nota in questo codice hai messo in una lista *gli oggetti PhotoImage* che contengono i file, non i file. Siccome qui stiamo parlando di come risalire dal nome di un file agli oggetti e viceversa, confondere le due cose è parecchio grave, capisci. Eccetera eccetera.





    Ora ti spiego il problema se vuoi, ma il fatto è che temo che ti mancano le basi per comprendere quello che ti spiego. Quindi probabilmente crederai di aver capito, e continuerai ad andare a tentoni. Davvero, la soluzione è prendersi un buon libro e seguirlo daccapo passo-passo.


    In ogni caso, il problema è questo. Tu hai un oggetto-Risorsa, e poi un oggetto-Manager che "acquisisce" la Risorsa, diciamo così. In pratica, ciascuna Risorsa sta "dentro" il suo Manager. Il problema è:
    1) ho in mano un riferimento al Manager, voglio ricavare un riferimento alla Risorsa che contiene;
    2) viceversa, ho in mano una Risorsa, voglio sapere il Manager che la contiene.

    La prima parte del problema in genere è più semplice: si suppone che il Manager "sa" quale Risorsa sta gestendo, e quindi probabilmente ha anche un metodo già pronto per sputare fuori un riferimento alla risorsa. Se stai usano una classe-Manager scritta da altri (per esempio, all'interno di un framework come le tk) allora ti basta leggere la documentazione per trovare quel metodo (per esempio, abbiamo visto che esiste PhotoImage.cget). Se invece la classe te la stai facendo tu, allora ti conviene scrivertelo, un metodo del genere. Qualcosa come:


    class Manager:
        def __init__(self, risorsa):
            self.risorsa = risorsa
    
        def get_risorsa(self):
            return self.risorsa
    
    # uso:
    risorsa = 'io sono una Risorsa' # un qualunque oggetto-Risorsa
    manager = Manager(risorsa)      # un oggetto-Manager che "contiene" la Risorsa
    r = manager.get_risorsa() # restituisce un riferimento alla Risorsa usata
    r is risorsa # è True: il riferimento ottenuto è davvero quello alla Risorsa usata
    
    La seconda parte (risalire dalla Risorsa al Manager) è ovviamente più difficile. Se il Manager "sa" quale Risorsa contiene, viceversa la Risorsa esiste da prima che il suo Manager venga creato, e quindi non può "sapere" in quale Manager finirà. Ora, naturalmente se tu hai solo un Manager e una Risorsa, la soluzione è banale: ti basta mantenere in vita le variabili che si riferiscono a questi due oggetti (nell'esempio sopra "risorsa" e "manager"), e poi tu lo sai già che "quel" Manager contiene "quella" Risorsa.
    Ma se le cose diventano più "dinamiche", allora si complicano. In questi casi la soluzione è mantenere una struttura-dati parallela, una specie di registro dove annoti man mano quali Risorse sono contenute dentro quali Manager. Che cosa è questo "registro"? Mah, quello che vuoi, dipende dalle tue esigenze. Nei casi più semplici, un dizionario è la prima cosa che viene in mente, e in effetti può andar bene.


    Facciamo un esempio. Abbiamo una serie di Risorse, di cui non conosciamo neanche il numero esatto, perché le prendiamo da una sorgente esterna al nostro controllo (le carichiamo da un file preparato dall'utente, o da un database, va a sapere). Supponiamo, per capirci, che le nostre Risorse siano le righe di testo di un file esterno (ogni riga è una Risorsa). Quindi apriamo il file e carichiamo ogni riga in un oggetto-Manager (usiamo la classe Manager che ho scritto sopra):
    with open('file_delle_risorse', 'r') as f:
        for line in f:
            manager = Manager(line)
    
    Con un codice del genere abbiamo ovviamente due problemi: il primo è che non stiamo conservando *nessun* riferimento né ai Manager né alle Risorse. A ogni ciclo del "for", la variabile "line" si riferisce alla Risorsa, e "manager" si riferisce al Manager: ma al ciclo successivo, "line" e "manager" si riferiscono a una nuova Risorsa e a un nuovo Manager, e i precedenti diventano irraggiungibili e vengono distrutti. Quindi in pratica stiamo distruggendo il lavoro man mano che lo facciamo. Alla fine del ciclo, resteranno in vita solo l'ultima Risorsa e l'ultimo Manager creati. Del resto, non è che possiamo usare una variabile per ciascun Manager, come prima:
    manager1 = Manager(line1)
    manager2 = Manager(line2)
    ...
    
    perché semplicemente non sappiamo quante sono le linee del file, quindi quante sono le Risorse, quindi quanti sono i Manager da creare. Il secondo problema è quello che dicevamo: non sappiamo tener traccia dei collegamenti tra Manager e Risorse, e in particolare risalire da una Risorsa a un Manager (l'opposto è più facile, come abbiamo visto).
    Ed ecco che una struttura-dati separata (per esempio un dizionario) può risolvere entrambi i nostri problemi:
    registro = {}
    with open('file_delle_risorse', 'r') as f:
        for line in f:
            manager = Manager(line)
            registro\[line\] = manager    # scusa il \[ 
    
    In questo modo dentro il registro conserviamo i riferimenti sia alle Risorse (che sono le chiavi del dizionario) sia ai Manager (che sono i valori). Inoltre, conserviamo l'associazione Risorsa->Manager che ci interessa. Se per esempio abbiamo una Risorsa che si chiama "pippo", per risalire al Manager che la contiene basta fare:
    risorsa = 'pippo' # sappiamo che una delle risorse è "pippo"
    manager = registro\[risorsa\] # adesso "manager" è un riferimento al Manager di "pippo"
    # e viceversa...
    r = manager.get_risorsa() # ottengo dal Manager un riferimento alla Risorsa contenuta
    r is risorsa # è True
    
    Non è detto che un dizionario sia la struttura-dati migliore per contenere questo registro. Dipende dal caso specifico. Per esempio, se sei in un contesto in cui ti interessa di più *l'ordine* in cui ti arrivano le Risorse e quindi sono creati i Manager corrispondenti, allora potresti tenere una lista, o anche una doppia lista:
    registro_manager = []
    registro_risorse = []
    with open('file_delle_risorse', 'r') as f:
        for line in f:
            manager = Manager(line)
            registro_manager.append(manager)
            registro_risorse.append(line)
    
    E adesso, se la tua situazione è tale per cui ti interessa sapere qual è, poniamo, il terzo Manager e/o la terza Risorsa creata, puoi banalmente fare:
    terzo_manager = registro_manager[ 2 ]
    terza_risorsa = registro_risorse[ 2 ]
    
    E ci sono molte altre soluzioni possibili, a seconda di cosa conviene nei vari casi. E ovviamente tutte queste soluzioni hanno dei problemi e delle fragilità (che cosa succede se elimino un Manager, o se ne aggiungo uno? e se un Manager cambia Risorsa a run-time? eccetera). In generale, questo è un problema di implementare un pattern MCV: questo "registro", comunque tu lo realizzi, è in sostanza un "controller" che media tra gli oggetti presenti. In senso astratto, il controller è una classe (o una serie di classi) su cui deve essere possibile fare certe operazioni, e che devono garantire una certa robustezza. Per esempio, se volessi davvero implementare il tuo registro come una lista doppia, allora sicuramente tenere due liste "sciolte" nel codice è molto fragile: per esempio, se cancelli un Manager devi sempre ricordarti di cancellare anche la Risorsa corrispondente. Allora vorrai piuttosto "inscatolare" questa doppia lista in una classe specializzata che si curi di implementare in modo sicuro le operazioni richieste:
    class Registro:
        def __init__(self):
            self.registro_risorse = []
            self.registro_manager = []
        def aggiungi(self, manager, risorsa):
            self.registro_risorse.append(risorsa)
            self.registro_manager.append(manager)
        def elimina(self, n):
            self.registro_risorse.remove(n)
            self.registro_manager.remove(n)
        ... etc. etc. ...
    


    E poco per volta questo diventa un serio esercizio di programmazione a oggetti.


    PS: scusa l'uso di "\[" e "\]" per dire "[" e "]"... il fatto è che per qualche ragione questo autentico cess* di motore di rendering del forum si intestardisce a creare automaticamente voci inutili dell'inutile wiki.... immagino che nessuno riparerà più questo baco, ma è veramente una seccatura.






    --- Ultima modifica di RicPol in data 2018-10-12 15:44:22 ---
    https://pythoninwindows.blogspot.com/p/blog-page.html
    Le mie guide: Come installare e usare Python su Windows - Progetti Python multilingua
  • Re: Aggiornare il contenuto di un wxPanel
    Forum >> Programmazione Python >> GUI
    Mah guarda, in generale il problema che poni è interessante, solo che nel tuo caso particolare diventa tutto molto banale.


    In generale il problema è: come generare dinamicamente una parte della gui, e quali strategie usare per aggiornarla altrettanto dinamicamente. E qui in effetti si pone tutto il problema di MVC, bla bla bla. E, a seconda dei casi, può essere più conveniente una cosa, l'altra, l'altra ancora. Bla bla bla.


    Ma nel tuo caso specifico, che senso ha quello che stai cercando di fare? Per cominciare, wxPython ha *già* dei widget che visualizzano un calendario, e che fanno già tutto il lavoro per te. Se ben ricordo, ne aveva addirittura due. Usa quelli e vivi felice.


    In secondo luogo, se proprio vuoi farti un calendario a mano (magari per esercizio, non so), allora nel tuo caso ha poco senso complicarsi la vita. Semplicemente disegna 31 pulsanti e poi, a ogni cambio di mese, nascondi quelli che non ti servono. Così non hai bisogno di rifare il disegno, e tutto resta semplice. Come bonus di scaltrezza, puoi chiedere direttamente a python quanti giorni ha il mese che ti serve: così risolvi anche il problema degli anni bisestili, ed eviti di mettere sempre 28 giorni a Febbraio.


    Ecco una bozza di idea buttata giù in cinque minuti:


    import datetime
    import wx
    
    class CalendarPanel(wx.Panel):
        def __init__(self, parent, initial_date=None):
            wx.Panel.__init__(self, parent)
            if initial_date is None:
                initial_date = datetime.date.today()
            self.current_year = initial_date.year
            self.current_month = initial_date.month
            move_back = wx.Button(self, -1, '<')
            move_back.Bind(wx.EVT_BUTTON, self.on_move_back)
            move_forw = wx.Button(self, -1, '>')
            move_forw.Bind(wx.EVT_BUTTON, self.on_move_forw)
            self.display_date = wx.TextCtrl(self, style=wx.TE_READONLY)
            self.day_buttons = []
            for day in range(31):
                b = wx.Button(self, -1, str(day+1), size=(40, 40))
                b.Bind(wx.EVT_BUTTON, self.on_day_clic)
                self.day_buttons.append(b)
            self._refresh_display()
            self._refresh_day_buttons()
            siz1 = wx.BoxSizer(wx.HORIZONTAL)
            for widget in (move_back, self.display_date, move_forw):
                siz1.Add(widget, 0, wx.ALL, 5)
            siz2 = wx.GridSizer(7, 0, 0)
            for button in self.day_buttons:
                siz2.Add(button)
            s = wx.BoxSizer(wx.VERTICAL)
            s.Add(siz1)
            s.Add(siz2, 0, wx.ALL, 5)
            self.SetSizer(s)
    
        def _refresh_display(self):
            'Setta mese e anno attuali nella casella di testo.'
            display = '%i / %i' % (self.current_month, self.current_year)
            self.display_date.SetValue(display)
    
        def _refresh_day_buttons(self):
            "Reimposta i pulsanti per il mese corrente, nasconde i giorni in piu'."
            for button in self.day_buttons:
                button_day = int(button.GetLabel())
                try:
                    datetime.date(self.current_year, self.current_month, button_day)
                    button.Show()
                except ValueError:
                    # metodo brutale: se datetime.date non puo' essere formata, vuol dire
                    # che il mese attuale non ha quel giorno (es. 30 febbraio): 
                    # quindi semplicemente nascondo il pulsante.
                    # Nota che questo ha pure il vantaggio di tener conto dei bisestili!
                    button.Hide()
    
        def on_move_back(self, evt):
            self.current_month -= 1
            if self.current_month < 1:
                self.current_year -= 1
                self.current_month = 12
            self._refresh_display()
            self._refresh_day_buttons()
    
        def on_move_forw(self, evt):
            self.current_month += 1
            if self.current_month > 12:
                self.current_year += 1
                self.current_month = 1
            self._refresh_display()
            self._refresh_day_buttons()
    
        def on_day_clic(self, evt):
            button = evt.GetEventObject()
            button_day = int(button.GetLabel())
            date = datetime.date(self.current_year, self.current_month, button_day)
            print('hai cliccato', date)
    
    
    class MainFrame(wx.Frame):
        def __init__(self, *a, **k):
            wx.Frame.__init__(self, *a, **k)
            p = CalendarPanel(self)
    
    app = wx.App()
    MainFrame(None).Show()
    app.MainLoop()
    Naturalmente un vero calendario dovrebbe tenere i giorni incolonnati, e per questo c'è bisogno di un po' di lavoro in più. Dovresti farti una griglia di cinque settimane e poi, a ogni refresh del mese, non solo nascondi i giorni superflui, ma cambi proprio le label dei pulsanti. O meglio ancora, cambi le label dei pulsanti e non nascondi i pulsanti dei giorni superflui, ma li mostri come i giorni adiacenti del mese precedente e successivo. Come fanno i veri calendari, insomma.


    Ma allora, come dicevo... perché non usare un vero calendario, visto che wxPython ce l'ha?









    https://pythoninwindows.blogspot.com/p/blog-page.html
    Le mie guide: Come installare e usare Python su Windows - Progetti Python multilingua
  • Re: memorizzazione immagini
    Forum >> Principianti
    Mah sai, dovresti leggerti la documentazione di PhotoImage per capire se davvero quella stringa è affidabile, ma onestamente non credo che sia nemmeno documentata una cosa del genere. Si dà per scontato che *non* è affidabile, e nel mondo reale nessuno cercherebbe di fare quello che vorresti fare tu. Semplicemente, non è la strada giusta.


    Ora, quando fai un print() di un oggetto, invochi il metodo __repr__ di quell'oggetto. Che cosa restituisce __repr__ dipende dall'api dell'oggetto, ma l'idea di base è semplicemente restituire una stringa "amichevole" a scopo di debugging (vedi https://docs.python.org/3/reference/datamodel.html?highlight=__repr__#object.__repr__). Non sta scritto da nessuna parte che questa stringa deve identificare in modo univoco l'oggetto. Per queste cose c'è "id()", o magari "hash()". Poi certo, molto spesso davvero la stringa finisce per essere unica: guarda anche semplicemente questo:


    >>> class Bogus: pass
    ...
    >>> a = Bogus()
    >>> b = Bogus()
    >>> c = Bogus()
    >>> a, b, c
    (<__main__.Bogus object at 0x00000010CB1BAF28>, 
    <__main__.Bogus object at 0x00000010CB1C1470>, 
    <__main__.Bogus object at 0x00000010CB1C14A8>)
    Come vedi la stringa include l'id dell'oggetto, quindi è univoca. Ma anche in questo caso, come fai a risalire dalla stringa all'oggetto? Intendiamoci, non c'è modo di risalire all'oggetto neppure partendo dal suo id o dal suo hash. Semplicemente, non sono fatti per quello. Il modo giusto per risalire a un oggetto, in Python, è conservarne un riferimento in una variabile.


    Nel tuo caso specifico, tu vuoi fare una cosa ancora (leggeremente) più complicata, in verità. Tu vuoi risalire a una *proprietà* dell'oggetto (il nome del file fisico associato all'oggetto) a partire dalla sua rappresentazione-stringa (cioè, la stringa che ottieni con __repr__, come detto). Ovviamente non c'è modo di farlo, perché non c'è modo in primo luogo di risalire all'oggetto, quindi a maggior ragione neppure a una sua proprietà.


    Ora, è vero il fatto che, almeno in apparenza, Tkinter mantiene un contatore delle immagini create e quindi restituisce "image1", "image2" etc., quando chiami __repr__ sugli oggetti-immagine che hai aperto. Di nuovo, ti invito a cercare nella documentazione se questa policy è affidabile, e fino a che punto. Per esempio, quando distruggi un oggetto-immagine tkinter potrebbe riciclare il suo numero? Ma anche se dovessi scoprire che questo contatore è "robusto abbastanza", non puoi farci proprio niente comunque.


    Cioè, come hai già notato anche tu, potresti tenere traccia dell'*ordine* in cui apri i file, per cui "file1" finisce per essere "image1", e così via. Ma anche lasciando perdere la fragilità della cosa, capisci che stai solo spostando il problema un po' più in là. Adesso il problema è: COME tieni conto dell'ordine in cui apri i file? Per esempio mettendoli in una lista:

    file_da_aprire = ['file1.jpg', 'file2.jpg', ...]
    for f in file_da aprire:
        ...
    
    Ma appunto, a questo punto HAI GIA' i nomi dei file che ti servono, opportunamente conservati nella tua lista. Perché hai bisogno di recuperarli facendo un giro strano?





    > in questo caso il problema non esiste ma come hai ben ipotizzato lo scenario dove si presenta invece si.
    Non credo. Magari sbaglio, ma un pizzico di esperienza mi insegna che stai cercando di risolvere un problema semplice senza conoscere il pattern giusto per risolvere questo tipo di problemi. Prova a spiegare che cosa vuoi fare davvero.








    Post-scriptum, solo per il gusto di aggiungere una nota un po' difficile e anche un po' sbruffona. Prima ho scritto che non c'è modo di risalire all'oggetto partendo dal suo id. Ma non è completamente vero. Almeno in C-Python, l'id di un oggetto è in effetti l'indirizzo di memoria in cui risiede l'oggetto:


    >>> class Bogus: pass
    ...
    >>> a = Bogus()
    >>> id(a)
    72127091992
    
    Questo vuol dire che in effetti è possibile risalire dall'id all'oggetto... *non* usando Python... ma usando C (da dentro Python)!


    >>> import ctypes
    >>> b = ctypes.cast(id(a), ctypes.py_object).value
    >>> id(b)
    72127091992
    >>> b is a
    True
    
    Buffo, vero? Ma ovviamente lascia perdere questa cosa, non ha senso per quello che vuoi fare tu. Era solo per far vedere qualcosa di inconsueto.
    https://pythoninwindows.blogspot.com/p/blog-page.html
    Le mie guide: Come installare e usare Python su Windows - Progetti Python multilingua
  • Re: memorizzazione immagini
    Forum >> Principianti
    Che cos'è "PhotoImage"? In generale per cortesia evitate di usare nomi, moduli, librerie, componenti vari senza dire che cosa sono, da che cosa li avete importati. Non è che possiamo tirare a indovinare.


    E in ogni caso... da quello che scrivi sembra che "pyimage1" sia semplicemente la rappresentazione dell'oggetto che la tua libreria crea quando apri un'immagine. File immagine -> caricato in un oggetto python -> chiamo __repr__ su quell'oggetto (con print, per esempio) e ottengo "pyimage1". Quindi "pyimage1" non è niente, è solo una stringa di convenienza che python sputa fuori in risposta a una chiamata "oggetto.__repr__()" (una chiamata che per esempio avviene quando fai un print). L'oggetto non è "pyimage1", l'oggetto è quello che raggiungi con la variabile "image" (nel tuo codice). E quindi qual è il problema? Hai già scoperto come ottenere il nome del file a partire dall'oggetto, attraverso "image.cget" (che non so che cosa sia ovviamente, ma è occhei suppongo).


    (senza contare, naturalmente, che nel tuo scenario tu *sai già* qual è il nome del file, perché è quello che hai usato per aprire l'immagine in primo luogo... E su due piedi non riesco a immaginare facilmente uno scenario in cui tu non possa semplicemente conservare in una variabile il nome dell'immagine che stai aprendo e risolvere il problema in questro modo, invece di dover recuperare il nome dopo... Però magari invece uno scenario del genere esiste, e tu ne hai bisogno...)








    https://pythoninwindows.blogspot.com/p/blog-page.html
    Le mie guide: Come installare e usare Python su Windows - Progetti Python multilingua
  • Re: Problema variabile non definita
    Forum >> Principianti
    Diciamo che ci sono ancora... alcuni passi da fare prima di essere "sufficientemente chiaro", ecco. Prima di tutto, riposta il codice usando la formattazione giusta (c'è un apposito pulsante "code" nella barra sopra il box dove scrivi i messaggi, hai visto? Proprio accanto alla serie di quadratini colorati). In questo modo possiamo vedere i rientri e capire forse che cosa c'è che non va.


    Poi dovresti fare un sforzo di scrivere chiaramente in Italiano: che cosa vuol dire "la funzione Proba(n,tau) sfrutta una funzione che contiene FFz"? Sfrutta in che senso? Ha una concessione mineraria sulla funzione? La sta ricattando? E a che cosa si riferisce quel "la definisce"? Chi è "la", tra le due funzioni?


    Poi c'è il fatto che dai alle tue variabili dei nomi impossibili da capire, e che in generale dovresti veramente seguire la PEP8 quando scrivi codice python.


    Poi c'è il fatto che non posti tutto lo stacktrace dell'errore che ricevi. Ok, hai un NameError, ma *dove*? Anche perché, da quello che dici, potrebbe essere nella funzione che hai postato, ma anche nella funzione che non hai postato (se ho capito quello che hai scritto, cosa di cui però dubito).


    Una volta sistemate queste cose, possiamo cominciare a ragionarci sopra, suppongo.

    https://pythoninwindows.blogspot.com/p/blog-page.html
    Le mie guide: Come installare e usare Python su Windows - Progetti Python multilingua
  • Re: Richiamare shell interattiva scrivendo "python" anziché "python3.7"
    Forum >> Programmazione Python >> IDE ed Editor
    Uhm, più precisamente: diciamo che se sei "dentro" un venv, allora "python" è il python del venv. Viceversa, specialmente su linux dove di solito hai più di un python installato, è ragionevole usare i qualificatori di versione. Ovviamente puoi registrarti un alias nella shell se proprio ci tieni, ma... non so quanto può aver senso.
    https://pythoninwindows.blogspot.com/p/blog-page.html
    Le mie guide: Come installare e usare Python su Windows - Progetti Python multilingua
  • Re: Problema installazione fbprophet
    Forum >> Principianti
    E' un pacchetto con estensioni binarie non pre-compilate ("msvc is not supported"). E' fatto per essere compilato in ambiente linux. Se trovi una versione per windows sul sito dello sviluppatore e/o nella collezione di chris gohlke e/o in qualche altra distribuzione non ufficiale, bene. Se no, dovresti provare a compilartelo da solo. Se no, usa linux...
    https://pythoninwindows.blogspot.com/p/blog-page.html
    Le mie guide: Come installare e usare Python su Windows - Progetti Python multilingua
  • Re: Calcolo regressione S&P
    Forum >> Programmazione Python >> Calcolo scientifico
    Tendenzialmente perché spider/anaconda (immagino) utilizza un certo environment con certe impostazioni, mentre il tuo "altro python" (qualunque sia) è un'altra cosa. L'argomento è molto lungo e i casi possibili sono migliaia e non vale la pena di mettersi a rintracciare l'origine di questo specifico problema (domani ne avrai un'altro, e così via). La soluzione è avere ben chiaro in testa come funziona il modello di esecuzione di uno script python, come è fatto python, come si installa, come importa i pacchetti, che cos'è un environment, eccetera. Su windows. Ho scritto una lunga guida (link in firma) su questi argomenti, ti suggerisco di leggerla. Se invece il tuo scopo è solo quello di eseguire certi compiti in un certo contesto, non ti preoccupare e continua a usare spyder che va benissimo per quello che devi fare...
    https://pythoninwindows.blogspot.com/p/blog-page.html
    Le mie guide: Come installare e usare Python su Windows - Progetti Python multilingua