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
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
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, enc); t = text(b, enc)
+1 The coding
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
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 opinion, this is
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)
Unlike .setdefault, this would use
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 stdin, line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
ordinal not in range(128)
because they want to convert the
Guido van Rossum [EMAIL PROTECTED] writes:
It's only me that's allowed to top-post. :-)
At least you include attributions these days! wink
Cheers,
mwh
--
SPIDER: 'Scuse me. [scuttles off]
ZAPHOD: One huge spider.
FORD: Polite though.
-- The Hitch-Hikers Guide to
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
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 exceptions
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 confuses
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
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.recode()? In
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. And I've
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 the
first
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 for
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 deliberately
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
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
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,
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 many
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 as being
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:
we could simply allow
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
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; most
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 workings
[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 make. The
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 .decode()
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 registration is not much of a problem:
we
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 its an easy enough
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 assure that only
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 and
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 discussion: in
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 similar
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 case of two
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 that restriction?
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
thoughts on
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 encoding:
1. Name
2.
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 as a
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 as being
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
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
name
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
#define
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 subset
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 work, but here
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?
This was just an
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
[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
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
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)
Another option would be:
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
___
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
should be
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
be a
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 behaviour
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
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 as a
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 raise an
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
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 opposite
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
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 mean if
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 can
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 buildbot
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:
[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.
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
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 modifiable
[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 in
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
69 matches
Mail list logo
