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. The
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 _unico
>> 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 issues like:
* implications
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 l
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
> "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/sh
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
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 in
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 read-only. Alternatively, d.default c
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 eval
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
> Guido van Rossum wrote:
>
>> d = DefaultDict([])
>>
>> can be written as simply
>>
>> d[key].append(value)
>
>> Feedback?
>
Ok, setdefault is a horrible name. Would it make sense to come up with a
better name?
Georg Brandl wrote:
> Probably a good idea, has been proposed multiple time
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
>> someunicodestri
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,
Thomas Wouters wrote:
> 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
> "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):
Gui
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
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 *no
Thomas Wouters wrote:
> I'm seeing spurious test failures in test_timeout, on my own workstation and
> on macteagle.python.org (now that it crashes less; Apple sent over some new
> memory.) The problem is pretty simple: both macteagle and my workstation
> live too closely, network-wise, to www.pyth
"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__ special method (but
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
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 anoth
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 unicode.tr
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 w
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:
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
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
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
>
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 conside
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
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. ch
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 is
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 g
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 t
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, th
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 nam
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!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
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
http://mail.python.org/mailman/listinfo/python-
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 assign
> 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
>>
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 ei
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.
__
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
>>
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.
Walter Dörwald wrote:
> 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
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> 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 some
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 like this?
I'd say we l
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 unico
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 simp
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 m
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 t
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
Python-Dev@py
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(valu
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
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).
>> Switchin
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
Nick Coghlan wrote:
> Using Guido's original example:
>
> d.get(key, [], True).append(value)
hmm. are you sure you didn't just reinvent setdefault ?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
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 rea
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 ;)
[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
>
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
swampe
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
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
Walter Dörwald wrote:
> 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 cl
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] = []
d[key].appen
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 am
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.
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 hand
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 m
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 enc
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 hav
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 avo
"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
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
>
> T
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 de
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 va
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
>> 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) shoul
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 ever
On Fri, 17 Feb 2006 08:09:23 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> 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 defaul
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 defaultd
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 I'v
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 tha
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 g
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 possib
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
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
1 - 100 of 179 matches
Mail list logo
