Phillip J. Eby wrote:
> At 07:40 PM 7/9/2007 -0500, Ron Adam wrote:
>
>> Guido van Rossum wrote:
>>
>>> We could easily change this to return a
>>> writable mapping that's not a dict at all but a "view" on the locals
>>> just as dict.keys() returns a view on a dict. I don't see why locals()
>>>
On Monday 09 July 2007, Greg Ewing wrote:
> Isn't it rather dangerous to rely on any built-in
> Python operations to be atomic? They might happen
> to be, but I don't think there's any guarantee
> they will stay that way.
My limited recollection is that setdefault() was all about it being atom
Matt Chisholm wrote:
> Are break / continue currently abused more than they are used right,
> or used to make code difficult to understand?
In my experience, using break and continue for anything
other than a standard loop-and-a-half makes code hard
to follow, even when there is only one loop. Lab
On Jul 3 2007, 10:14, Guido van Rossum wrote:
>On 6/30/07, Matt Chisholm <[EMAIL PROTECTED]> wrote:
>>I've created and submitted a new PEP proposing support for labels in
>>Python's break and continue statements. Georg Brandl has graciously
>>added it to the PEP list as PEP 3136:
>>
>>http://www.
Phillip J. Eby wrote:
> However, there is another class of use cases which use setdefault for
> its limited atomic properties - the initialization of non-mutated
> data structures that are shared among threads.
Isn't it rather dangerous to rely on any built-in
Python operations to be atomic? The
At 07:40 PM 7/9/2007 -0500, Ron Adam wrote:
>Guido van Rossum wrote:
>
>>We could easily change this to return a
>>writable mapping that's not a dict at all but a "view" on the locals
>>just as dict.keys() returns a view on a dict. I don't see why locals()
>>couldn't return the object used to repr
Guido van Rossum wrote:
> We could easily change this to return a
> writable mapping that's not a dict at all but a "view" on the locals
> just as dict.keys() returns a view on a dict. I don't see why locals()
> couldn't return the object used to represent the namespace, but I
> don't see that it
Barry Warsaw wrote:
> However, .setdefault() is a horrible name because it's not clear from
> the name that a 'get' operation also happens.
The return value of .setdefault() could be changed to None, then the name
would be correct.
And then a helper function could fill the current use case of
At 12:04 AM 7/10/2007 +0300, Guido van Rossum wrote:
>On 7/9/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>>Phillip, I support any initiative to keep .setdefault() or similar
>>functionality. When this thread came up before, I wasn't against
>>defaultdict, I just didn't think it covered enough of t
At 11:56 PM 7/9/2007 +0300, Guido van Rossum wrote:
> The use of the word "mapping"
>might easily be construed as implementing abc.Mapping, and then
>iteration and reading the contents would be well-defined.
I'm not sure which use of the word "mapping" you're talking
about. PEP 3115 is explicit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 9, 2007, at 5:29 PM, Raymond Hettinger wrote:
>> PEP 3100 suggests dict.setdefault() may be removed in Python 3, since
>> it is in principle no longer necessary (due to the new defaultdict
>> type).
>
> I've forgotten. What was the whole poi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 9, 2007, at 5:04 PM, Guido van Rossum wrote:
> On 7/9/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> Phillip, I support any initiative to keep .setdefault() or similar
>> functionality. When this thread came up before, I wasn't against
>> defa
Raymond Hettinger wrote:
> > PEP 3100 suggests dict.setdefault() may be removed in
> > Python 3, since it is in principle no longer necessary
> > (due to the new defaultdict type).
>
> I've forgotten. What was the whole point of Python 3.0?
> Is it to make the language fat with lots of ways to d
> PEP 3100 suggests dict.setdefault() may be removed in Python 3, since
> it is in principle no longer necessary (due to the new defaultdict type).
I've forgotten. What was the whole point of Python 3.0?
Is it to make the language fat with lots of ways to do everything?
Guys, this is your ONE ch
On 7/9/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Phillip, I support any initiative to keep .setdefault() or similar
> functionality. When this thread came up before, I wasn't against
> defaultdict, I just didn't think it covered enough of the use cases
> of .setdefault() to warrant its removal
Barry Warsaw <[EMAIL PROTECTED]> writes:
> However, .setdefault() is a horrible name because it's not clear
> from the name that a 'get' operation also happens.
Agreed! From the name, a clever but naive user would assume that
"setdefault" sets what value the dictionary returns when a key does
no
On 7/9/07, tav <[EMAIL PROTECTED]> wrote:
> setdefault's ability to return current value is also a very useful
> functionality and has saved writing:
>
> if key not in dict:
> value =
> dict[key] = value
>
> with the simpler:
>
> value = dict.setdefault(key, )
>
> Is there a better way
On 7/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 06:13 PM 7/9/2007 +0300, Guido van Rossum wrote:
> >On 7/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > At 09:03 PM 7/9/2007 +1000, Nick Coghlan wrote:
> > > >However, I will point out that setting class attributes via locals() is
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 9, 2007, at 2:44 PM, Phillip J. Eby wrote:
> PEP 3100 suggests dict.setdefault() may be removed in Python 3, since
> it is in principle no longer necessary (due to the new defaultdict
> type).
>
> However, there is another class of use cases
At 07:59 PM 7/9/2007 +0100, tav wrote:
>>PEP 3100 suggests dict.setdefault() may be removed in Python 3, since
>>it is in principle no longer necessary (due to the new defaultdict type).
>>
>>However, there is another class of use cases which use setdefault for
>>its limited atomic properties - the
> PEP 3100 suggests dict.setdefault() may be removed in Python 3, since
> it is in principle no longer necessary (due to the new defaultdict type).
>
> However, there is another class of use cases which use setdefault for
> its limited atomic properties - the initialization of non-mutated
> data st
PEP 3100 suggests dict.setdefault() may be removed in Python 3, since
it is in principle no longer necessary (due to the new defaultdict type).
However, there is another class of use cases which use setdefault for
its limited atomic properties - the initialization of non-mutated
data structures
At 06:13 PM 7/9/2007 +0300, Guido van Rossum wrote:
>On 7/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 09:03 PM 7/9/2007 +1000, Nick Coghlan wrote:
> > >However, I will point out that setting class attributes via locals() is
> > >formally undefined (it happens to work in current versions
On 7/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:03 PM 7/9/2007 +1000, Nick Coghlan wrote:
> >However, I will point out that setting class attributes via locals() is
> >formally undefined (it happens to work in current versions of CPython,
> >but there's no guarantee that will always be
At 09:03 PM 7/9/2007 +1000, Nick Coghlan wrote:
>However, I will point out that setting class attributes via locals() is
>formally undefined (it happens to work in current versions of CPython,
>but there's no guarantee that will always be the case).
As of PEP 3115, it's no longer undefined for cla
Brian Harring wrote:
>
> I'd be curious if there is anyway to preserve the existing behaviour;
>
> class foo:
> some_list = ('blacklist1', 'blacklist2')
> known_bad = some_list += ('blah',)
> locals().update([(attr, some_callable) for attr in some_list])
>
> is slightly contrived, but I u
26 matches
Mail list logo
