Kontrollere argumenter i numerisk Python-kode

stemmer
3

Jeg finner meg selv å skrive det samme argumentet kontrollkoden hele tiden for tallknusing:

def myfun(a, b):
    if a < 0:
        raise ValueError('a cannot be < 0 (was a=%s)' % a)
    # more if.. raise exception stuff here ...
    return a + b

Finnes det en bedre måte? Jeg ble fortalt ikke å bruke 'hevde' for disse tingene (selv om jeg ikke ser problemet, bortsett fra ikke vite verdien av variabelen som forårsaket feilen).

Edit: For å klargjøre, argumentene er vanligvis bare tall og feil sjekke forholdene kan være komplisert, ikke-triviell og vil ikke nødvendigvis føre til et unntak senere, men bare til feil resultat. (Ustabile algoritmer, meningsløse løsninger etc)

Publisert på 29/10/2009 klokken 04:17
kilden bruker
På andre språk...                            


3 svar

stemmer
0

Du ønsker ikke å bruke hevde fordi koden kan kjøres (og er som standard på noen systemer) på en slik måte at hevde linjer er ikke merket og ikke heve feil ( -Okommandolinjeflagg).

Hvis du bruker en rekke variabler som alle skal ha de samme egenskaper, hvorfor ikke underklasse uansett type du bruker, og legger til at sjekk til klassen selv? Så når du bruker den nye klassen, vet du at du aldri har en ugyldig verdi, og trenger ikke å gå å se etter det over alt.

Svarte 29/10/2009 kl. 04:21
kilden bruker

stemmer
4

assertblir optimalisert bort hvis du kjører med python -O(beskjedne optimaliseringer, men noen ganger er fint å ha). En bedre alternativ hvis du har mønstre som ofte gjentar kan være å bruke dekoratører - flott måte å faktor ut repetisjon. Eg, si at du har en zillion funksjoner som må kalles med argumenter for-stilling (ikke av-søkeord) og må ha sine første argumentene positive; deretter...:

def firstargpos(f):
  def wrapper(first, *args):
    if first < 0:
      raise ValueError(whateveryouwish)
    return f(first, *args)
  return wrapper

så du si noe sånt som:

@firstargpos def myfun (a, b): ...

og kontrollene er utført i dekoratører (eller snarere wrapper nedleggelsen den returnerer) en gang for alle. Så er det bare vanskelige delen å finne ut nøyaktig hva som sjekker dine funksjoner trenger og hvordan best å ringe dekoratør (e) til å uttrykke disse (vanskelig å si, uten å se det sett av funksjoner du definerer og sett sjekker hver behov ! -). Husk, DRY ( "Ikke gjenta deg selv") er i nærheten av topplasseringen blant hovedprinsipper i programvareutvikling, og Python har rimelig støtte slik at du kan implementere TØRR og unngå boilerplatey, repeterende kode -)

Svarte 29/10/2009 kl. 04:24
kilden bruker

stemmer
-1

Jeg er ikke sikker på om dette vil svare på spørsmålet ditt, men det slår meg at du sjekker en rekke argumenter ved starten av en funksjon er ikke veldig Pytonske .

Hva jeg mener med dette er at det er forutsetningen for de fleste pythonistas at vi er alle samtykkende voksne, og vi stoler på hverandre for ikke å gjøre noe dumt. Her er hvordan jeg skulle skrive ditt eksempel:

def myfun(a, b):
    '''a cannot be < 0'''
    return a + b

Dette har tre klare fordeler. First off, det er kortfattet, det er egentlig ingen ekstra kode å gjøre noe som ikke er relatert til hva du faktisk prøver å få gjort. For det andre setter den informasjonen nøyaktig hvor den hører hjemme, i help(myfun)hvor pythonistas forventes å lete etter bruk notater. Til slutt, er en ikke-positiv verdi for avirkelig en feil? Selv om du kanskje tror det, med mindre noe definitivt vil bryte hvis en er null (her er det sannsynligvis wont), så kanskje la den gli gjennom og forårsake en feil opp samtalen strømmen er klokere. Tross alt, hvis a + ber feil, reiser det et unntak som blir gått opp kallstakken og atferd er fortsatt ganske mye det samme.

Svarte 29/10/2009 kl. 04:44
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more