Looks like an IDLE problem. If you really like idle (HA HA) it might be worth filing a bug, but a better suggestion is to use a better editor / interpreter console (Emacs does the job).
V
Posts made by verte
-
RE: Weird annoying Python/vista stuff
-
RE: The 2 logins saga
@astonerbum said:
@Zecc said:
@astonerbum said:
Solution: COMPLETELY change the styles of one of the login pages. Users will not think that both are identical.
Make that the style of the whole systems (as I failed to imply in my previous post).Kind of like white/$ prompt for normal users and red/# prompt for root.
Don't restyle the system if they are both different functionality, make one login blue the other one dark red. Its so obvious she will call once or twice and everything will be back to normal. Theoretically just some CSS property changes for background/foreground colors.
The login boxes clearly state either "email address" or "<application> login", where <application> is a desktop application they use daily. I'm not sure how it could be any clearer. But like the OP says, even if you can't read, if you can't see all the features, surely before calling in a kerfuffle, you'd try the other login? Especially if you were an IT PM?
-
RE: Python, Linux, and audio
@archivator said:
for socket in read:
buff = ''.join((buff,socket.recv(48))) # data always comes in 48 B packets;
#also, this is claimed to be faster than buff += socket.recv(48)
count += 1
if count % 15 == 0:
if len(send_buff) > 0:
playback_queue.append(send_buff)
send_buff = '%s' % buff # the send buffer is always 15 packets behind buff
buff = r''
it's interesting that you've noticed that str.join is supposed to be faster that +=.it is, but not the way you're using it. Both ways involve copying the entire buffer
each time you add to it. This should be obvious to anyone with C experience, because
strcat behaves the same way. The correct thing to do is to build a list of strings,
and join them when you need a result.
None of this matters, however, since you may as well simply wait for all the packets to arrive.
Along the same lines, why are you polling a socket if you're waiting to read from it
before you can do anything anyway? I assume you left out a heap of code, including
whatever you do to capture_queue. The sad part is, it shouldn't take many more lines
to make the proxy complete.
I assume also that you realise that [, is a syntax error, and the forum software is
simply on crack. Also, while 1: is ugly. use while True:
(This is O(len(buff)) rather than O(len(buff) ** 2))
for s in read:
buff = s.recv(720) # don't loop needlesslyif len(send_buff) > 0:
playback_queue.append(send_buff)
send_buff = buff # the send buffer is always 15 packets behind buff
buff = '' # no need for raw strings, you have nothing to escape.Apologies for code mode, my first post :)