Ian Bicking wrote:
> Well, here's a kind of an example: WSGI specifies that the environment
> must be a dictionary, and nothing but a dictionary. I think it would
> have to be updated to say that it must be a dictionary with
> default_factory not set, as default_factory would break the
> predictab
On Fri, 17 Feb 2006 20:33:16 -0800, Josiah Carlson <[EMAIL PROTECTED]> 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 cod
Guido van Rossum wrote:
> I'd much rather be able to write "if key in d" and get the result I want...
Somewhere else in this byzantine thread, I realised that what was really
bothering me was the conditional semantics that dict ended up with (i.e., it's
behaviour changed significantly if the def
On Fri, 17 Feb 2006, Phillip J. Eby wrote:
> > d = {} # or dict()
> > d.default_factory = list
>
> Why not a classmethod constructor:
>
> d = dict.with_factory(list)
>
> But I'd rather set the default and create the
> dictionary in one operation, since when reading it as two, you first
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 =
On 2/17/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>
> I'm very sorry for my silliness. I do see the problem I was having now.
>Thank you for helping me out. I was assuming that PY_SSIZE_T_MAX
> could be used in a pre-processor statement like LONG_MAX and INT_MAX.
>
> In other words
>
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 at least one SF bug, namely "#1333982 Bugs of the new AST
> compiler", that in my humble opinion absolutely needs to be
All right, the patch is up on SF. Sorry for the delay, I accidentally
left my powerbook about an hour's drive away from home, and had to drive
to go get it this morning :)
To those who were asking what advantage the new syntax has - well, from
a technical perspective there are none, since the u
On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> if key in d:
> dosomething(d[key])
> else:
> dosomethingelse()
>
> try:
> dosomething(d[key])
> except KeyError:
> dosomethingelse()
I agree with the gut feeling that these should still do the same
thing. Could we modify d.get() instead?
On Fri, Feb 17, 2006, "Martin v. L?wis" wrote:
> Josiah Carlson 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:
> o
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 conversion operation has al
On Sat, 18 Feb 2006 00:52:51 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>Adam Olsen wrote:
>> Consider these two pieces of code:
>>
>> if key in d:
>> dosomething(d[key])
>> else:
>> dosomethingelse()
>>
>> try:
>> dosomething(d[key])
>> except KeyError:
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 conversion operation has always felt like a constructor
> > to me, and in this parti
Tim Peters wrote:
> [Travis Oliphant]
>
>>Maybe I have the wrong version of code. In my pyport.h (checked out
>>from svn trunk) I have.
>>
>>#define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)>>1))
>>
>>What is size_t?
>
>
> size_t is an unsigned integral type defined by, required by, and used
>
On 2/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> And this is where the question of whether has_key/__having__ return True or
> False when default_factory is set is important. If they return False, then the
> LBYL (if key in d:) and EAFTP (try/except) approaches give *different
> answers*.
>
>
At 11:58 AM 02/17/2006 -0800, Guido van Rossum wrote:
>I forgot to mention in my revised proposal that the API for setting
>the default_factory is slightly odd:
>
> d = {} # or dict()
> d.default_factory = list
>
>rather than
>
> d = dict(default_factory=list)
>
>This is of course because w
Guido van Rossum wrote:
> But there were
> several suggestions that this would be fine functionality to add to
> the standard dict type -- and then I really don't see any other way to
> do this.
Given the constructor problem, and the issue with "this function expects a
plain dictionary", I think
Stephen J. Turnbull wrote:
>>"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
> Guido> - b = bytes(t, enc); t = text(b, enc)
>
> +1 The coding conversion operation has always felt like a constructor
> to me, and in this particular usage that's exactly what it is. I
> prefer the n
[Travis Oliphant]
> Maybe I have the wrong version of code. In my pyport.h (checked out
> from svn trunk) I have.
>
> #define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)>>1))
>
> What is size_t?
size_t is an unsigned integral type defined by, required by, and used
all over the place in standard C.
Adam Olsen wrote:
> And the pièce de résistance..
> Doc/tools/anno-api.py:51
>
> It has this:
> try:
> info = rcdict[s]
> except KeyError:
> sys.stderr.write("No refcount data for %s\n" % s)
> else:
> ...
> rcdict is loaded from refcounts.load(). refcounts.load
Martin v. Löwis wrote:
>>Another thought -- what is going to happen to os.open?
>>Will it change to return bytes, or will there be a new
>>os.openbytes?
>
> Nit-pickingly: os.open will continue to return integers.
Sorry, what I meant was will os.read return bytes.
Greg
_
Thomas Wouters wrote:
> On Fri, Feb 17, 2006 at 04:40:08PM -0700, Travis Oliphant wrote:
>
>
>>What is PY_SSIZE_T_MAX supposed to be? The definition in pyport.h
>>doesn't compile.
>
Maybe I have the wrong version of code. In my pyport.h (checked out
from svn trunk) I have.
#define PY_SSIZE_
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > You could pass a float in as well. But if the function is documented
> > as taking a dict, and the programmer expects a dict.. that now has to
> > be changed to "dict without a default". Or they have to code
> > defe
On Feb 17, 2006, at 4:20 PM, Martin v. Löwis wrote:
> Ian Bicking wrote:
>> Maybe it isn't worse, but the real alternative is:
>>
>> import zlib
>> import base64
>>
>> base64.b64encode(zlib.compress(s))
>>
>> Encodings cover up eclectic interfaces, where those interfaces fit a
>> basic patt
On Fri, Feb 17, 2006 at 04:40:08PM -0700, Travis Oliphant wrote:
> What is PY_SSIZE_T_MAX supposed to be? The definition in pyport.h
> doesn't compile.
Why not? Does it give an error for your particular platform? What platform
is that? What are HAVE_SSIZE_T, SIZEOF_VOID_P and SIZEOF_SIZE_T defi
Martin v. Löwis wrote:
>>Maybe it isn't worse, but the real alternative is:
>>
>> import zlib
>> import base64
>>
>> base64.b64encode(zlib.compress(s))
>>
>>Encodings cover up eclectic interfaces, where those interfaces fit a
>>basic pattern -- data in, data out.
>
>
> So should I write
>
> 3
Martin v. Löwis wrote:
> Adam Olsen wrote:
>
>>Consider these two pieces of code:
>>
>>if key in d:
>> dosomething(d[key])
>>else:
>> dosomethingelse()
>>
>>try:
>> dosomething(d[key])
>>except KeyError:
>> dosomethingelse()
>>
>>Before they were the same (assuming dosomething() won't raise
>>
WFM. Patch anyone?
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
> > (easily overridable in more normal property usage by the doc=
> > argumen
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> That's why I think has_key and in should return True for any key.
> This leaves keys(), items(), and values(). From a pure point of
> view, they should return infinite sets. Practicality beats purity,
> so yes, d[k] could be considered a mo
Ian Bicking wrote:
> Maybe it isn't worse, but the real alternative is:
>
> import zlib
> import base64
>
> base64.b64encode(zlib.compress(s))
>
> Encodings cover up eclectic interfaces, where those interfaces fit a
> basic pattern -- data in, data out.
So should I write
3.1415.encode("s
Ian Bicking wrote:
> It is lazily incarnated for multidict, because there is no *noticeable*
> side effect -- if there is any internal side effects that is an
> implementation detail. However for default_factory=list, the result of
> .keys(), .has_key(), and .items() changes when you do d[some_key
Alex Martelli wrote:
> Maybe we could fix that by having property(getfunc) use
> getfunc.__doc__ as the __doc__ of the resulting property object
> (easily overridable in more normal property usage by the doc=
> argument, which, I feel, should almost invariably be there).
+1
--
Ian Bicking / [E
Martin v. Löwis wrote:
> Ian Bicking wrote:
>
>>That str.encode(unicode_encoding) implicitly decodes strings seems like
>>a flaw in the unicode encodings, quite seperate from the existance of
>>str.encode. I for one really like s.encode('zlib').encode('base64') --
>>and if the zlib encoding raise
It's only me that's allowed to top-post. :-)
On 2/17/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> Is that a record? ;-)
>
> BTW, does python-dev have different expectations re top-posting?
> I've seen more here than on c.l.p I think, so I'm wondering what to do.
>
> When-in-Rome'ly,
>
> Regards,
On 2/17/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> 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 rea
Is that a record? ;-)
BTW, does python-dev have different expectations re top-posting?
I've seen more here than on c.l.p I think, so I'm wondering what to do.
When-in-Rome'ly,
Regards,
Bengt Richter
On Fri, 17 Feb 2006 14:17:41 -0800, "Guido van Rossum" <[EMAIL PROTECTED]>
wrote:
>Cut to the
Josiah Carlson wrote:
>>>If some users
>>>can't understand this (passing different arguments to a function may
>>>produce different output),
>>
>>It's worse than that. The return *type* depends on the *value* of
>>the argument. I think there is little precedence for that: normally,
>>the return val
Ian Bicking wrote:
> That str.encode(unicode_encoding) implicitly decodes strings seems like
> a flaw in the unicode encodings, quite seperate from the existance of
> str.encode. I for one really like s.encode('zlib').encode('base64') --
> and if the zlib encoding raised an error when it was passe
Adam Olsen wrote:
> Consider these two pieces of code:
>
> if key in d:
> dosomething(d[key])
> else:
> dosomethingelse()
>
> try:
> dosomething(d[key])
> except KeyError:
> dosomethingelse()
>
> Before they were the same (assuming dosomething() won't raise
> KeyError). Now they would b
Martin v. Löwis wrote:
> Just in case you haven't noticed, I just merged
> the ssize_t branch (PEP 353).
>
> If you have any corrections to the code to make which
> you would consider bug fixes, just go ahead.
>
> If you are uncertain how specific problems should be resolved,
> feel free to ask.
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson 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:
> o
Martin v. Löwis writes:
> You are missing the rationale of the PEP process. The point is
> *not* documentation. The point of the PEP process is to channel
> and collect discussion, so that the BDFL can make a decision.
> The BDFL is not bound at all to the PEP process.
>
> To document things, we us
Thomas Wouters wrote:
> 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
On Fri, 17 Feb 2006 14:58:34 -0800, "Guido van Rossum" <[EMAIL PROTECTED]>
wrote:
>On 2/17/06, "Martin v. L=F6wis" <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > On 2/16/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
>> >>/usr/share often is on a different mount; that's the whole
Adam Olsen wrote:
> The latter is even the prefered form, since it only invokes a single
> dict lookup:
>
> On 2/16/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
>
>>try:
>>v = d[key]
>>except:
>>v = d[key] = value
>
>
> Obviously this example could be changed to
Martin v. Löwis wrote:
>>I know *I* at least don't like code that mixes up access and
>>modification. Maybe not everyone does (or maybe not everyone thinks of
>>getitem as "access", but that's unlikely). I will assert that it is
>>Pythonic to keep access and modification separate, which is why
Martin v. Löwis wrote:
> 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 convert the string "to Unicode
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> 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
> >
Adam Olsen wrote:
> You could pass a float in as well. But if the function is documented
> as taking a dict, and the programmer expects a dict.. that now has to
> be changed to "dict without a default". Or they have to code
> defensively since d[key] may or may not raise KeyError, so they must
>
Ian Bicking wrote:
> I know *I* at least don't like code that mixes up access and
> modification. Maybe not everyone does (or maybe not everyone thinks of
> getitem as "access", but that's unlikely). I will assert that it is
> Pythonic to keep access and modification separate, which is why met
On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Such are the joys of writing polymorphic code. I don't really see how
> > you can avoid this kind of confusion -- I could have given you some
> > other mapping object that does weird stuff.
>
> You could pass a float in as well. But if the func
On 2/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > 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
On 2/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > It's also makes it harder to read code. You may expect d[key] to
> > raise an exception, but it won't because of a single line up several
> > pages (or in another file entierly!)
>
> Suc
Josiah Carlson 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 convert the string "to
Guido van Rossum wrote:
> 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 -- so what to do if
Guido van Rossum wrote:
> On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
>>It's also makes it harder to read code. You may expect d[key] to
>>raise an exception, but it won't because of a single line up several
>>pages (or in another file entierly!)
>
>
> Such are the joys of writing polym
On Fri, 17 Feb 2006 21:35:25 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> 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
Guido van Rossum wrote:
> 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 argume
Cut to the chase: -1000.
On 2/17/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> Cut to the chase: how about being able to write
>
> baz(bar(foo(x, y)),z)
>
> serially as
>
> foo(x, y) -> bar() -> baz(z)
>
> via the above as sugar for
>
> baz.__get__(bar.__get__(foo(x, y))())(z)
>
> ?
"Martin v. Löwis" <[EMAIL PROTECTED]> 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
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 a facto
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 exception (and catches
Bengt Richter wrote:
> Cut to the chase: how about being able to write
>
> baz(bar(foo(x, y)),z)
>
> serially as
>
> foo(x, y) -> bar() -> baz(z)
>
> via the above as sugar for
>
> baz.__get__(bar.__get__(foo(x, y))())(z)
Reminds me of
http://dev.perl.org/perl6/doc/design/syn/S03.
On 2/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> It's also makes it harder to read code. You may expect d[key] to
> raise an exception, but it won't because of a single line up several
> pages (or in another file entierly!)
Such are the joys of writing polymorphic code. I don't really see how
Fuzzyman wrote:
>>Also, I think has_key/in should return True if there is a default.
>>
>>
>>
> And exactly what use would it then be ?
Code that checks
if d.has_key(k):
print d[k]
would work correctly. IOW, you could use a dictionary with a default
key just as if it were a normal dictionary
Cut to the chase: how about being able to write
baz(bar(foo(x, y)),z)
serially as
foo(x, y) -> bar() -> baz(z)
via the above as sugar for
baz.__get__(bar.__get__(foo(x, y))())(z)
?
I.e., you'd have self-like args to receive results from upstream. E.g.,
>>> def foo(x, y): return
On 2/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - There's a fundamental difference between associating the default
> value with the dict object, and associating it with the call. So
> proposals to invent a better name/signature for setdefault() don't
> compete.
That's a feature, not a bu
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 (h
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.
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-t
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
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
>
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, 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?
>
> Th
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
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 Ross
[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 imp
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 impossib
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:
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
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 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
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/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
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:
> 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 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
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
>> 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
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
>> 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
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
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
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
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
"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
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
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
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
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
1 - 100 of 179 matches
Mail list logo
