Arkadiusz Miskiewicz wrote:
I wasn't, thanks for information.
Still few questions... one of developers/commiters reviews patch and commit
it? Few developers has to review single patch?
As Neal says, a single committer can review and commit. However,
non-committers can also review; this is
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido I think that the implementation of encoding-guessing or
Guido auto-encoding-upgrade techniques should be left out of the
Guido standard library design for now.
As far as I can see, little new design is needed. There's no
Josiah Carlson wrote:
I would agree that zip is questionable, but 'uu', 'rot13', perhaps 'hex',
and likely a few others that the two of you may be arguing against
should stay as encodings, because strictly speaking, they are defined as
encodings of data. They may not be encodings of _unicode_
John Marshall wrote:
Should I expect the virtual memory allocation
to go up if I do the following?
python-dev is a list for discussing development of Python,
not the development with Python. Please post this question
to [EMAIL PROTECTED]
For python-dev, a message explaining where the memory
Steve Holden wrote:
Thomas Wouters wrote:
I'm thinking that it could probably try to connect to a less reliable
website, but that's just moving the problem around (and possibly harassing
an unsuspecting website, particularly around release-time.) Perhaps the test
should try to connect to a
Bob == Bob Ippolito [EMAIL PROTECTED] writes:
Bob Huh? What does that have to do with anything? I've never
Bob seen a system where /usr/include, /usr/lib, /usr/bin,
Bob etc. are not all on the same mount. It's not really any
Bob different with OS X either.
/usr/share often is
On Feb 16, 2006, at 11:35 AM, Benji York wrote:
Alexander Schremmer wrote:
In fact, PHP does it like php.net/functionname which is even
shorter, i.e.
they fallback to the documentation if that path does not exist
otherwise.
Like many things PHP, that seems a bit too magical for my
Guido van Rossum wrote:
d = DefaultDict([])
can be written as simply
d[key].append(value)
Feedback?
Probably a good idea, has been proposed multiple times on clpy.
One good thing would be to be able to specify either a default value
or a factory function.
While at it, other
Hi,
Should I expect the virtual memory allocation
to go up if I do the following?
-
raw = open(data).read()
while True:
d = eval(raw)
-
I would have expected the memory allocated to the
object referenced by d to be deallocated, garbage
collected, and reallocated for the new
Guido van Rossum wrote:
A bunch of Googlers were discussing the best way of doing the
following (a common idiom when maintaining a dict of lists of values
relating to a key, sometimes called a multimap):
if key not in d: d[key] = []
d[key].append(value)
An alternative way to spell
On 2/15/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Actually users trying to figure out Unicode would probably be better served if bytes.encode() and text.decode() did not exist.[...]It would be better if the signature of text.encode() always returned a
bytes object. But why deny the bytes
On Feb 16, 2006, at 9:20 PM, Josiah Carlson wrote:
Greg Ewing [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
They may not be encodings of _unicode_ data,
But if they're not encodings of unicode data, what
business do they have being available through
someunicodestring.encode(...)?
I
Bob Ippolito wrote:
On Feb 16, 2006, at 11:35 AM, Benji York wrote:
Alexander Schremmer wrote:
In fact, PHP does it like php.net/functionname which is even
shorter, i.e.
they fallback to the documentation if that path does not exist
otherwise.
Like many things PHP, that seems a bit
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido I'd say there are two symmetric API flavors possible (t
Guido and b are text and bytes objects, respectively, where text
Guido is a string type, either str or unicode; enc is an encoding
Guido name):
Guido -
Bernhard Herzog wrote:
Travis E. Oliphant [EMAIL PROTECTED] writes:
2) The __index__ special method will have the signature
def __index__(self):
return obj
Where obj must be either an int or a long or another object
that has the __index__
Op wo, 15-02-2006 te 11:23 -0800, schreef Bob Ippolito:
On Feb 15, 2006, at 4:49 AM, Jan Claeys wrote:
Op wo, 15-02-2006 te 14:00 +1300, schreef Greg Ewing:
I'm disappointed that the various Linux distributions
still don't seem to have caught onto the very simple
idea of *not*
On 2/16/06, Paul Moore [EMAIL PROTECTED] wrote:
On 2/16/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 2/16/06, Nick Coghlan [EMAIL PROTECTED] wrote:
The PEP itself requests that a string be returned from get_data(), but
doesn't
require that the file be opened in text mode. Perhaps
Georg Brandl wrote:
Bernhard Herzog wrote:
Travis E. Oliphant [EMAIL PROTECTED] writes:
2) The __index__ special method will have the signature
def __index__(self):
return obj
Where obj must be either an int or a long or another object
that has
If str becomes unicode for PY 3000, and we then have bytes as out
coding-agnostic
byte data, then I think bytes should have the str translation method, with a
tweak
that I would hope could also be done to str now.
BTW, str.translate will presumably become unicode.translate, so
perhaps
Fredrik Lundh wrote:
Barry Warsaw wrote:
We know at least there will never be a 2.10, so I think we still have
time.
because there's no way to count to 10 if you only have one digit?
we used to think that back when the gas price was just below 10 SEK/L,
but they found a way...
IIRC
On Thu, 16 Feb 2006 13:11:49 -0800, Guido van Rossum [EMAIL PROTECTED] wrote:
A bunch of Googlers were discussing the best way of doing the
following (a common idiom when maintaining a dict of lists of values
relating to a key, sometimes called a multimap):
if key not in d: d[key] = []
[Moving to python-dev]
I don't have a strong opinion. Any one else have an opinion about
removing --with-wctype-functions from configure?
n
--
On 2/16/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
neal.norwitz wrote:
Author: neal.norwitz
Date: Thu Feb 16 06:25:37 2006
New Revision: 42396
Thomas Heller wrote:
Probably a good idea, has been proposed multiple times on clpy.
One good thing would be to be able to specify either a default value
or a factory function.
While at it, other interesting dict subclasses could be:
* sorteddict, practically reinvented by every larger
Guido van Rossum [EMAIL PROTECTED] writes:
OTOH, even if we didn't rename str/unicode to text, opentext would
still be a good name for the function that opens a text file.
Hnnrgh, not really. You're not opening a 'text', nor are you
constructing something that might reasonably be called an
Bengt Richter wrote:
On Wed, 15 Feb 2006 18:57:26 -0800, Guido van Rossum [EMAIL PROTECTED]
wrote:
[...]
My expectation is that the Py3k standard I/O library will do all of
its own conversions on top of binary files anyway -- if you missed it,
I'd like to get rid of any ties to C's
On 2/17/06, Raymond Hettinger [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
I would like to add something like this to the collections module,
+1
but a PEP is
Aahz wrote:
In all fairness to Tim (and despite the fact that emotionally I agree
with you), the fact is that there had been essentially no forward motion
on www.python.org redesign until he went to work. Even if we end up
chucking out all his work in favor of something else, I'll consider
Martin v. Lwis 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
Guido van Rossum wrote:
A bunch of Googlers were discussing the best way of doing the
following (a common idiom when maintaining a dict of lists of values
relating to a key, sometimes called a multimap):
if key not in d: d[key] = []
d[key].append(value)
/.../
Feedback?
+1. check it
On Thu, 16 Feb 2006 12:47:22 -0800, Guido van Rossum [EMAIL PROTECTED] wrote:
On 2/15/06, Neil Schemenauer [EMAIL PROTECTED] wrote:
This could be a replacement for PEP 332. At least I hope it can
serve to summarize the previous discussion and help focus on the
currently undecided issues.
On 2/15/06, Bengt Richter [EMAIL PROTECTED] wrote:
On Wed, 15 Feb 2006 18:57:26 -0800, Guido van Rossum [EMAIL PROTECTED]
wrote:
My expectation is that the Py3k standard I/O library will do all of
its own conversions on top of binary files anyway -- if you missed it,
I'd like to get rid of
On Wed, 15 Feb 2006 21:13:14 +0100, Georg Brandl wrote:
If something like Fredrik's new doc system is adopted, it would be extremely
convenient to refer someone to just
docs.python.org/os.path.join
In fact, PHP does it like php.net/functionname which is even shorter, i.e.
they fallback to
Alexander Schremmer wrote:
In fact, PHP does it like php.net/functionname which is even shorter, i.e.
they fallback to the documentation if that path does not exist otherwise.
Like many things PHP, that seems a bit too magical for my tastes.
--
Benji York
On 2/15/06, Neil Schemenauer [EMAIL PROTECTED] wrote:
This could be a replacement for PEP 332. At least I hope it can
serve to summarize the previous discussion and help focus on the
currently undecided issues.
I'm too tired to dig up the rules for assigning it a PEP number.
Also, there are
On Thu, Feb 16, 2006 at 01:11:49PM -0800, Guido van Rossum 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 builtin named
Michael Hudson wrote:
OTOH, even if we didn't rename str/unicode to text, opentext would
still be a good name for the function that opens a text file.
Hnnrgh, not really. You're not opening a 'text', nor are you
constructing something that might reasonably be called an 'opentext'.
Martin v. Löwis wrote:
Also, I think has_key/in should return True if there is a default.
and keys should return all possible key values!
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Hi,
as Jim Jewett noted, multifile is supplanted by email as much as mimify etc.
but it is not marked as deprecated. Should it be deprecated in 2.5?
Georg
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum wrote:
On 2/15/06, Neil Schemenauer [EMAIL PROTECTED] wrote:
This could be a replacement for PEP 332. At least I hope it can
serve to summarize the previous discussion and help focus on the
currently undecided issues.
I'm too tired to dig up the rules for assigning it a PEP
My conclusion is that setdefault() is a failure -- it was a
well-intentioned construct, but doesn't actually create more readable
code.
It was an across the board failure: naming, clarity, efficiency.
Can we agree to slate dict.setdefault() to disappear in Py3.0?
Raymond
Guido van Rossum wrote:
On 2/16/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
What will be the explicit way to open a file in bytes mode
and in text mode (I for one would like to move away from
open() completely as well) ?
Will we have a single file type with two different modes
or two
At 10:10 AM 02/17/2006 +0100, Georg Brandl wrote:
Guido van Rossum wrote:
d = DefaultDict([])
can be written as simply
d[key].append(value)
Feedback?
Probably a good idea, has been proposed multiple times on clpy.
One good thing would be to be able to specify either a default
Georg Brandl wrote:
as Jim Jewett noted, multifile is supplanted by email as much as mimify etc.
but it is not marked as deprecated. Should it be deprecated in 2.5?
-0.5 (gratuitous breakage).
I think the current see also/supersedes link is good enough.
/F
Guido van Rossum wrote:
On 2/16/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
What will be the explicit way to open a file in bytes mode
and in text mode (I for one would like to move away from
open() completely as well) ?
Will we have a single file type with two different modes
or two
Fredrik Lundh wrote:
Georg Brandl wrote:
as Jim Jewett noted, multifile is supplanted by email as much as mimify etc.
but it is not marked as deprecated. Should it be deprecated in 2.5?
-0.5 (gratuitous breakage).
I think the current see also/supersedes link is good enough.
Well, it
Bengt Richter wrote:
If str becomes unicode for PY 3000, and we then have bytes as out
coding-agnostic
byte data, then I think bytes should have the str translation method, with a
tweak
that I would hope could also be done to str now.
BTW, str.translate will presumably become
Fredrik Lundh wrote:
Raymond Hettinger wrote:
I would like to add something like this to the collections module, but a PEP
is
probably needed to deal with issues like:
frankly, now that Guido is working 50% on Python, do we really have to use
the full PEP process also for simple things
Martin v. Löwis wrote:
Josiah Carlson wrote:
I would agree that zip is questionable, but 'uu', 'rot13', perhaps 'hex',
and likely a few others that the two of you may be arguing against
should stay as encodings, because strictly speaking, they are defined as
encodings of data. They may not
Neal Norwitz wrote:
[Moving to python-dev]
I don't have a strong opinion. Any one else have an opinion about
removing --with-wctype-functions from configure?
FWIW, I announced this plan in Dec 2004:
http://mail.python.org/pipermail/python-dev/2004-December/050193.html
I didn't get any
Guido van Rossum wrote:
[Hey, I thought I sent that just to you. Is python-dev really
interested in this?]
Force of habit on my part - I saw the python-dev header and automatically
dropped pyd into the To: field of the reply.
Given Paul's contribution on the get_data front, it turned out to
Georg Brandl wrote:
Hi,
it has been proposed before, but there was no conclusive answer last time:
is there any chance for 2.5 to include commonly used decorators in a module?
No interest at all?
Georg
___
Python-Dev mailing list
On 2/16/06, Guido van Rossum [EMAIL PROTECTED] wrote:
A bunch of Googlers were discussing the best way of doing the
following (a common idiom when maintaining a dict of lists of values
relating to a key, sometimes called a multimap):
if key not in d: d[key] = []
d[key].append(value)
An
Phillip J. Eby wrote:
At 10:10 AM 02/17/2006 +0100, Georg Brandl wrote:
Guido van Rossum wrote:
d = DefaultDict([])
can be written as simply
d[key].append(value)
Feedback?
Probably a good idea, has been proposed multiple times on clpy.
One good thing would be to be able to specify
M.-A. Lemburg wrote:
Walter Dörwald wrote:
Guido van Rossum wrote:
[...]
Years ago I wrote a prototype; checkout sandbox/sio/.
However sio.DecodingInputFilter and sio.EncodingOutputFilter don't work
for encodings that need state (e.g. when reading/writing UTF-16).
Switching to stateful
Adam Olsen 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 builtin named defaultdict. The first, required, argument to the
Nick Coghlan wrote:
Using Guido's original example:
d.get(key, [], True).append(value)
hmm. are you sure you didn't just reinvent setdefault ?
/F
___
Python-Dev mailing list
Python-Dev@python.org
Walter Dörwald wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
Guido van Rossum wrote:
[...]
Years ago I wrote a prototype; checkout sandbox/sio/.
However sio.DecodingInputFilter and sio.EncodingOutputFilter don't work
for encodings that need state (e.g. when reading/writing UTF-16).
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 place? When you create a dict
Fredrik Lundh wrote:
Nick Coghlan wrote:
Using Guido's original example:
d.get(key, [], True).append(value)
hmm. are you sure you didn't just reinvent setdefault ?
I'm reasonably sure I copied it on purpose, only with a name that isn't 100%
misleading as to what it does ;)
I think
[EMAIL PROTECTED] wrote:
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 Thursday 16 February 2006 17:06, Martin v. Löwis wrote:
I'm still unhappy with that change, and still nobody has told me how to
maintain PyXML so that it can continue to work both for 2.5 and for 2.4.
Martin,
I do intend to write a proper response for you, but have been massively
M.-A. Lemburg wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
[...]
Like I suggested in the patch discussion, such functionality could
be factored out of the implementations of StreamReaders/Writers
and put into new StatefulEncoder/Decoder classes, the objects of
which then get used by
On Fri, 17 Feb 2006 00:43:50 -0500, Steve Holden [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
Barry Warsaw wrote:
We know at least there will never be a 2.10, so I think we still have
time.
because there's no way to count to 10 if you only have one digit?
we used to think that back
On Thu, Feb 16, 2006 at 01:11:49PM -0800, Guido van Rossum wrote:
[snip]
Google has an internal data type called a DefaultDict which gets
passed a default value upon construction. Its __getitem__ method,
instead of raising KeyError, inserts a shallow copy (!) of the given
default value into
Hi Travis,
On Tue, Feb 14, 2006 at 08:41:19PM -0700, Travis E. Oliphant wrote:
2) The __index__ special method will have the signature
def __index__(self):
return obj
Where obj must be either an int or a long or another object that has
the
+1It's about time!- COn 2/16/06, Guido van Rossum [EMAIL PROTECTED] wrote:
A bunch of Googlers were discussing the best way of doing thefollowing (a common idiom when maintaining a dict of lists of valuesrelating to a key, sometimes called a multimap):if key not in d: d[key] = []
Bengt Richter wrote:
because there's no way to count to 10 if you only have one digit?
we used to think that back when the gas price was just below 10 SEK/L,
but they found a way...
IIRC Guido is on record as saying There will be no Python 2.10 because
I hate the ambiguity of
On Fri, Feb 17, 2006 at 05:29:32PM +0100, Armin Rigo wrote:
Where obj must be either an int or a long or another object that has
the
__index__ special method (but not self).
The anything but not self rule is not consistent with any other
special method's behavior. IMHO we
M.-A. Lemburg wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
[...]
So maybe
codecs.lookup() should return an instance of a subclass of tuple which
has the StatefulEncoder/Decoder as attributes. But then codecs.lookup()
must be able to handle old 4-tuples returned
I'm writing a program in python that creates tar files of a certain maximum size (to fit onto CD/DVD). One of the problems I'm running into is that when using compression, it's pretty much impossible to
determine if a file, once added to an archive, will cause the archive size to exceed the
On Fri, 17 Feb 2006 00:33:49 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
[EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
I would agree that zip is questionable, but 'uu', 'rot13', perhaps 'hex',
and likely a few others that the two of you may be arguing against
should stay as encodings,
Hi,
On Tue, Feb 14, 2006 at 09:24:57PM -0800, Neal Norwitz wrote:
http://www.python.org/peps/pep-0356.html
There is at least one SF bug, namely #1333982 Bugs of the new AST
compiler, that in my humble opinion absolutely needs to be fixed before
the release, even though I won't hide that I have
Steve It appears to hang together, but I'm not sure I see how it
Steve overcomes objections to lambda by replacing it with another
Steve keyword.
Well, it does replace it with a word which has meaning in common English.
FWIW, I would require the parens around the arguments and avoid
Fredrik Lundh [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Raymond Hettinger wrote:
I would like to add something like this to the collections module, but a
PEP is
probably needed to deal with issues like:
frankly, now that Guido is working 50% on Python, do we really have
It is critical, but I hadn't seen the bug report. Feel free to assign
AST bugs to me and assign them a 5 priority.
Jeremy
On 2/17/06, Armin Rigo [EMAIL PROTECTED] wrote:
Hi,
On Tue, Feb 14, 2006 at 09:24:57PM -0800, Neal Norwitz wrote:
http://www.python.org/peps/pep-0356.html
There is
Actually, it might be easier to assign separate bugs. A number of the
old bugs appear to have been fixed. It's hard to track individual
items within a bug report.
Jeremy
On 2/17/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
It is critical, but I hadn't seen the bug report. Feel free to assign
Raymond Hettinger 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
I would like to add something like this to the collections module, but a PEP
is
probably needed to deal with
Terry Reedy wrote:
I'd say we let the BDFL roam free.
PEPs are useful for question-answering purposes even after approval. The
design phase can be cut short by simply posting the approved design doc.
not for trivialities. it'll take Guido more time to write a PEP than to
implement the
Also, I think has_key/in should return True if there is a default.
Fredrik and keys should return all possible key values!
I think keys() and in should reflect reality. Only when you do something
like
x = d['nonexistent']
or
x = d.get('nonexistent')
should the default
Georg Brandl wrote:
Hi,
it has been proposed before, but there was no conclusive answer last time:
is there any chance for 2.5 to include commonly used decorators in a module?
One peculiar aspect is that decorators are a programming technique, not
a particular kind of functionality. So the
it has been proposed before, but there was no conclusive answer last
time: is there any chance for 2.5 to include commonly used decorators
in a module?
Georg No interest at all?
I would think the decorators that allow proper introspection (func_name,
__doc__, etc) should be
Ian Bicking wrote:
Unfortunately, a @property decorator is impossible...
It already works! But only if you want a read-only property. Which is
actually about 50%+ of the properties I create. So the status quo is
not really that bad.
I have abused it this way too and felt bad every
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 builtin named defaultdict.
On Friday 17 February 2006 14:09, Guido van Rossum wrote:
So here's a new proposal.
I like the version you came up with. It has sufficient functionality to make
it easy to use, and enough flexibility to be useful in more specialized
cases. I'm quite certain it would handle all the cases
On 2/16/06, Guido van Rossum [EMAIL PROTECTED] wrote:
A bunch of Googlers were discussing the best way of doing the
...
Wow, what a great discussion! As you'll recall, I had also mentioned
the callable factory as a live possibility, and there seems to be a
strong sentiment in favor of that;
I really don't like that defaultdict (or a dict extension) means that
x[not_found] will have noticeable side effects. This all seems to be a
roundabout way to address one important use case of a dictionary with
multiple values for each key, and in the process breaking an important
quality of
On 2/17/06, Alex Martelli [EMAIL PROTECTED] wrote:
On 2/16/06, Guido van Rossum [EMAIL PROTECTED] wrote:
A bunch of Googlers were discussing the best way of doing the
...
Wow, what a great discussion! As you'll recall, I had also mentioned
the callable factory as a live possibility, and
On 2/17/06, Ian Bicking [EMAIL PROTECTED] wrote:
I really don't like that defaultdict (or a dict extension) means that
x[not_found] will have noticeable side effects. This all seems to be a
roundabout way to address one important use case of a dictionary with
multiple values for each key, and
On Friday 17 February 2006 14:51, Ian Bicking wrote:
This all seems to be a
roundabout way to address one important use case of a dictionary with
multiple values for each key,
I think there are use cases that do not involve multiple values per key. That
is one place where this commonly
Guido van Rossum wrote:
So here's a new proposal.
Let's add a generic missing-key handling method to the dict class, as
well as a default_factory slot initialized to None. The implementation
is like this (but in C):
def on_missing(self, key):
if self.default_factory is not None:
Please submit your patch to SourceForge.
On 2/17/06, Chris AtLee [EMAIL PROTECTED] wrote:
I'm writing a program in python that creates tar files of a certain
maximum size (to fit onto CD/DVD). One of the problems I'm running
into is that when using compression, it's pretty much impossible
[cc to py-dev again]
Guido van Rossum wrote:
On 2/17/06, Thomas Heller [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
So here's a new proposal.
Let's add a generic missing-key handling method to the dict class, as
well as a default_factory slot initialized to None. The implementation
is
On 2/17/06, Thomas Heller [EMAIL PROTECTED] wrote:
Ahem, I'm still looking for ways to 'overtake' the dict to implement
weird and fancy things. Can on_missing be overridden in subclasses (writing
the subclass in C would not be a problem)?
Why ahem?
The answer is yes.
--
--Guido van Rossum
On Fri, Feb 17, 2006 at 03:03:06PM -0500, Fred L. Drake, Jr. wrote:
On Friday 17 February 2006 14:51, Ian Bicking wrote:
and in the process breaking an important
quality of good Python code, that attribute and getitem access not have
noticeable side effects.
I'm not sure that's quite
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 users.
Regards,
Martin
Guido van Rossum wrote:
On 2/17/06, Ian Bicking [EMAIL PROTECTED] wrote:
I really don't like that defaultdict (or a dict extension) means that
x[not_found] will have noticeable side effects. This all seems to be a
roundabout way to address one important use case of a dictionary with
multiple
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 a factory associated with the
dictionary, and no default value would get passed in.
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 6-tuples to be passed into
On Fri, Feb 17, 2006, Guido van Rossum wrote:
But the default implementation is designed so that we can write
d = {}
d.default_factory = list
+1
I actually like the fact that you're forced to use a separate statement
for setting the default_factory. From my POV, this can go into 2.5.
(I
On 2/16/06, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
/usr/share often is on a different mount; that's the whole rationale
for /usr/share.
I don't think I've worked at a place where something like that was
done for at least 10 years. Isn't this argument outdated?
--
--Guido van Rossum (home
1 - 100 of 157 matches
Mail list logo
