Precisazioni RCommon in Py

import Rhino
import scriptcontext

def AddObjectsToGroup():
    go = Rhino.Input.Custom.GetObject()
    go.SetCommandPrompt("Select objects to group")
    go.GroupSelect = True
    go.GetMultiple(1, 0)
    if go.CommandResult()!= Rhino.Commands.Result.Success:
        return go.CommandResult()

    ids = [go.Object(i).ObjectId for i in range(go.ObjectCount)]
    index = scriptcontext.doc.Groups.Add(ids)
    scriptcontext.doc.Views.Redraw()
    if index>=0: return Rhino.Commands.Result.Success
    return Rhino.Commands.Result.Failure

if __name__ == "__main__":
    AddObjectsToGroup()

if go.CommandResult()!= Rhino.Commands.Result.Success:
return go.CommandResult()

if name == “main”:
AddObjectsToGroup()

ma gli if prima di return go.CommandResult() e
AddObjectsToGroup() sono davvero necessari?
di sicuro c’é un motivo per controllare meglio
il codice. ma mi sfugge la vera importanza. . .

ps ma il Main nel caso di Py in Rh
sarebbe di default la pagina vuota?

Il primo if interrompe l’esecuzione della funzione se GetObject non e’ andato a buon fine.
Se esegui il return comunque, le istruzioni che seguono non saranno mai eseguite, e il gruppo non verra’ costruito in nessun caso.

Il secondo e’ il vecchio trucchetto di Python per poter testare le librerie.
Se il file in questione e’ importato come libreria, quella if risulta falsa e la funzione non viene eseguita.
Non farei caso a queste due istruzioni.
Sono cose che riguardano chi scrive la libreria. Noi possiamo passare oltre.

Non capisco cosa intendi.
Qui

if name == "main":

significa solo: se questo file e’ stato eseguito direttamente, e non importato come libreria.
Ma come dicevo, per i nostri script non c’entra.

era un mio pensiero da tempo e collegandolo adesso col C# poi lo avevo anche associato al namespace
credevo che facesse questo ragionamento: __ name __ in Py corrispondeva al namespace in C# essendo che, come mi sembra di aver capito il namespace indicherebbe l’intero progetto, similmente in Py un foglio vuoto dove scrivi il codice equivarrebbe al namespace come progetto che ha come nome __ main __

quindi il codice direbbe: se il nome del “foglio vuoto” (in C# namespace. . .) è __ main __ esegui questa def
(in pratica tutti i fogli vuoti di Py dovrebbero avere __ main __ come nome di default (mi sembrava strano)
ma come dici invece serve a controllare se il file è importato come libreria. quindi come non detto :+1:

if go.CommandResult()!= Rhino.Commands.Result.Success:
        return go.CommandResult()

questa non lo capita però. . . per me la leggo al contrario di ciò che hai spiegato :thinking:

se il comando.risultato è diverso dal buonfine (quindi ha fallito) ritorna comando.risultato (dammi il risutato)

come anche qui:

    if index>=0: return Rhino.Commands.Result.Success
    return Rhino.Commands.Result.Failure

se index => 0 dammi risultato andato a buonfine
però poi riga successiva contemporaneamente
ritorna dammi il risultato fallito
(ma se sopra è andato bene?)

Be’, si’ … possiamo anche interpretarlo in questo modo.
Credo che per la precisione __main__ in Python sia il nome del modulo, ma mi sembra un concetto simile al namespace di C#.

Comunque se ti interessa e’ una cosa spiegata in tutti i libri su Python. :slight_smile:
C’e’ chi la usa anche negli script per Rhino.

A proposito, il codice che hai postato non viene da rhinoscriptsyntax.
Sembra un plug-in, dove lo hai preso ? :slight_smile:

Se il risultato non e’ Success, restituisce il risultato, che quindi sara’ ad esempio Failure o un altro valore di quella enumeration.
Cioe’ il risultato suona come “Non ha funzionato”.

E, come ho detto sopra, se tu esci dalla funzione qui, chi e’ che costruisce il gruppo, visto che le istruzioni necessarie sono scritte dopo ?

Cioe’ quelle 5 righe di Python scritte sotto a cosa servono se tu esci dalla funzione prima quando lo script funziona ?

eeee quello consigliatomi dell’apogeo non dovrei averlo perso, ma chissà dov’é finito. . .

infatti sto cercando con Py di prendere un po di confidenza con RCommon prima di scriverli in VS anche perché come hai visto con la guida in Py mi sembra più fattibile essendo che ha un minimo di esempi.

lo avevo salvato ultimamente girando nei vari link postati in qualche 3d, poi proprio per caso mentre cercavo dei riferimenti prima di postare le domande guarda caso l’avevo ribeccato :wink: ecco il link:

ok quindi non ero proprio fuori strada :+1:

1 Mi Piace

:man_facepalming: :man_facepalming:

credo sia un po ambigua come dicitura, per me un risultato.success
mi fa capire che va ad indicare il risultato che è andato a buon fine

ma se mi dici: il risultato non’é Success restituisce il risultato e quindi torna Failure
quindi Success non indica Successo (buon fine)

succ

quindi succede questo?

Perche’ no ?
Success indica che GetObject ha avuto successo, cioe’ ha selezionato degli oggetti.
Quindi l’elaborazione puo’ proseguire e costruire il nuovo gruppo.

Se invece GetObject non ha avuto successo, allora possiamo uscire subito dalla funzione, tanto non c’e’ possibilita’ di costruire il gruppo.

L’idea, come la capisco io, e’ questa:

Se GetObject non ha funzionato, usciamo subito dalla funzione, non c’e’ altro da fare.
Se invece ha funzionato, andiamo avanti e costruiamo il gruppo.

Non ti sembra che sia quello che fa il codice ?

volevo fare una prova con il print ma invece di chiarirmi le idee me le complica maggiormente
come mai stampa due volte “prova”, e peggio ancora se il print lo sposto sopra if si inverte la stampa :exploding_head:

che il codice funziona come dici tu queto lo avevo ormai constatato
è sulla sintassi che non mi trovo. ma forse è perché non conosco il funzionamento di queste nuove parole

io ero rimasto (anche in C#) che quando vuoi uscire fuori dal codice quindi terminare il tutto metti break
ovviamente ci sono vari metodi e ok. nel primo if (se il risultato del comando non è diverso da “Success” ritorna il risultato del comando)

CommandResult Method: Helper method for getting command result value from getter results.
quindi in teoria dovrebbe solo restituire un valore e non uscire dal codice
(a meno che non’é una funziona intrinseca della metodo stesso,
quindi utilizzando getobject() se è null esci direttamente. . .)

non lo so sto ipotizzando per cercare di capire

nel secondo if invece uguale se index => 0 ritorna il valore del risultato Success (fin qui va bene)
però poi continua con return Rhino.Commands.Result.Failure è questa parte non’é nemmeno indentata
quindi per come la vedo io a prescindere dal risultato del if (penultima riga) ultima riga dovrebbe essere comunque in ogni modo eseguita. a meno che l’azione di uscita dal codice non’é nel getobject ma in questi metodi cioè: CommandResult / Result.Success / Result.Failure?

primo caso:

esegue if __name__ eccetera e quindi esegue la routine, trova il print e scrive “prova”
poi esegue print AddObjects eccetera quindi:
1) esegue di nuovo la routine, trova print e scrive “prova”
2) finita l’esecuzione della routine, la print AddObjects … scrive il valore restituito: “Success”

secondo caso:
cambia semplicemente l’ordine di quanto detto sopra, per cui prima stampa “prova” e “Success”
e poi stampa “prova”

Quali parole ?
Dicci cosa non e’ chiaro.

Il break ti fa solo uscire dai cicli.
Per uscire da una funzione o metodo abbiamo sempre usato return in Python, come anche in C#.
Il VSB non usa return … ma lui ama distinguersi. :wink: :smile: :smile:

E’ esattamente quello che fa.
E la if che puo’ farti uscire, eseguendo il return in certi casi.
La if dice: se il risultato non e’ Success, allora return …
E’ sempre e solo il return che ti fa uscire dalla routine.

Non deve essere indentata. Va eseguita se la if e’ falsa.
E’ come scrivere

    if index>=0: 
        return Rhino.Commands.Result.Success
    else:
        return Rhino.Commands.Result.Failure

Se non esce con la if, esce alla riga dopo.
Non c’e’ niente di strano.

Ci sono due if prima che in certi casi eseguono return
Come fa l’ultima riga ad essere sempre eseguita ?

Qui:

    if go.CommandResult()!= Rhino.Commands.Result.Success:
        return go.CommandResult()

se il risultato non e’ Success, usciamo dalla routine.

E qui:

   if index>=0: return Rhino.Commands.Result.Success

se index e’ maggiore o uguale a zero, usciamo dalla routine.

In questi casi, come ci arrivi all’ultima riga ?

Se permetti una considerazione …
Ho l’impressione che tu abbia dimenticato il return
E’ vero che negli script in Python spesso non si usano funzioni e lo script non deve restituire niente, quindi potresti essere un po’ “fuori allenamento” col return. :wink:
Ma e’ sempre stata l’istruzione usata per restituire un valore da una funzione.
Forse prima di ammattire con questi esempi conviene ripassare un momento il return. :slight_smile:
Serve anche per il C#, anche lui usa il return.

1 Mi Piace

in verità non dico mai usato ma quasi :sweat_smile:

ecco l’arcano, il return. . . e che quel paio di volte che avevo visto e usato nel codice (poche righe)
era sempre alla fine del codice, quindi credevo che riportasse solo il risultato finale della def
mi ero perso la parte che ti fa anche uscire dal codice allora a questo punto ok :+1:

1 Mi Piace

ok anche qui :ok_hand:

immagine

eeee che debbo fare. . . per andare avanti ho bisogno di fare prima qualche passo indietro :wink:

giustamente anche con il print prova() va a richiamare la def quindi nell’esempio di prima veniva eseguita
sempre 2 volte ma in ordine diverso tutto chiaro. Emilio senza le tue spiegazioni sarei perso :clap: :clap:

ps per questo ho pensato che fosse opportuno, prima di approcciarmi al C# in Rhino
capire un pochino come funziona il Common in Py che mi è sempre stato ostico :wink:

1 Mi Piace