Code: Alles auswählen
for (signr, args) in self.pset.pending:
if ((unblocks >> signr) & 1):
self.send(signr, args)
#self.pset.pending.remove((signr,args))
Code: Alles auswählen
pendings = copy.copy(self.pset.pending)
unblocks = olMask & nwMask
# notify all signals which are executed during the blocked time
for (signr, args) in pendings:
if ((unblocks >> signr) & 1):
self.send(signr, args)
self.pset.pending.remove((signr,args))
Code: Alles auswählen
for (signr, args) in pendings[:]:
print signr
if ((unblocks >> signr) & 1):
pendings.remove((signr,args))
#print pendings
Code: Alles auswählen
self.send_items(self.pset.remove(ol & nw))Code: Alles auswählen
def remove(self, unblocked):
pending = list()
for item in self.pending:
if item.match(unblocked):
yield item
else:
pending.append(item)
self.pending = pending
genau das war ja meine intention beim ersten versuch die liste zu bearbeiten.Das ist algorithmisch gesehen nicht besonders elegant, weil `remove()` ja wieder von vorne durch die Liste geht und etwas sucht, was man eigentlich ja gerade in den Fingern hatte.
genau das war mein erster code mit dem resultat das der index rutschte und die exception geworfen wurde. à la out of rangeDa wäre es vielleicht besser mit `enumerate()` den Index mit zu führen und dann ``del`` zu verwenden
Code: Alles auswählen
if item.match(unblocked): Code: Alles auswählen
def procmask(self, how, nwMask = None):
if self.pset is None:
return 0
olMask = self.pset.sigmask
if nwMask is not None:
if how == SIG_BLOCK:
self.pset.sigmask = olMask | nwMask
return olMask
if how == SIG_UNBLOCK:
self.pset.sigmask = olMask &~nwMask
elif how == SET_MASK:
self.pset.sigmask = nwMask
else:
return 0
#*************************************************************************
pendings = list()
unblocks = olMask & nwMask
# notify all signals which are executed during the blocked time
for (signr, args) in self.pset.pending:
if unblocks >> signr & 1:
self.send(signr, args)
else:
pendings.append((signr, args))
self.pset.pending = pendings
return olMask
Code: Alles auswählen
def send_pending(self):
pending = list()
for signal in self.pset.pending:
if signal.type not in self.pset.blocked_signals:
self.send(signal)
else:
pending.append(signal)
self.pset.pending = pending
def set_blocked_signals(self, signals):
self.pset.blocked_signals = signals
self.send_pending()
def block_signals(self, signals):
self.set_blocked_signals(self.pset.blocked_signals | signals)
def unblock_signals(self, signals):
self.set_blocked_signals(self.pset.blocked_signals - signals)
Arrrrrrr**** da stimme ich mir leider nicht überein. Als Programmierer sollte man schon wissen was da gemacht wird. Auch wenn es auf den ersten Blick nicht ersichtlich ist. Denn das ist ja nun mal kein riesen Quelltext und wir lesen ja keine Märchengeschichte.Das wäre aus dem gleichen Grund schlimm, warum auch Bitoperationen schlecht sind: Es verwirrt den Leser des Quelltextes
jep das ist mir schon klar. Nur störe ich mich momentan immer noch daran, dass hier Referenzen übergeben werden, wenn man aber eine Kopie benötigt. Oder besser, dass die Keys in den listen rutschen. Übrigens die Lösung mit den selbst implementierten Linked Listen funzt einwandfrei.während bei der aktuellen Lösung jedes Element in amortisiert O(1)-Laufzeit kopiert wird.
Gewöhne dich einfach daran etwas mehr Code zu schreiben und allen Dingen sinnvolle Namen zu geben.Ich kenne auch einen Informatiker, von dem ich diesen Satz vor 2 Jahren gehört habe. Der war Ende Fünfzig.maxwell hat geschrieben:das mag vielleicht altbacken klingen aber sehr interessant diese OOP
Natürlich sollte jeder Programmierer das wissen, aber man muss das Verständnis nicht noch erschweren. Quelltext mag zwar keine Märchengeschichte sein, aber auch sicher kein kryptisches Rätsel.maxwell hat geschrieben:Arrrrrrr**** da stimme ich mir leider nicht überein. Als Programmierer sollte man schon wissen was da gemacht wird. Auch wenn es auf den ersten Blick nicht ersichtlich ist. Denn das ist ja nun mal kein riesen Quelltext und wir lesen ja keine Märchengeschichte.
ich bin ende zwanzig und mein prof meint, dass er es bei mir aufgegen hat.Der war Ende Fünfzig.
Wie heißt es so schön: Jeder kann Quelltext für Computer schreiben, gute Programmierer aber schreiben Quelltext für Menschen.maxwell hat geschrieben:Ja "ol" & "nw" stehen für "old" & "new". Was das betrifft, kenne ich eigentlich nur solch "short names". ich mags einfach nicht wenn man - wie ich in unzähligen beispielen der OOP gesehen habe - selbst klassenbezeichnungen mit "dies_ist_meine_klasse_a" oder noch besser "DiesIstMeineKlasseA" bezeichnet. [...] Als Programmierer sollte man schon wissen was da gemacht wird. Auch wenn es auf den ersten Blick nicht ersichtlich ist. Denn das ist ja nun mal kein riesen Quelltext und wir lesen ja keine Märchengeschichte.
Da bist du bei Python ja genau richtig. Der Code ist in Python im Schnitt etwa um den Faktor 6-10 kürzer als in C. Die gewonnene Zeit nutzt man halt unter anderem gern dazu ordentliche Namen zu vergeben.außerdem bin ich von natur aus "tippfaul".
Code: Alles auswählen
import thiswer das gesagt hat, hat einen sehr schlechten tag gehabt!Jeder kann Quelltext für Computer schreiben, gute Programmierer aber schreiben Quelltext für Menschen.
Code: Alles auswählen
unsigned long i, *s, *m, x;
int sig = 0;
s = pending->signal.sig;
m = mask->sig;
switch (_NSIG_WORDS) {
default:
for (i = 0; i < _NSIG_WORDS; ++i, ++s, ++m)
if ((x = *s &~ *m) != 0) {
sig = ffz(~x) + i*_NSIG_BPW + 1;
break;
}
break;
case 2: if ((x = s[0] &~ m[0]) != 0)
sig = 1;
else if ((x = s[1] &~ m[1]) != 0)
sig = _NSIG_BPW + 1;
else
break;
sig += ffz(~x);
break;
case 1: if ((x = *s &~ *m) != 0)
sig = ffz(~x) + 1;
break;
}
Und Ahnung hat Martin Fowler auch keinemaxwell hat geschrieben:wer das gesagt hat, hat einen sehr schlechten tag gehabt!Jeder kann Quelltext für Computer schreiben, gute Programmierer aber schreiben Quelltext für Menschen.