use dict.get(key) instead of dict[key] for safety from KeyErrors #521

Merged
merged 1 commit into from Jun 14, 2011

Conversation

Projects
None yet
2 participants
@minrk
Member

minrk commented Jun 13, 2011

This protects against missing keys in object introspection, etc. when using the pure Python kernel.

addresses #516 and #519

use dict.get(key) instead of dict[key] for pure kernel
This protects against missing keys in object introspection, etc.
when using the pure Python kernel.

closes gh-516
closes gh-519
@mspacek

This comment has been minimized.

Show comment Hide comment
@mspacek

mspacek Jun 14, 2011

Contributor

Yes, this seems to fix both #516 and #519 for me. Thanks!

Contributor

mspacek commented Jun 14, 2011

Yes, this seems to fix both #516 and #519 for me. Thanks!

@minrk minrk merged commit b5570f7 into ipython:master Jun 14, 2011

@mspacek

This comment has been minimized.

Show comment Hide comment
@mspacek

mspacek Jun 14, 2011

Contributor

Actually, hold on. I may be going a little crazy, but now I'm getting this:

>>> a = 1
>>> a
1
>>> a
>>> 1

i.e. the 2nd time I type a to get it to print out, it prints its value after a prompt. Hitting ESC clears it, and then it prints properly for the next try or two, before it prints incorrectly again. Seems somewhat random how often it occurs.

Contributor

mspacek commented Jun 14, 2011

Actually, hold on. I may be going a little crazy, but now I'm getting this:

>>> a = 1
>>> a
1
>>> a
>>> 1

i.e. the 2nd time I type a to get it to print out, it prints its value after a prompt. Hitting ESC clears it, and then it prints properly for the next try or two, before it prints incorrectly again. Seems somewhat random how often it occurs.

@minrk

This comment has been minimized.

Show comment Hide comment
@minrk

minrk Jun 14, 2011

Member

With any reliability? This code has exactly nothing to do with that. There is technically no guarantee to the ordering of execute replies and output, but there is a tiny sleep between them to make this sort of thing unlikely.

Member

minrk commented Jun 14, 2011

With any reliability? This code has exactly nothing to do with that. There is technically no guarantee to the ordering of execute replies and output, but there is a tiny sleep between them to make this sort of thing unlikely.

@mspacek

This comment has been minimized.

Show comment Hide comment
@mspacek

mspacek Jun 14, 2011

Contributor

Yeah, there's about a 50% chance for me. You don't see the same? Again, strange that I'm starting to notice all these problems in pure mode only today. Couldn't b7839fa have changed something?

Contributor

mspacek commented Jun 14, 2011

Yeah, there's about a 50% chance for me. You don't see the same? Again, strange that I'm starting to notice all these problems in pure mode only today. Couldn't b7839fa have changed something?

@minrk

This comment has been minimized.

Show comment Hide comment
@minrk

minrk Jun 14, 2011

Member

Ah - the tiny sleep is not in the pure Python kernel, only IPython. I just copied it over to pykernel, so it should now be better.

Yet another of the previous bugfixes made in ipkernel not ported to pykernel.

Member

minrk commented Jun 14, 2011

Ah - the tiny sleep is not in the pure Python kernel, only IPython. I just copied it over to pykernel, so it should now be better.

Yet another of the previous bugfixes made in ipkernel not ported to pykernel.

@mspacek

This comment has been minimized.

Show comment Hide comment
@mspacek

mspacek Jun 14, 2011

Contributor

Much better now. Thanks!

Contributor

mspacek commented Jun 14, 2011

Much better now. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment