"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> [Martin v. Löwis]
> > This kind of invariant doesn't take into account
> > that there might be a default value.
>
> Precisely. Therefore, a defaultdict subclass violates the Liskov
> Substitution
> Principle.
class defaultdict(dict):
def __g
[Terry Reedy]
> One is a 'universal dict' that maps every key to something -- the default if
> nothing else. That should not have the default ever explicitly entered.
> Udict.keys() should only give the keys *not* mapped to the universal value.
Would you consider it a mapping invariant that "k
Raymond Hettinger wrote:
>> If you have a default value, you cannot ultimately del a key. This
>> sequence is *not* a basic mapping invariant.
>
>
> You believe that key deletion is not basic to mappings?
No, not in the sense that the key will go away through deletion.
I view a mapping as a modi
Neal Norwitz wrote:
> http://www.python.org/dev/buildbot/
>
> Whoever is first to break the build, buys a round of drinks at PyCon!
> That's over 400 people and counting:
> http://www.python.org/pycon/2006/pycon-attendees.txt
>
> Remember to run the tests *before* checkin. :-)
Don't we have a
[Martin v. Löwis]
> If you have a default value, you cannot ultimately del a key. This
> sequence is *not* a basic mapping invariant.
You believe that key deletion is not basic to mappings?
> This kind of invariant doesn't take into account
> that there might be a default value.
Precisely. The
Neal Norwitz wrote:
> http://www.python.org/dev/buildbot/
Unfortunately, test_logging still fails sporadically on Solaris.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Benji York wrote:
>>http://www.python.org/dev/buildbot/
>
>
> If there's interest in slightly nicer buildbot CSS (something like
> http://buildbot.zope.org/) I'd be glad to contribute.
I personally don't care much about the visual look of web pages.
However, people have commented that the build
Neal Norwitz wrote:
> http://www.python.org/dev/buildbot/
>
> Whoever is first to break the build, buys a round of drinks at PyCon!
> That's over 400 people and counting:
> http://www.python.org/pycon/2006/pycon-attendees.txt
>
> Remember to run the tests *before* checkin. :-)
I don't think we
Raymond Hettinger wrote:
>>>Also, I think has_key/in should return True if there is a default.
> * if __contains__ always returns True, then it is a useless feature (since
> scripts containing a line such as "if k in dd" can always eliminate that line
> without affecting the algorithm).
If you m
Travis E. Oliphant wrote:
> Why not just
>
> #if SIZEOF_SIZE_T == 2
> #define PY_SSIZE_T_MAX 0x7fff
> #elif SIZEOF_SIZE_T == 4
> #define PY_SSIZE_T_MAX 0x7fff
> #elif SIZEOF_SIZE_T == 8
> #define PY_SSIZE_T_MAX 0x7fff
> #elif SIZEOF_SIZE_T == 16
> #define PY_SSIZE_T_MAX 0x7
> Quoting [EMAIL PROTECTED]:
>> The only question in my mind is whether or not getting a non-existent
>> value
>> under the influence of a given default value should stick that value in
>> the
>> dictionary or not.
It seems to me that there are at least two types of default dicts, which
have op
Neal Norwitz wrote:
> http://www.python.org/dev/buildbot/
If there's interest in slightly nicer buildbot CSS (something like
http://buildbot.zope.org/) I'd be glad to contribute.
--
Benji York
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
Martin v. Löwis wrote:
> Adam Olsen wrote:
>
>>Still -1. It's better, but it violates the principle of encapsulation
>>by mixing how-you-use-it state with what-it-stores state. In doing
>>that it has the potential to break an API documented as accepting a
>>dict. Code that expects d[key] to rai
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
> Except that ambiguates it even further.
>
> Is encodings.tounicode() encoding, or decoding? According to everything
> you have said so far, it would be decoding. But if I am decoding binary
> data, why should it be spending any time
> > Also, I think has_key/in should return True if there is a default.
> It certainly seems desirable to see True where d[some_key]
> doesn't raise an exception, but one could argue either way.
Some things can be agreed by everyone:
* if __contains__ always returns True, then it is a useless fea
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Bengt Richter wrote:
>
> > My guess is that realistically default_factory will be used
> > to make clean code for filling a dict, and then turning the factory
> > off if it's to be passed into unknown contexts.
>
> This suggests that maybe the autodict beh
Guido van Rossum wrote:
> On 2/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>>Over lunch with Alex Martelli, he proposed that a subclass of dict
>>with this behavior (but implemented in C) would be a good addition to
>>the language. It looks like it wouldn't be hard to implement. It could
Martin v. Löwis wrote:
> Guido van Rossum wrote:
>
>>Feedback?
>
>
> I would like this to be part of the standard dictionary type,
> rather than being a subtype.
>
> d.setdefault([]) (one argument) should install a default value,
> and d.cleardefault() should remove that setting; d.default
> sh
http://www.python.org/dev/buildbot/
Whoever is first to break the build, buys a round of drinks at PyCon!
That's over 400 people and counting:
http://www.python.org/pycon/2006/pycon-attendees.txt
Remember to run the tests *before* checkin. :-)
n
___
On Sat, 18 Feb 2006 10:44:15 +0100 (CET), "=?iso-8859-1?Q?Walter_D=F6rwald?="
<[EMAIL PROTECTED]> wrote:
>Guido van Rossum wrote:
>> On 2/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>>> Guido van Rossum wrote:
>>> > d =3D {}
>>> > d.default_factory =3D set
>>> > ...
>>> > d[key].add(value)
>>>
Bengt Richter wrote:
> My guess is that realistically default_factory will be used
> to make clean code for filling a dict, and then turning the factory
> off if it's to be passed into unknown contexts.
This suggests that maybe the autodict behaviour shouldn't
be part of the dict itself, but prov
[Greg Ewing]
> Would people perhaps feel better if defaultdict
> *wasn't* a subclass of dict, but a distinct mapping
> type of its own? That would make it clearer that it's
> not meant to be a drop-in replacement for a dict
> in arbitrary contexts.
Absolutely. That's the right way to avoid Liskov
Would people perhaps feel better if defaultdict
*wasn't* a subclass of dict, but a distinct mapping
type of its own? That would make it clearer that it's
not meant to be a drop-in replacement for a dict
in arbitrary contexts.
Greg
___
Python-Dev mailing
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Ron Adam <[EMAIL PROTECTED]> wrote:
> >> Josiah Carlson wrote:
> > [snip]
> >>> Again, the problem is ambiguity; what does bytes.recode(something) mean?
> >>> Are we encoding _to_ something, or are we decoding _from_ something?
> >>
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>> Josiah Carlson wrote:
> [snip]
>>> Again, the problem is ambiguity; what does bytes.recode(something) mean?
>>> Are we encoding _to_ something, or are we decoding _from_ something?
>> This was just an example of one way that might wor
At 01:44 PM 02/18/2006 -0500, James Y Knight wrote:
>On Feb 18, 2006, at 2:33 AM, Martin v. Löwis wrote:
> > I don't understand. In the rationale of PEP 333, it says
> > "The rationale for requiring a dictionary is to maximize portability
> > between servers. The alternative would be to define some
Martin v. Löwis wrote:
> Neal Norwitz wrote:
>
>>I suppose that might be nice, but would require configure magic. I'm
>>not sure how it could be done on Windows.
>
>
> Contributions are welcome. On Windows, it can be hard-coded.
>
> Actually, something like
>
> #if SIZEOF_SIZE_T == SIZEOF_INT
"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Again, the problem is ambiguity; what does bytes.recode(something) mean?
> Are we encoding _to_ something, or are we decoding _from_ something?
> Are we going to need to embed the direction in the encoding/decoding
>
On Sat, Feb 18, 2006 at 01:21:18PM +0100, M.-A. Lemburg wrote:
> It's by no means a Perl attitude.
In your eyes, perhaps. It certainly feels that way to me (or I wouldn't have
said it :). Perl happens to be full of general constructs that were added
because they were easy to add, or they were use
Aahz wrote:
> On Sat, Feb 18, 2006, Ron Adam wrote:
>> I like the bytes.recode() idea a lot. +1
>>
>> It seems to me it's a far more useful idea than encoding and decoding by
>> overloading and could do both and more. It has a lot of potential to be
>> an intermediate step for encoding as well a
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> If the __getattr__()-like operation that supplies and inserts a
> dynamic default was a separate method, we wouldn't have this problem.
Why implement it in the dictionary type at all? If, for intance, the
default value functionality were provided
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>> M.-A. Lemburg wrote:
>>> Walter Dörwald wrote:
[...]
> Perhaps we should also deprecate codecs.lookup() in Py 2.5 ?!
+1, but I'd like to have a replacement for this, i.e. a function that
returns all info the registry has about an e
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
[snip]
> > Again, the problem is ambiguity; what does bytes.recode(something) mean?
> > Are we encoding _to_ something, or are we decoding _from_ something?
>
> This was just an example of one way that might work, but here are my
> tho
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
True. However, note that the .encode()/.decode() methods on
strings and Unicode narrow down the possible return types.
The corresponding .bytes methods should only allow bytes and
Unicode.
>>> I forgot that: what is the rationale for
On 2/18/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2006, at 2:33 AM, Martin v. Löwis wrote:
> > Well, as you say: you get a KeyError if there is an error with the
> > key.
> > With a default_factory, there isn't normally an error with the key.
>
> But there should be. Consider the c
James Y Knight wrote:
> But there should be. Consider the case of two servers. One which takes
> all the items out of the dictionary (using items()) and puts them in
> some other data structure. Then it checks if the "Date" header has been
> set. It was not, so it adds it. Consider another simi
Alex Martelli wrote:
> On Feb 18, 2006, at 12:38 AM, Georg Brandl wrote:
>
>> Guido van Rossum wrote:
>>> WFM. Patch anyone?
>>
>> Done.
>> http://python.org/sf/1434038
>
> I reviewed the patch and added a comment on it, but since the point
> may be controversial I had better air it here for d
On Feb 18, 2006, at 2:33 AM, Martin v. Löwis wrote:
> I don't understand. In the rationale of PEP 333, it says
> "The rationale for requiring a dictionary is to maximize portability
> between servers. The alternative would be to define some subset of a
> dictionary's methods as being the standard a
M.-A. Lemburg wrote:
>>>True. However, note that the .encode()/.decode() methods on
>>>strings and Unicode narrow down the possible return types.
>>>The corresponding .bytes methods should only allow bytes and
>>>Unicode.
>>
>>I forgot that: what is the rationale for that restriction?
>
>
> To as
Talin wrote:
> [EMAIL PROTECTED] wrote:
>
>>talin> ... whereas with 'given' you can't be certain when to stop
>>talin> parsing the argument list.
>>
>> So require parens around the arglist:
>>
>>(x*y given (x, y))
>>
>> Skip
>>
>>
> I would not be opposed to mandating the parens, and
Walter Dörwald wrote:
> M.-A. Lemburg wrote:
>> Walter Dörwald wrote:
>> I'd suggest we keep codecs.lookup() the way it is and
>> instead add new functions to the codecs module, e.g.
>> codecs.getencoderobject() and codecs.getdecoderobject().
>>
>> Changing the codec registratio
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> I've already explained why we have .encode() and .decode()
>> methods on strings and Unicode many times. I've also
>> explained the misunderstanding that can codecs only do
>> Unicode-string conversions. And I've explained that
>> the .encode() and .
[EMAIL PROTECTED] wrote:
>talin> ... whereas with 'given' you can't be certain when to stop
>talin> parsing the argument list.
>
>So require parens around the arglist:
>
>(x*y given (x, y))
>
>Skip
>
>
I would not be opposed to mandating the parens, and its an easy enough
change to
Richard Tew wrote:
> If anyone on this list who is attending PyCon, has some time to spare
> during the sprint period and an interest in perhaps getting more
> familiar with Stackless, you would be more than welcome in joining us to
> help out. Familiarity with the Python source code and its worki
Michael Hudson wrote:
> There's one extremely significant example where the *value* of
> something impacts on the type of something else: functions. The types
> of everything involved in str([1]) and len([1]) are the same but the
> results are different. This shows up in PyPy's type annotation; m
M.-A. Lemburg wrote:
> I've already explained why we have .encode() and .decode()
> methods on strings and Unicode many times. I've also
> explained the misunderstanding that can codecs only do
> Unicode-string conversions. And I've explained that
> the .encode() and .decode() method *do* check the
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
> I'd suggest we keep codecs.lookup() the way it is and
> instead add new functions to the codecs module, e.g.
> codecs.getencoderobject() and codecs.getdecoderobject().
>
> Changing the codec registration is not much of a problem:
>>
Aahz wrote:
> On Sat, Feb 18, 2006, Ron Adam wrote:
>> I like the bytes.recode() idea a lot. +1
>>
>> It seems to me it's a far more useful idea than encoding and decoding by
>> overloading and could do both and more. It has a lot of potential to be
>> an intermediate step for encoding as well a
On Sat, Feb 18, 2006, Ron Adam wrote:
>
> I like the bytes.recode() idea a lot. +1
>
> It seems to me it's a far more useful idea than encoding and decoding by
> overloading and could do both and more. It has a lot of potential to be
> an intermediate step for encoding as well as being used for
On Feb 18, 2006, at 12:38 AM, Georg Brandl wrote:
> Guido van Rossum wrote:
>> WFM. Patch anyone?
>
> Done.
> http://python.org/sf/1434038
I reviewed the patch and added a comment on it, but since the point
may be controversial I had better air it here for discussion: in 2.4,
property(fset=
Hi,During the sprint period after PyCon, we are planning on sprinting to bring Stackless up to date and to make it more current and approachable. A key part of this is porting it and the recently completed 64 bit changes that have been made to it to the latest version of Python. At the end of the
talin> ... whereas with 'given' you can't be certain when to stop
talin> parsing the argument list.
So require parens around the arglist:
(x*y given (x, y))
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
Barry Warsaw wrote:
> On Wed, 2006-02-15 at 22:07 +0100, M.-A. Lemburg wrote:
>
>> Those are not pseudo-encodings, they are regular codecs.
>>
>> It's a common misunderstanding that codecs are only seen as serving
>> the purpose of converting between Unicode and strings.
>>
>> The codec system is
On 2/18/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Look at what we've currently got going for data transformations in the
> standard library to see what these removals will do: base64 module,
> binascii module, binhex module, uu module, ... Do we want or need to
> add another top-level module
Quoting [EMAIL PROTECTED]:
>
> Guido> Over lunch with Alex Martelli, he proposed that a subclass of
> Guido> dict with this behavior (but implemented in C) would be a good
> Guido> addition to the language.
>
> Instead, why not define setdefault() the way it should have been done in th
Thomas Wouters wrote:
> On Sat, Feb 18, 2006 at 12:06:37PM +0100, M.-A. Lemburg wrote:
>
>> I've already explained why we have .encode() and .decode()
>> methods on strings and Unicode many times. I've also
>> explained the misunderstanding that can codecs only do
>> Unicode-string conversions. An
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>> Josiah Carlson wrote:
>>> Bengt Richter had a good idea with bytes.recode() for strictly bytes
>>> transformations (and the equivalent for text), though it is ambiguous as
>>> to the direction; are we encoding or decoding with bytes.rec
This posting is entirely tangential. Be warned.
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> It's worse than that. The return *type* depends on the *value* of
> the argument. I think there is little precedence for that:
There's one extremely significant example where the *value* of
something
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> Just because some codecs don't fit into the string.decode()
>> or bytes.encode() scenario doesn't mean that these codecs are
>> useless or that the methods should be banned.
>
> No. The reason to ban string.decode and bytes.encode is that
> it confu
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> I'm torn. While trying to implement this I came across some ugliness
> in PyDict_GetItem() -- it would make sense if this also called
> on_missing(), but it must return a value without incrementing its
> refcount, and isn't supposed to raise excepti
On Sat, Feb 18, 2006 at 12:06:37PM +0100, M.-A. Lemburg wrote:
> I've already explained why we have .encode() and .decode()
> methods on strings and Unicode many times. I've also
> explained the misunderstanding that can codecs only do
> Unicode-string conversions. And I've explained that
> the .e
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> It's only me that's allowed to top-post. :-)
At least you include attributions these days!
Cheers,
mwh
--
SPIDER: 'Scuse me. [scuttles off]
ZAPHOD: One huge spider.
FORD: Polite though.
-- The Hitch-Hikers Guide to
Martin, v. Löwis wrote:
>> How are users confused?
>
> Users do
>
> py> "Martin v. Löwis".encode("utf-8")
> Traceback (most recent call last):
> File "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
> ordinal not in range(128)
>
> because they want to
Guido van Rossum wrote:
> On 2/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > d = {}
>> > d.default_factory = set
>> > ...
>> > d[key].add(value)
>>
>> Another option would be:
>>
>>d = {}
>>d.default_factory = set
>>d.get_default(key).add(value)
>>
>> Unl
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Bengt Richter had a good idea with bytes.recode() for strictly bytes
> > transformations (and the equivalent for text), though it is ambiguous as
> > to the direction; are we encoding or decoding with bytes.recode()? In
> > my opinio
Aahz wrote:
> The problem is that they don't understand that "Martin v. L?wis" is not
> Unicode -- once all strings are Unicode, this is guaranteed to work.
This specific call, yes. I don't think the problem will go away as long
as both encode and decode are available for both strings and byte
arr
Guido van Rossum wrote:
> WFM. Patch anyone?
Done.
http://python.org/sf/1434038
Georg
> On 2/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>> Alex Martelli wrote:
>> > Maybe we could fix that by having property(getfunc) use
>> > getfunc.__doc__ as the __doc__ of the resulting property object
>>
Josiah Carlson wrote:
> Bob Ippolito <[EMAIL PROTECTED]> wrote:
>>
>> On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
>>
>>> Greg Ewing <[EMAIL PROTECTED]> wrote:
Stephen J. Turnbull wrote:
>> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
> Guido> - b = bytes(t, en
Neal Norwitz wrote:
> I suppose that might be nice, but would require configure magic. I'm
> not sure how it could be done on Windows.
Contributions are welcome. On Windows, it can be hard-coded.
Actually, something like
#if SIZEOF_SIZE_T == SIZEOF_INT
#define PY_SSIZE_T_MAX INT_MAX
#elif SIZEO
Adam Olsen wrote:
> Demo/metaclass/Meta.py:55
That wouldn't break. If you had actually read the code, you would have
seen it is
try:
ga = dict['__getattr__']
except KeyError:
pass
How would it break if dict had a default factory? ga would get the
__getattr
70 matches
Mail list logo
