Ops, sending to the whole list.
On 2/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I tried to fix a few more unit tests tonight that had started failing
> after the introduction of dict views. Looking over UserDict.py, it's
> clear that this module needs more work -- while I banged it into
On 2/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Perhaps the most egregious example is MixinDict, which currently
> assumes that keys() is a primitive operation returning a list, and
> builds __iter__() out of that. Obviously a better approach is to turn
> this around. (I'd have thought th
On 2/13/07, Chris Rebert <[EMAIL PROTECTED]> wrote:
> There are currently few, if any, known good uses of the current
> behavior of mutable default arguments.
Then are there *any* good use cases for the proposed semantics?
Here are the use cases that I can remember seeing for mutable de
On 2/15/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 2/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Perhaps the most egregious example is MixinDict, which currently
> > assumes that keys() is a primitive operation returning a list, and
> > builds __iter__() out of that. Obviously a
Since I contributed DictMixin and have been responsible for its maintenance,
if no one minds, I would like to be the one to migrate it to Py3.0.
Raymond
- Original Message -
From: "Guido van Rossum" <[EMAIL PROTECTED]>
To: "Steven Bethard" <[EMAIL PROTECTED]>
Cc: "Python 3000" ; "Eduar
On 2/15/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 2/13/07, Chris Rebert <[EMAIL PROTECTED]> wrote:
> > There are currently few, if any, known good uses of the current
> > behavior of mutable default arguments.
>
> Then are there *any* good use cases for the proposed semantics?
Note
* Remove the unreliable empty() and full() methods from Queue.py
* Remove jumpahead() from the random API. It is somewhat uncommon for PRNGs to
have a closed form solution that jumpsahead N steps.
* Make the primative for random be something generating random bytes rather
than
random floats.
Okay, in light of Guido's comments, alternate idea:
We require all default values to be hash()-able, thus reasonably
ensuring their immutability. This doesn't deal with the 'x=None...'
dance, but at least it might stop dangerous code from being written. Or
if anyone else has ideas, that's great
On Thu, Feb 15, 2007 at 09:37:27PM -0800, Chris Rebert wrote:
> Okay, in light of Guido's comments, alternate idea:
>
> We require all default values to be hash()-able, thus reasonably
> ensuring their immutability.
Offhand, that's a pretty arbitrary restriction- default __hash__
for objects is
