On 2005 Jan 06, at 20:16, Terry Reedy wrote:
James Y Knight [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Please notice that I'm talking about concrete, real issues, not just a
super is bad! rant.
Umm, James, come on. Let's be really real and concrete ;-).
Your title Python's Super
On 2005 Jan 07, at 14:45, Michael Chermside wrote:
Andrew explains that in the CSV module, escape characters are not
properly removed.
Magnus writes:
IMO this is the *only* reasonable behaviour. I don't understand why
the escape character should be left in; this is one of the reason why
UNIX-style
: Object Adaptation
Version: $Revision: 1.6 $
Author: [EMAIL PROTECTED] (Alex Martelli),
[EMAIL PROTECTED] (Clark C. Evans)
Status: Draft
Type: Standards Track
Created: 21-Mar-2001
Python-Version: 2.5
Post-History: 29-Mar-2001, 10-Jan-2005
Abstract
This proposal puts forth an extensible
On 2005 Jan 10, at 18:43, Phillip J. Eby wrote:
...
At 03:42 PM 1/10/05 +0100, Alex Martelli wrote:
The fourth case above is subtle. A break of substitutability can
occur when a subclass changes a method's signature, or restricts
the domains accepted for a method's argument (co
On 2005 Jan 11, at 11:01, Alex Martelli wrote:
On 2005 Jan 10, at 18:59, Phillip J. Eby wrote:
At 12:43 PM 1/10/05 -0500, Phillip J. Eby wrote:
As a practical matter, all of the existing interface systems (Zope,
PyProtocols, and even the defunct Twisted implementation) treat
interface
On 2005 Jan 11, at 16:34, Phillip J. Eby wrote:
...
Anyway, I agree that your version of the code should be used to form
the reference implementation, since the purpose of the reference
implementation is to show the complete required semantics.
Great, one point at last on which we fully agree
On 2005 Jan 11, at 23:20, Fredrik Lundh wrote:
back in Python 2.1 (and before), an object could define how copy.copy
should
work simply by definining a __copy__ method. here's the relevant
portion:
...
try:
copierfunction = _copy_dispatch[type(x)]
except KeyError:
On 2005 Jan 11, at 22:08, Phillip J. Eby wrote:
...
Yes, you're ALLOWED to stuff with NULL any field that isn't
explicitly specified as NOT NULL.
But you should ONLY do so when the information is REALLY missing, NOT
when you've lost it along the way because you've implemented
adapter-chain
Since this bug isn't the cause of Fredrik's problem I'm changing the
subject (and keep discussing the specific problem that Fredrik
uncovered under the original subject).
On 2005 Jan 12, at 05:11, Guido van Rossum wrote:
...
I had exactly the same metabug in the pep 246 reference
On 2005 Jan 12, at 00:30, Fredrik Lundh wrote:
Guido van Rossum wrote:
The only thing this intends to break /.../
it breaks classic C types:
True!!! And it only breaks copy, NOT deepcopy, because of the
following difference between the two functions in copy.py...:
def deepcopy(x, memo=None,
On 2005 Jan 12, at 14:44, Paul Moore wrote:
On Wed, 12 Jan 2005 00:33:22 +0100, Alex Martelli [EMAIL PROTECTED]
wrote:
But adaptation is not transmission! It's PERFECTLY acceptable for an
adapter to facade: to show LESS information in the adapted object than
was in the original. It's PERFECTLY
On 2005 Jan 12, at 16:12, Phillip J. Eby wrote:
At 02:27 PM 1/12/05 +, Mark Russell wrote:
I strongly prefer *not* to have A-B and B-C automatically used to
construct A-C. Explicit is better than implicit, if in doubt don't
guess, etc etc.
So I'd support:
- As a first cut, no automatic
On 2005 Jan 12, at 16:26, Guido van Rossum wrote:
...
[Alex]
I'm saying that if, by mistake, the programmer has NOT
registered the A-C adapter (which would be easily coded and work
perfectly), then thanks to transitivity, instead of a clear and simple
error message leading to immediate
On 2005 Jan 12, at 16:44, Thomas Heller wrote:
...
conform = getattr(type(obj), '__conform__', None)
...
I'm confused. Do you mean that
getattr(obj, somemethod)(...)
does something different than
obj.somemethod(...)
with new style class instances? Doesn't getattr search the
On 2005 Jan 12, at 17:40, Phillip J. Eby wrote:
At 04:36 PM 1/12/05 +0100, Alex Martelli wrote:
I already know -- you told us so -- that if I had transitivity as you
wish it (uncontrollable, unstoppable, always-on) I could not any more
write and register a perfectly reasonable adapter which
On 2005 Jan 12, at 18:58, Phillip J. Eby wrote:
...
I have some data about people coming in from LDAP and the like, which
I want to record in that SQL DB -- the incoming data is held in types
that implement IPerson, so I write an adapter IPerson - IFullname
for the purpose.
This doesn't
On 2005 Jan 12, at 19:16, Guido van Rossum wrote:
...
[Alex]
Hm?
I meant if there were multiple A's. For every Ai that has an Ai-B you
would also have to register a trivial Ai-C. And if there were
multiple C's (B-C1, B-C2, ...) then the number of extra adaptors to
register would be the number
On 2005 Jan 12, at 20:39, Phillip J. Eby wrote:
...
it's difficult because intuitively an interface defines a
*requirement*, so
it seems logical to inherit from an interface in order to add
requirements!
Yes... I would fall into this trap as well until I'd been burned a
few times.
It's
On 2005 Jan 12, at 20:51, Phillip J. Eby wrote:
...
There's a very simple reason. If one is using only non-noisy
adapters, there is absolutely no reason to ever define more than one
adapter between the *same* two points. If you do,
...but there's no harm whatsoever done, either. If I have
On 2005 Jan 12, at 21:42, Phillip J. Eby wrote:
...
Anyway, hopefully this post and the other one will be convincing that
considering ambiguity to be an error *reinforces* the idea of I-to-I
perfection, rather than undermining it. (After all, if you've written
a perfect one, and there's
On 2005 Jan 14, at 04:08, David Ascher wrote:
Alex Martelli wrote:
Yes, there is (lato sensu) non-determinism involved, just like in,
say:
for k in d:
print k
Wow, it took more than the average amount of googling to figure out
that lato sensu means broadly speaking,
Ooops -- sorry; I
On 2005 Jan 14, at 10:36, Skip Montanaro wrote:
Brett The problem I have always had with this proposal is that the
Brett value is worthless, time tuples do not have a slot for
fractional
Brett seconds. Yes, it could possibly be changed to return a
float for
Brett seconds, but
On 2005 Jan 14, at 19:11, Aahz wrote:
On Fri, Jan 14, 2005, Brett C. wrote:
Right, it's a struct_time object; just force of habit to call it a
time
tuple.
And I technically don't see why a fractional second attribute could
not be
added that is not represented in the tuple. But I personally
On 2005 Jan 14, at 20:25, Clark C. Evans wrote:
| Does anyone know of any other languages that take this operational
| aproach to solving the substitutability problem?
Microsoft's COM?
I don't see the parallel: COM (QueryInterface) is strictly
by-interface, not by-method, and has many other
On 2005 Jan 15, at 02:30, Phillip J. Eby wrote:
is requested. It's too bad Python doesn't have some sort of
deallocation hook you could use to get notified when an object goes
away. Oh well.
For weakly referenceable objects, it does. Giving one to other objects
would be almost isomorphic to
On 2005 Jan 16, at 03:17, Phillip J. Eby wrote:
...
Uh oh. I just used view to describe an iterator as a view on an
iterable, as distinct from an adapter that adapts a sequence so that
it's iterable. :)
I.e., using view in the MVC sense where a given Model might have
multiple independent
copy.py, as recently discussed starting from a post by /F, has two
kinds of misbehaviors since 2.3 (possibly 2.2, haven't checked), both
connected to instance/type/metatype confusion (where do special methods
come from? in classic classes and types, from the instance, which may
delegate to the
On 2005 Jan 16, at 10:27, Martin v. Löwis wrote:
Simon Percivall wrote:
What would happen if Exception were made a new-style class, enforce
inheritance from Exception for all new-style exceptions, and allow all
old-style exceptions as before.
string exceptions would break.
Couldn't we just
On 2005 Jan 16, at 11:17, Raymond Hettinger wrote:
[Alex]
So, as per discussion here, I have prepared a patch (to the
maintenance
branch of 2.3, to start with) which adds unit tests to highlight these
issues, and fixes them in copy.py. This patch should go in the
maintenance of 2.3 and 2.4, but
On 2005 Jan 16, at 12:03, Fredrik Lundh wrote:
Alex Martelli wrote:
Problem: to write unit tests showing that the current copy.py
misbehaves with a classic extension
type, I need a classic extension type which defines __copy__ and
__deepcopy__ just like /F's
cElementTree does. So, I made one
On 2005 Jan 19, at 11:10, Bob Ippolito wrote:
Do you REALLY think this should be True?!
isinstance(foo, unicode) and foo != unicode(foo)
H -- why not? In the generic case, talking about some class B, it
certainly violates no programming principle known to me that
isinstance(foo, B) and
On 2005 Jan 20, at 02:47, Skip Montanaro wrote:
Phillip Actually, this is one of those rare cases where
optimization
Phillip and clarity go hand in hand. Human brains just don't
handle
Phillip nesting that well. It's easy to visualize two levels of
nested
Phillip structure,
On 2005 Jan 21, at 14:02, Nick Coghlan wrote:
Phillip's monkey-typing PEP (and his goal of making it easy to write
well behaved adapters) got me wondering about the benefits of
providing an adaptation. Adapter class that could be used to reduce
the boiler plate required when developing new
On 2005 Feb 05, at 07:43, Anthony Baxter wrote:
Ok, so here's the state of play: 2.3.5 is currently aimed for next
Tuesday,
but there's an outstanding issue - the new copy code appears to have
broken something, see www.python.org/sf/1114776 for the gory details.
I'm completely out of time this
On 2005 Feb 05, at 16:49, Jeremy Hylton wrote:
On Sat, 5 Feb 2005 02:31:26 -0500, Raymond Hettinger [EMAIL PROTECTED]
wrote:
[Anthony]
While this is undoubtedly a bug fix, I'm not sure that it should be
backported - it will break people's code that is working now
(albeit
in a faulty way). What
On 2005 Feb 19, at 06:03, Nick Coghlan wrote:
This is something I've typed way too many times:
Py class C():
File stdin, line 1
class C():
^
SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a
function with no arguments still requires
On 2005 Feb 20, at 04:35, Jack Diederich wrote:
I always use new style classes so I only have to remember one set of
behaviors.
I agree: that's reason #1 I recommend always using new-style whenever I
teach / tutor / mentor in Python nowadays.
__metaclass__ = type is warty, it has the action at
On 2005 Feb 20, at 05:20, Raymond Hettinger wrote:
...
This sort of thing is easy to test for and easy to fix. The question
is
whether we care about updating this module anymore or is it a relic.
Also, is the use case one that we care about. AFAICT, this has never
come up before.
I did have
On Mar 11, 2005, at 17:28, Guido van Rossum wrote:
PS in the blog responses, a problem with sum() was pointed out --
unless you use the second argument, it will only work for numbers. Now
Why is that a *problem*? It solves the end case (if the sequence is
empty which you mention for any() and
On Mar 11, 2005, at 18:18, Raymond Hettinger wrote:
str.join() is still the best practice for string concatenation.
...except you actually need unicode.join if the strings are of that
kind. Fortunately, ''.join intrinsically compensates:
x=[u'\u0fe0']*2
''.join(x)
u'\u0fe0\u0fe0'
*without*
On Mar 11, 2005, at 19:39, Raymond Hettinger wrote:
[Alex]
If you're considering revisions to sum's design, my suggestion would
be
to find a way to let the user tell sum to use a more accurate approach
when summing floats.
FWIW, when accuracy is an issue, I use:
sum(sorted(data, key=abs))
On Mar 14, 2005, at 11:20, Nick Coghlan wrote:
...
Somewhat ugly, but backwards compatible:
I realize you're mostly talking semantics, not implementation, but, as
long as we're at it, could we pretty please have back the optimization
indicated by...:
# Add the elements
if
On Mar 15, 2005, at 01:16, Tim Peters wrote:
[Eric Nieuwland]
Perhaps the second argument should not be optional to emphasise this.
After all, there's much more to sum() than numbers.
[Greg Ewing]
I think practicality beats purity here. Using it on
numbers is surely an extremely common case.
I'd
On Mar 29, 2005, at 17:41, Terry Reedy wrote:
...
Steve Holden [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Having to write
[x for x in seq]
to produce a copy of a list doesn't seem that outrageous to me,
Except for (currently) leaving the last value of sequence bound to 'x'
On Apr 7, 2005, at 07:58, Raymond Hettinger wrote:
Does anyone know what has become of the following developers and
perhaps
have their current email addresses? Are any of these folks still
active
in Python development?
Ben Gertzfield
Charles G Waldman
Eric Price
Finn Bock
Ken
On Apr 10, 2005, at 13:44, Skip Montanaro wrote:
Michael I suppose one could jsut do it unconditionally and wait
for one
Michael of the three remaining VAX users[2] to compile Python 2.5
and
Michael then notice.
You forgot the two remaining CRAY users. Since their machines are so
On Apr 22, 2005, at 16:51, holger krekel wrote:
Moreover, i think that there are more than the transactional
use cases mentioned in the PEP. For example, a handler
may want to log exceptions to some tracing utility
or it may want to swallow certain exceptions when
its block does IO operations
On Apr 30, 2005, at 08:34, Raymond Hettinger wrote:
I haven't heard back from Greg Stein, Jim Fulton, or Paul Prescod.
If anyone can get in touch with them, that would be great.
I suspect that Jim may want to keep the commit privileges active
and that Paul and Greg are done with commits for the
On May 4, 2005, at 01:57, Paul Moore wrote:
tried to construct a plausible example, I couldn't find a case which
made real-life sense. For example, with Nicolas' original example:
for name in filenames:
opening(name) as f:
if condition: break
I can't think of a
On May 9, 2005, at 21:58, Guido van Rossum wrote:
Apologies if this has been discovered and rejected already; I've had
to skip most of the discussions but this though won't leave my head...
Skimming rather than skipping all of the discussion burned most of my
py-dev time, and it was just
On 11/4/05, Eyal Lotem [EMAIL PROTECTED] wrote:
I have a few claims, some unrelated, and some built on top of each
other. I would like to hear your responses as to which are
convincing, which arne't, and why. I think that if these claims are
true, Python 3000 should change quite a bit.
A.
On Nov 17, 2005, at 5:00 PM, Thomas Lee wrote:
Portability may also be an issue to take into consideration:
Of course -- but so is anno domini... the eskimo.com FAQ is (C) 1995,
and the neohapsis.com page just points to the eskimo.com one:
http://www.eskimo.com/~scs/C-faq/q7.32.html
On 12/12/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 02:25 PM 12/12/2005 -0600, Ian Bicking wrote:
That looks good to me. Well, I actually try not to use cls as the first
argument to metaclass's __new__ method, because there's so many classes
being tossed about at that point that I try to
On 12/12/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
...
I'd rather see 'metaclass' fully spelled out than resort to 'mcl';
metaclass code is tricky enough to write without figuring out
abbreviations. :)
Indeed, the only reason I use 'cls' is because it was Pronounced the
standard;
On 12/14/05, Chris Lambacher [EMAIL PROTECTED] wrote:
Py2exe manages to load .pyd files and dlls from zip. Apparently they have
written an alternate dll loader that does not need the file to be on the file
system. This is used for single file apps.
I don't know if it is possible to write a
On Dec 27, 2005, at 12:45 PM, Valentino Volonghi aka Dialtone wrote:
...
any(iterable, test=bool) and all(iterable, test=bool)
...
any(some_objects, test=operator.attrgetter('some_attribute'))
Why would that be better than
any(o.some_attribute for o in some_objects)
?
def zerop(x):
On Dec 27, 2005, at 11:06 PM, Eric Nieuwland wrote:
...
def zerop(x):
return x==0
all(some_objects, zerop)
and why would that be better than
all(o==0 for o in some_objects)
?
all() can be terminated at the first false element. For very long
sequences this has important
On Dec 28, 2005, at 2:57 AM, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Since I routinely use 2-item tuples (twoples?)
I've been using pairs to describe that datatype. Not sure
how common it is in English, but in German, Zweitupel
is often called Paar.
I use 'pair', too, admittedly by
On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote:
[EMAIL PROTECTED] writes:
Fredrik a quit/exit command that actually quits, instead of
printing a
Fredrik you didn't say please! message.
I like Fredrik's idea more and more.
The thing that bothers me about it is that the
On 12/28/05, Walter Dörwald [EMAIL PROTECTED] wrote:
...
We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook?
Sure, particularly with Nick's suggestion for a default input hook it
would be fine.
sessions in which I want to perform some action repeatedly, and
currently
For the last 2+ years I've been occasionally arguing for the
introduction of a basenumber (and ideally a baseinteger, but that, to
me, is a slightly lesser issue) analogous to basestring. Google
search fo [basenumber site:python.org] for several messages on the
subject, by me and others;
On Jan 16, 2006, at 7:53 AM, Guido van Rossum wrote:
On 1/15/06, Alex Martelli [EMAIL PROTECTED] wrote:
Now, today, I have _again_ been bit by the lack of basenumber (by a
bug of mine, fixed by adding decimal.Decimal to a long tuple of
classes to be passed to an isinstance call -- I hadn't
On Jan 16, 2006, at 2:01 PM, Martin v. Löwis wrote:
Alex Martelli wrote:
I can't find a PEP describing this restriction of basestring, and I
don't see why a coder who needs to implement another kind of
character string shouldn't subclass basestring, so that those
instances pass
Is it finally time in Python 2.5 to allow the obvious use of, say,
str(5,2) to give '101', just the converse of the way int('101',1)
gives 5? I'm not sure why str has never allowed this obvious use --
any bright beginner assumes it's there and it's awkward to explain
why it's not!-).
On Jan 16, 2006, at 8:03 PM, Jeremy Hylton wrote:
It never occured to me that str() would behave like int() for this
case. It makes complete sense to me that a factory for numbers would
ask about the base of the number. What would the base of a string be,
except in a few limited cases?
On 1/16/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 1/16/06, Alex Martelli [EMAIL PROTECTED] wrote:
Is it finally time in Python 2.5 to allow the obvious use of, say,
str(5,2) to give '101', just the converse of the way int('101',1)
[I'm sure you meant int('101', 2) here]
Yep.
gives
On 1/17/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Alex, I think you're missing a point here: what you are looking
for is an interface, not a base class - simply because the
I expect numbers to support arithmetic operators, c -- no need for
basenumber to spell this out, i.e., be an itnerface.
On Jan 18, 2006, at 11:09 AM, Brett Cannon wrote:
On 1/18/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
I'd propose bin() to stay in line with the short abbreviated names.
There has been some previous discussion about removing hex()/oct()
from
builtins for Python 3.0, IIRC. I sure don't
On Jan 18, 2006, at 8:47 PM, James Y Knight wrote:
On Jan 18, 2006, at 11:40 PM, Aahz wrote:
On Wed, Jan 18, 2006, Guido van Rossum wrote:
Can we just all agree that RMS is an asshole now? Bah.
Citing RMS's insanity is a great way to get my blood steaming. --
GvR
Ya know, you don't
On Jan 20, 2006, at 1:39 PM, Phillip J. Eby wrote:
At 11:19 AM 01/20/2006 -0800, Guido van Rossum wrote:
(There *are*other uses besides the trampoline,
right? :-)
It's easy to come up with use cases where you feed data *into* a
generator
(parsers and pipelines, for example). I just
On 2/1/06, Greg Wilson [EMAIL PROTECTED] wrote:
Generator expressions make syntactic support irrelevant:
Not when you're teaching the language to undergraduates: I haven't
actually done the study yet (though I may this summer), but I'm willing to
bet that allowing math notation for sets will
I was recently reviewing a lot of the Python 2.4 code I have written,
and I've noticed one thing: thanks to the attrgetter and itemgetter
functions in module operator, I've been using (or been tempted to use)
far fewer lambdas, particularly but not exclusively in key= arguments
to sort and sorted.
On Feb 3, 2006, at 1:36 AM, Michael Hudson wrote:
Alex Martelli [EMAIL PROTECTED] writes:
I was recently reviewing a lot of the Python 2.4 code I have written,
and I've noticed one thing: thanks to the attrgetter and itemgetter
functions in module operator, I've been using (or been tempted
On Feb 3, 2006, at 6:47 AM, Giovanni Bajo wrote:
...
use itemgetter and friends but the correct way of doing a
defferred x[1]
*should* let you write x[1] in the code. This is my main
opposition to
partial/itemgetter/attrgetter/methodcaller: they allow deferred
execution
using a
When teaching some programming to total newbies, a common frustration
is how to explain why a==b is False when a and b are floats computed
by different routes which ``should'' give the same results (if
arithmetic had infinite precision). Decimals can help, but another
approach I've found
On 2/6/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 2/6/06, Donovan Baarda [EMAIL PROTECTED] wrote:
yeah... the problem is differentiating the empty set from an empty dict.
The only alternative that occured to me was the not-so-nice and
not-backwards-compatible {:} for an empty dict and
On 2/6/06, Guido van Rossum [EMAIL PROTECTED] wrote:
...
What we should do in 3.0 is not entirely clear to me. It would be nice
if there was only a single type (named 'int', of course) with two
run-time representations, one similar to the current int and one
similar to the current long. But
On 2/6/06, Aahz [EMAIL PROTECTED] wrote:
...
def areclose(x, y, relative_err = 1.e-5, absolute_err=1.e-8):
diff = abs(x - y)
ave = (abs(x) + abs(y))/2
return diff absolute_err or diff/ave relative_err
Also, separating the two terms with 'or' rather than '+' makes the
two
On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
...
what other reactive socket framework is there that would fit well into
the standard library ? is twisted really simple enough ?
Twisted is wonderful, powerful, rich, and very large. Perhaps a small
subset could be carefully extracted
On 2/9/06, Travis E. Oliphant [EMAIL PROTECTED] wrote:
...
The patch adds a new API function int PyObject_AsIndex(obj).
This was not specifically in the PEP but probably should be. The name
could also be PyNumber_AsIndex(obj) but I was following the nb_nonzero
slot example to help write
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
...
Next, the schedule. Neal's draft of the schedule has us releasing 2.5
in October. That feels late -- nearly two years after 2.4 (which was
released on Nov 30, 2004). Do people think it's reasonable to strive
for a more aggressive (by
On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote:
[Guido van Rossum]
PEP 351 - freeze protocol. I'm personally -1; I don't like the
idea of
freezing arbitrary mutable data structures. Are there champions who
want to argue this?
It has at least one anti-champion. I think it is a
On 2/13/06, Guido van Rossum [EMAIL PROTECTED] wrote:
...
I don't like to add a built-in index() at this point; mostly because
of Occam's razor (we haven't found a need).
I thought you had agreed, back when I had said that __index__ should
also be made easily available to implementors of
On 2/14/06, Just van Rossum [EMAIL PROTECTED] wrote:
...
Maybe it's even better to use opentext() AND openbinary(), and deprecate
plain open(). We could even introduce them at the same time as bytes()
(and leave the open() deprecation for 3.0).
What about shorter names, such as 'text'
On Feb 15, 2006, at 9:51 AM, Barry Warsaw wrote:
On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote:
Regarding open vs. opentext, I'm still not sure. I don't want to
generalize from the openbytes precedent to openstr or openunicode
(especially since the former is wrong in 2.x and the
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;
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 really that bad.
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 Feb 20, 2006, at 5:41 AM, Guido van Rossum wrote:
...
Alternative A: add a new method to the dict type with the semantics of
__getattr__ from the last proposal, using default_factory if not None
(except on_missing is inlined). This avoids the discussion about
broken invariants, but one
On Feb 20, 2006, at 8:35 AM, Raymond Hettinger wrote:
[GvR]
I'm not convinced by the argument
that __contains__ should always return True
Me either. I cannot think of a more useless behavior or one more
likely to have
unexpected consequences. Besides, as Josiah pointed out, it is
On Feb 20, 2006, at 12:33 PM, Guido van Rossum wrote:
...
You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
is perfectly fine there and hard to improve upon.
I see d[k]+=1 as a substantial improvement -- conceptually more
direct, I've now seen one more k than I had
On Feb 20, 2006, at 12:38 PM, Aahz wrote:
...
Can you say, for the record (since nobody else seems to care), if
d.getorset(key, func) would work in your use cases?
Because I haven't been reading this thread all that closely, you'll
have
to remind me what this means.
Roughly the same
On Feb 20, 2006, at 3:04 PM, Brett Cannon wrote:
...
- Yes and it should be the only constructor argument. This is my
...
While #3 is my preferred solution as well, it does pose a Liskov
violation if this is a direct dict subclass instead of storing a dict
How so? Liskov's
On Feb 20, 2006, at 5:05 PM, Raymond Hettinger wrote:
[Alex]
I see d[k]+=1 as a substantial improvement -- conceptually more
direct, I've now seen one more k than I had seen before.
[Guido]
Yes, I now agree. This means that I'm withdrawing proposal A (new
method) and championing only B (a
On Feb 21, 2006, at 6:53 AM, Bengt Richter wrote:
Perhaps a more informative message would be nice.
Here's an easy way to trigger it:
compile(#-*- coding: ascii -*-\nprint 'ab%c'\n%0x80, '','exec')
Traceback (most recent call last):
File stdin, line 1, in ?
MemoryError
Definitely
On Feb 21, 2006, at 1:51 AM, Greg Ewing wrote:
...
Just one more thing -- have you made a final decision
about the name yet? I'd still prefer something like
'autodict', because to me 'defaultdict' suggests
autodict is shorter and sharper and I prefer it, too: +1
etc.) it seems more
On Feb 22, 2006, at 7:21 AM, Raymond Hettinger wrote:
...
I'm somewhat happy with the patch as it stands now. The only part
that needs serious rethinking is putting on_missing() in regular
dicts. See my other email on that subject.
What if we named it _on_missing? Hook methods
:
Guido van Rossum
Alex Martelli
many other worthies snipped
T-shirts? I'm an absolute fan of T-shirts...!-)
The point is that I don't know some of you, so please grab my shoulder
here in PyCon. And if you're not coming to the conference but somebody
can carry it to you, just let me know
On Feb 25, 2006, at 4:43 PM, [EMAIL PROTECTED] wrote:
Zitat von Facundo Batista [EMAIL PROTECTED]:
The question is, it's ok to use a third party system for this
initiative? Or you (we) prefer to host it in-house? Someone alredy
thought of this?
I thought about it at one time, and I think
On Mar 6, 2006, at 4:43 PM, Bob Ippolito wrote:
On Mar 6, 2006, at 4:14 PM, Guido van Rossum wrote:
...
I wonder if this use case and the frequently requested
case-insensitive dict don't have some kind of generalization in
common
-- perhaps a dict that takes a key function a la
1 - 100 of 174 matches
Mail list logo
