OT Python3

Credo sia un esempio di come aggiungere un attributo (in questo caso un metodo, cioe’ una funzione) ad una classe a posteriori.
Cioe’ di come prendere una classe gia’ definita in precedenza ed aggiungerci il metodo.

Se il metodo cuoci fosse stato definito fin dall’inizio, sarebbe venuta fuori una cosa cosi’

class Cibo:
    def __init__(self, proteine=0, carboidrati=0, grassi=0):
        self.proteine = proteine
        self.carboidrati = carboidrati
        self.grassi = grassi
        
    def calcolaCalorie(self):
        return (self.proteine * 4 + self.carboidrati * 4 + self.grassi * 9)

    def cuoci(self):
        self.cotta = True

Ma nell’esempio questa operazione e’ successiva, quindi Beri ci mostra come definire la funzione fuori dalla classe e poi come collegarla alla classe.

Quindi prima definiamo la nostra funzione

def cuoci_cibo(self):
    self.cotta = True

e poi usiamo setattr per collegarla alla classe.
setattr vuole 3 parametri:

  1. la classe (o l’oggetto)
  2. il nome dell’attributo
  3. il valore dell’attributo
setattr(Cibo, "cuoci", cuoci_cibo) 

Cibo e’ la classe
“cuoci” e’ il nome del metodo
cuoci_cibo e’ il metodo

OK, ora cuoci e’ diventato un metodo di Cibo , quindi lo possiamo richiamare con l’oggetto pasta

pasta.cuoci()

:slight_smile:

In questo esempio, Beri ha definito la funzione usando un nome e poi il metodo usando un nome diverso:

cuoci_cibo o e cuoci

Ma … suppongo che a te interessi anche vedere se funziona usando lo stesso nome … :smile:

class Cibo:
    def __init__(self, proteine=0, carboidrati=0, grassi=0):
        self.proteine = proteine
        self.carboidrati = carboidrati
        self.grassi = grassi
        
    def calcolaCalorie(self):
        return (self.proteine * 4 + self.carboidrati * 4 + self.grassi * 9)

pasta = Cibo(proteine=12, carboidrati=72, grassi=1)

def cuoci(self):
    self.cotta = True

setattr(Cibo, "cuoci", cuoci) 

pasta.cuoci()
print(pasta.cotta)

… Pare che funzioni … :slight_smile:
Ciao !

io da poco stavo iniziando a capire qualcosina su gli attributi e adesso escono fuori anche i metodi :triumph:

non c’è la posso fare voglio piangere :sob::sob:

Hehe … tranquillo … :slight_smile:

‘attributo’ e’ generico: vale per qualunque cosa collegata a una classe.
Puo’ essere un numero o una stringa, oppure una funzione.
Se e’ una funzione, per distinguerlo dagli altri tipi di attributi, lo chiamiamo ‘metodo’.

La confusione deriva dalla terminologia usata in OOP, che ovviamente puo’ variare da linguaggio a linguaggio … :smile:

Prima di studiare queste cose in Python, potrebbe essere utile leggere qualcosa sulla programmazione ad oggetti in generale.
Tanto per cominciare a ‘farci l’orecchio’ … :wink:

Se no ti trovi ad affrontare insieme la sintassi Python piu’ la OOP … mischiate insieme …
Eh, puo’ venir fuori un bel guazzabuglio. :smile:

Forse potrebbe essere utile guardarti un po’ il testo che avevi gentilmente linkato tu:
https://www.python.it/doc/Howtothink/Howtothink-html-it/chap14.htm

E tieni conto del fatto che, come dice il testo nel link, la OOP ti permette di scrivere in modo diverso cose che potresti anche scrivere nel modo ‘tradizionale’.
In pratica e’ solo una sintassi diversa che a volte puo’ essere piu’ comoda da utilizzare.
Ma altre volte forse ci confonde piu’ di quanto ci aiuti.

Alla fine e’ sempre una nostra scelta come scrivere il programma. :slight_smile:

Ma ovviamente prima di poterci ‘muovere’ agevolmente in questo ambito, bisogna imparare le basi della OOP, per cui fai bene ad applicartici.
Solo … prendila con calma … sono concetti un po’ ‘nebulosi’ a mio avviso, su cui a volte non concordano gli stessi esperti. :smile:

… Io, che sono una zucca molto dura, ci ho messo anni ad ‘abituarmi’, entro certi limiti, alla programmazione ad oggetti (Ma conservo una buona dose di scetticismo :smile: ).

Per usare RhinoCommon non e’ necessario essere un esperto di oggetti (se no non la userei nemmeno io :grinning: ).
In pratica basta sapere cos’e’ una classe e come richiamare un metodo . :slight_smile:

ma infatti qui allora ritorniamo alla mia domanda principale: del fatto per avere un risultato si possa scrivere la sintassi in modi diversi, che è diversa da come in genere sono abituato con altri linguaggi, nel senso fin’ora le strade per ottenere un certo risultato erano varie ma la sintassi del codice era sempre quella più o meno.

questo si, meglio che ci sono vari modi di scrivere perchè sicuramente userò un modo invece che un’altro
mi allaccio alla seconda mia domanda iniziale:
questi modi diversi è solo di sintassi oppure questo vale solo per i piccoli codici che mi accingerò a fare, mentre per la programmazione “vera e propria” viene scelta una determinata strada più tosto che un’altra perchè già si sà che ad un certo punto una determinata strada non andrà bene per quello che vuole fare?

credo che questo sia fondamentale saperlo a priori prima che si inizia a scrivere un codice impegnativo.

diciamo che questo non è proprio incoraggiante ahahahah

si infatti è proprio il ragionamento che stavo facendo, perchè è talmente vasto il discorso che se lo vuoi conoscere tutto ci vogliono 20anni per poi iniziare a fare qualcosa quindi imparo man mano ciò che mi serve

ovviamente grazie sempre Emilio :slight_smile:

Temo di non essere il piu’ adatto per rispondere su queste cose …
Io con gli script ‘piccolini’ di solito mi arrabatto … ma se provo a scrivere cose piu’ corpose … tendo a combinare pasticci. :smile:

Comunque, per quanto ne so, sono cose soggettive.
Voglio dire: ognuno ha le sue preferenze, magari preferenze diverse per fare cose diverse …

Il linguaggio mette a disposizione un certo numero di strumenti … che so … variabiil locali, variabili globali, moduli esterni, funzioni, classi, liste, dizionari, set, un buon numero di funzioni predefinite, cicli, istruzioni condizionali. eccetera eccetera eccetera …

Non ci sono cose che funzionano solo se lo script e’ breve e smettono di funzionare se supera, ad esempio, le 500 istruzioni … :slight_smile:
Python funziona sempre … entro i limiti delle risorse della macchina.

Siamo noi che per riuscire a fare uno script che funzioni dobbiamo trovare il modo di mantenere il controllo di quanto scriviamo.

E ognuno ha (o cerca) il suo modo di fare le cose.

Come diceva Lucio, si possono scrivere dei commenti che spieghino cosa fanno certe istruzioni o certe funzioni.
Si possono dare i nomi a variabili, funzioni, classi secondo un certo schema, che ci aiuti a ricordare di cosa si tratta.
Certamente possiamo impostare lo script usando le classi oppure no, scrivendo molte funzioni o pochissime,
scomponendo il codice in piu’ files oppure usandone uno solo … e cosi’ via …
Possiamo cercare di facilitare il debugging, di faciiltare successive modifiche …
Credo che l’unica cosa da fare sia provare.

Se ti trovi bene a scrivere in un certo modo, bene ! Usa quello.
Forse in seguito cambierei idea, imparerai altre cose, oppure dovrai fare operazioni diverse e userai strumenti diversi. :slight_smile:

Non so se ho risposto alla domanda … :confused:
Come dicevo, finche’ discutiamo dei nostri scriptini, bene. Anch’io mi faccio parecchi script per ‘aiutare’ Rhino :smile: :wink:
Ma se parliamo di programmi seri … mi spiace ma debbo ritirarmi …non e’ il mio campo … :unamused:

Spero che anche altri ti rispondano, in modo da sentire opinioni diverse … magari di qualcuno un po’ piu’ organizzato e meno casinista … :grinning:

Mi sembra una scelta saggia. :grinning:

Se utilizzi python per piccoli codici che servono a te , per sveltire certe operazioni ripetitive o per disegnare componenti parametrizzati lascia perdere le classi e usa rhinoscriptsintax.
Ciao Vittorio

Vittorio ma come, prima mi incoraggi ad imparare Python e poi mi dissuadi
ho preso anche il libro che mi hai consigliato :frowning:

cmq apparte tutto, credo che anche se usassi solo rhinoscriptsintax, ciò che sto imparando mi servirà
sicuramente sia per leggere e capire altri script sia per usare al meglio qualche cosa che realizzerò.
ps e poi non sò se si è capito, che una volta iniziato ci posso mettere un pò di tempo in più ma il libro lo finisco

Emilio, la domanda che mi faccio è: perchè un programmatore deve creare due modi differenti di fare la stessa cosa? giusto per fare un esempio pratico: se posso impostare i parametri tramite “__ int __” da programmatore perchè debbo creare un’altro sistema come “setattr” che fa la stessa cosa del primo? troverei giustificato farlo se uno oltre a fare le stesse cose, possa anche essere usato dove l’altro non può essere impiegato non credi?

mi è difficile credere che i programmatori sopratutto di un linguaggio, con obiettivi già fissati hanno poi tutto questo tempo libero da dedicare a istruzioni che danno lo stesso risultato di altre già realizzate, invece di crearne di nuove oppure di risolvere problemi che sicuramente si presentano nella programmazione.

Ad esempio perche’ setattr richiede il nome dell’attributo come stringa, quindi il nome lo puo’ costruire lo script stesso programmaticamente, e puo’ essere diverso di volta in volta.

allora c’è la spiegazione :slight_smile:

ho cercato nel web senza risultato, mi servirebbe sapere se sia possibile stampare la lista degli attributi?

class Mia:
    i=123
    def __init__(self, anni=15):
        self.a=anni

es. tipo:
print(Mia[0]) risultato i
print(Mia[1]) risultato a

ps @lucio_zadra mi sa che il militare non l’ho hai fatto vero? ahahahah

dir() ti da’ la lista degli attributi.

Ad esempio:
( Diamo retta a Vittorio e partiamo da rhinoscriptsyntax, che per impratichirsi con Python va benissimo …
E ha il vantaggio che ci consente di sperimentare con oggetti e comandi di Rhino, non con cose astratte :slight_smile: )

import rhinoscriptsyntax as rs
print( dir( rs ) )

Per incolonnare puoi usare join()

import rhinoscriptsyntax as rs
print( '\n'.join( dir( rs ) ) )

Mi son perso… qua voi fate delle discussioni “fiume” che se non stai attento ti ritrovi con 30 messaggi ingarbugliati da leggere… da cosa si evincerebbe che non ho fatto il militare? :roll_eyes:

avevo già provato dir(), quindi deduco che non sia possibile avere quel tipo di risultato. thanks Emilio :wink:

un militare non lascerebbe mai un’altro militare da solo nella trincea :smile:

Vedi che non conosci le tattiche, io sto coprendo le spalle con il fucile da cecchino… quando vedo che la situazione si fa critica, intervengo “sparando” qualche caxxata!
Non per niente sono alpino fuciliere assaltatore… mica micio micio e bao bao…

Mi sono perso io adesso … quale risultato ?
Cosa vorresti che dir() non fa ?

mi sa che ci sono riuscito alla fine giocando un pochino col dir() sono riuscito ad avere ciò che volevo:

class Mia:
    a = 'io'
    b = 'tu'
setattr(Mia, dir(Mia)[-2], 'noi')
setattr(Mia, dir(Mia)[-1], 'loro')
print(Mia.a, Mia.b)

va benissimo così grazie Emilio.

Lucio non so se te ne sei reso conto, il fatto è che qui la situazione non è critica è una catastrofe ahahahah
dai battute a parte, spero non te la sei presa volevo un pò di aiuto da una persona più razionale di me essendo che come hanno sottolineato (è lo riconosco) sono un tipo che fa girare molto l’emisfero irrazionale.

ps mica si è notato che sono un pochino anticonformista ahahahah

EDIT: faccio girare emisfero del cervello mi raccomando non fate battutacce :smile:

1 Mi Piace

Non voglio scoraggiarti . Per me il metodo migliore per imparare (che ho sempre usato a scuola) è fare allenamento con le cose semplici e poi via via affrontare le cose più complesse.
Ti allego un semplice script per fare fori ciechi che rappresentino i fori ciechi filettati. Devi scegliere l’M della vite
e selezionare la superficie su cui posizionare il foro filettato semplificato. In seguito puoi fare il foro con il filetto elicoidale.
Ciao Vittorio

1 Mi Piace

ciao Vittorio,
grazie per il file e anche per i consigli e tranquillo che non mi scoraggio, a volte cerco di scaricare un pò la tensione ma poi mi riprendo subito :slight_smile:

beh in effetti il codice risco a leggere le istruzioni che contiene, un mezzo casino sono le varie misure per creare il cilindro quelle si che c’è da perdere la testa. per il fatto di iniziare a fare prima le cose semplici sono daccordo con te infatti io di codici ancora non ho fatto nulla sto solo seguendo gli esempi del libro che mi hai consigliato il fatto è che se non riesco a leggere e quindi capire quello che Beri intende fare non posso proseguire e per questo che sto cercando di approfondire bene il discorso delle classi che si trova al cap.8 onestamente non mi va di ricopiare pari pari gli esempi del libro per poi dire “che bel codice che ho fatto” io cerco sempre di comprendere ciò che si vuole riuscire a fare e con quali mezzi, e li io cerco di metterlo in pratica con idee che mi vengono in mente così affronto anche problemi diversi che non sorgono nel libro.

ps ho voluto dare questa spiegazione no perchè non voglio ascoltare i consigli di chi sa più di me anzi,
ma era giusto per trasmettere il mio pensiero se no finisce veramente che mi prendiate per uno stramboide :slight_smile:

Ciao Vittorio !

Bello …
Non conoscevo il comando RevolvedHole.
E’ carino, mi sembra ben studiato … :slight_smile: . … Un po’ troppo specifico forse …
Peccato non abbia una opzione per aggiungere materiale anziche’ toglierne …
Anche poter scegliere l’orientamento dell’asse a volte sarebbe utile …
… E magari anche un fattore di scala … :grinning:

Grazie, Ciao !

Le varie misure sono state prese dalle norme UNI . Il diametro esterno è stato aumentato di 0.05 mm
perché con uno script che mette le quote in automatico riconosce che quel foro è un filetto e quindi mette M davanti alla quota.
Ciao Vittorio

1 Mi Piace