[issue5736] Add the iterator protocol to dbm modules

Christopher Lee added the comment: Another reason this issue is really important, is that the lack of a consistent iter() interface for dbm.* makes shelve iteration not scalable; i.e. trying to iterate on a Shelf will run self.dict.keys() to load the entire index into memory. This seems

[issue6045] Fix dbm interfaces

Christopher Lee added the comment: I suspect that for most users, shelve is the main way they will access the dbm.* interfaces. Based on that, the dict methods that are really needed on dbm.* objects are just: __iter__, __len__, __getitem__, __setitem__, __delitem__, __contains__, has_key, and

[issue22627] Calling timestamp() on a datetime object modifies the timestamp of a different datetime object.

New submission from Christopher Lee: I have an example script here[1]. This script creates 2 datetime objects (using a timedelta work around to deal with large timestamps). It then makes 2 assertions, that the timestamp of the created object is the same as the one that was used to create it

[issue22627] Calling timestamp() on a datetime object modifies the timestamp of a different datetime object.

Christopher Lee added the comment: Hi Antoine, thanks for taking a look. I should explain further. This code is for an introspection tool[1] that provides an interface to write tests in python against an application. This code is a workaround for using large timestamps[2] (i.e. larger than

[issue22627] Calling timestamp() on a datetime object modifies the timestamp of a different datetime object.

Christopher Lee added the comment: Alexander, Ah ok thanks for clarifying that. Am I wrong then to think that this code[1] should work as I think it should (i.e. datetime_from_large_timestamp(example_ts) == datetime.fromtimestamp(example_ts)) I'm trying to be able to handle timestamps l

[issue22627] Calling timestamp() on a datetime object modifies the timestamp of a different datetime object.

Christopher Lee added the comment: Thanks Akira, everyone for all the info. It looks like I've highjacked this bug comments to trying to solve my first problem (i.e. datetime objects for large timestamps) instead of the bug at hand, I feel should move that conversation elsewhere. It ap