"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> #!/usr/bin/python2.4
>
> """An example of generic functions vs. adaptation.
Nice.
For me, the idea of 'generic function' goes into my brain much more
smoothly than the idea of 'protocol adaptation' even though the
> As for the % operator, I never liked it -- either a builtin function,
> or even better a method of string objects, is going to be much more
> readable (and my preference would be to have it take optional
> positional arguments, corresponding to {1}, {2}, etc, and optional
> named argument
Greg Ewing wrote:
> Ian Bicking wrote:
>
>> Using {} instead of $/${} doesn't seem like a big win.
>
> Perhaps this is where we differ. To me it
> *does* make quite a substantial difference
> to readability -- easily enough to override
> whatever small advantage there might be in
> following what
Guido van Rossum wrote:
>On 4/4/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>
>(Could you not change the subject each time? Or if you do, could you
>assume the reader hasn't necessarily read your previous posts? For
>gmail users like me, each subject change starts a new thread -- like
>in newsgrou
Just van Rossum wrote:
> While I appreciate that there are maintained pure Python versions of
> those modules, as a user it irritates me that I have the choice. The
> argument so far for not replacing StringIO with cStringIO was that
> they're subtly incompatible (mostly StringIO's "feature" to sup
On Apr 4, 2006, at 9:03 PM, Guido van Rossum wrote:
...
> It would be useful to compare this to adaptation built on top of
> generic functions. Alex seems to be convinced that adaptation is more
> powerful than generic functions; but he hadn't considered the
> possibility of having a generic f
On Tuesday 04 April 2006 23:37, Ian Bicking wrote:
> Note that if it takes keyword arguments, but doesn't take a single
> dictionary-like object (like % and string.Template.substitute do), then
> you lose any ability to use clever or interesting dictionary-like
> objects for substitution.
Inde
On 4/4/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Apr 4, 2006, at 5:29 PM, Guido van Rossum wrote:
> [excellent example, mostly snipped]
>
> Just for when this will be published/blogged (as it deserves to be!),
> tiny nit:
>
> > if hasattr(obj, "__iter__"):
> > return obj._
On 4/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I'm in agreement with the sentiment of keeping the Python code though
> -- it's incredibly useful for example in Jython and IronPython.
> Perhaps we should switch to a naming scheme where we have a "pickle"
> module that you're supposed to
On 4/4/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
(Could you not change the subject each time? Or if you do, could you
assume the reader hasn't necessarily read your previous posts? For
gmail users like me, each subject change starts a new thread -- like
in newsgroups -- and having so far ignored
Alex Martelli wrote:
> On Apr 4, 2006, at 8:37 PM, Ian Bicking wrote:
>> Alex Martelli wrote:
>>> As for the % operator, I never liked it -- either a builtin
>>> function, or even better a method of string objects, is going to be
>>> much more readable (and my preference would be to have it tak
On Apr 4, 2006, at 8:37 PM, Ian Bicking wrote:
> Alex Martelli wrote:
>> As for the % operator, I never liked it -- either a builtin
>> function, or even better a method of string objects, is going to
>> be much more readable (and my preference would be to have it take
>> optional positi
Alex Martelli wrote:
> As for the % operator, I never liked it -- either a builtin function,
> or even better a method of string objects, is going to be much more
> readable (and my preference would be to have it take optional
> positional arguments, corresponding to {1}, {2}, etc, and option
Alex Martelli wrote:
> On Apr 4, 2006, at 5:29 PM, Guido van Rossum wrote:
> [excellent example, mostly snipped]
>
> Just for when this will be published/blogged (as it deserves to be!),
> tiny nit:
>
>> if hasattr(obj, "__iter__"):
>> return obj.__iter__()
>> raise TypeErro
On Apr 4, 2006, at 8:12 PM, Bill Janssen wrote:
>> +1 for {} over the $/${} dichotomy -- it's easier to explain, as well
>> as more readable.
>
> Perhaps I'm just allergic to bash/perl/java/ruby syntax, but the more
> I follow this discussion, the more I like the current string
> formatting syste
Barry Warsaw wrote:
> On Apr 4, 2006, at 7:17 PM, Ian Bicking wrote:
>> These don't quite work with string.Template, because ${...} has the
>> same content constraints that $... has, so you can't easily put
>> extended expressions in there. I could have sworn I opened an SF bug
>> on this, but
On Apr 4, 2006, at 5:29 PM, Guido van Rossum wrote:
[excellent example, mostly snipped]
Just for when this will be published/blogged (as it deserves to be!),
tiny nit:
> if hasattr(obj, "__iter__"):
> return obj.__iter__()
> raise TypeError("Can't iterate over a %s object"
On 4/4/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 04, 2006, Just van Rossum wrote:
> > Has there been any discussion yet about StringIO vs cStringIO and pickle
> > vs cPickle?
>
> Now there is!
>
> > While I appreciate that there are maintained pure Python versions of
> > those modules, as a
> +1 for {} over the $/${} dichotomy -- it's easier to explain, as well
> as more readable.
Perhaps I'm just allergic to bash/perl/java/ruby syntax, but the more
I follow this discussion, the more I like the current string
formatting system :-).
It seems to me that the core of the issue is the
On Apr 4, 2006, at 5:38 PM, Greg Ewing wrote:
> Ian Bicking wrote:
>
>> Using {} instead of $/${} doesn't seem like a big win.
>
> Perhaps this is where we differ. To me it
> *does* make quite a substantial difference
> to readability -- easily enough to override
> whatever small advantage there
On Apr 4, 2006, at 8:38 PM, Greg Ewing wrote:
> Ian Bicking wrote:
>
>> Using {} instead of $/${} doesn't seem like a big win.
>
> Perhaps this is where we differ. To me it
> *does* make quite a substantial difference
> to readability -- easily enough to override
> whatever small advantage there
On Apr 4, 2006, at 7:44 PM, Greg Ewing wrote:
> I'm more interested in long-term readability
> and maintainability than in pandering to one-off
> impressions when coming from another language.
>
> I don't believe they would have any difficulty
> "getting" this, anyway. Can you honestly say
> that
On Apr 4, 2006, at 7:17 PM, Ian Bicking wrote:
>
> These don't quite work with string.Template, because ${...} has the
> same content constraints that $... has, so you can't easily put
> extended expressions in there. I could have sworn I opened an SF
> bug on this, but it appears not. But
Greg Ewing <[EMAIL PROTECTED]> wrote
> Subject: Re: [Python-3000] pre-PEP: Things that Will Not Change in
> Python 3.0
> To: python-3000@python.org
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Guido van Rossum wrote:
>
>> Good idea. Ma
On Tue, Apr 04, 2006 at 06:51:48PM -0500, Ian Bicking wrote:
> Using {} instead of $/${} doesn't seem like a big win.
Big enough to be worth considering, IMO.
Neil
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/list
Guido van Rossum wrote:
>> __hash__() isn't always O(1), so in my world it wouldn't be a
>> property.
>
> I like this best of all the arguments presented so far, and consider
> the case closed.
>
> (The weakness of the argument "but hash() can take a long time to
> compute" is that a good hash
On Wed, Apr 05, 2006, Greg Ewing wrote:
> Ian Bicking wrote:
>>
>> Though I also agree that $"answer: $answer" introduces a confusing
>> number of $'s.
>
> If an interpolation feature like this were considered desirable, maybe
> the backquote syntax could be repurposed for it in Py3k?
Aaagh!
On 4/4/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > The question is where to draw the line. I don't believe you really
> > meant "all no-args methods". Perhaps you meant "all side-effect free
> > argument-less methods that return the same value ea
Ian Bicking wrote:
> Using {} instead of $/${} doesn't seem like a big win.
Perhaps this is where we differ. To me it
*does* make quite a substantial difference
to readability -- easily enough to override
whatever small advantage there might be in
following what everyone else does.
--
Greg
_
One followup. Alex mentioned that PyPy used to have its own
implementation of multiple dispatch (which is really the same as
generic functions) but ditched over a year ago. Would Armin or Samuele
care to explain why? Do they no longer like multiple dispatch or was
the reason for the extraction spec
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The question is where to draw the line. I don't believe you really
> meant "all no-args methods". Perhaps you meant "all side-effect free
> argument-less methods that return the same value each time (or at
> least until some explicit change to the obje
#!/usr/bin/python2.4
"""An example of generic functions vs. adaptation.
After some face-to-face discussions with Alex I'm presenting here two
extremely simplified implementations of second-generation adaptation
and generic functions, in order to contrast and compare.
As the running example, we u
Delaney, Timothy (Tim) wrote:
> 2. If it's a property, subclasses need to override the getter and
> recreate the property if they want to change the hash of the object
> (unless the base class uses a lazy property).
In which case the performance advantage becomes
negative (instead of just a metho
Guido van Rossum wrote:
> The __hash__() method qualifies, which is why it's a tough call (I'll
> come back on that; I want to come up with a reason why __hash__()
> should remain a method).
Another thought is how frequently the method/attribute
is going to be used. I can't even remember when was
Barry Warsaw wrote:
> While we were at it, we changed everything
> that returns a newly formed concrete sequence to returning an iterator
> (which broke code that was doing random access into the sequence,
That sounds like a good use for Py3k-style views!
--
Greg
_
Guido van Rossum wrote:
> Good idea. Maybe 3000 should then be the meta-meta PEP with the
> Process for deciding Python 3000 Processes.
And if we get too many more meta-meta-PEPs we'll need
a meta-meta-meta-PEP on Procedure for Numbering
Meta-Meta-PEPs. Not sure what number it should have,
though
Barry Warsaw wrote:
> Certainly "foo.get_something()" and
> "foo.set_something(thing)" are much better spelled "foo.something" and
> "foo.something = thing".
If you already have a get/set pair, that definitely
makes sense. If hash() had been spelled get_hash()
it might have made sense there too.
Greg Ewing wrote:
> Barry Warsaw wrote:
>> Here i disagree. $-strings are so familiar to people coming from other
>> languages that they instantly "get it".
>
>
> I'm more interested in long-term readability
> and maintainability than in pandering to one-off
> impressions when coming from anothe
Barry Warsaw wrote:
> On Tue, 2006-04-04 at 14:28 +1200, Greg Ewing wrote:
>
>>I'm also not all that keen on $, either inside
>>or outside the string. It seems to me that
>>something like
>>
>> "User {user} has printed {n} pages"
>>
>>sets off the parameters from the rest of the
>>string more re
Guido van Rossum wrote:
> We apparently need more guidance for when it's appropriate to turn
> something into an attribute.
I'd suggest that things which could require substantial
computation to obtain should remain methods; hash()
seems to fall into that category.
--
Greg
__
Barry Warsaw wrote:
> On Mon, 2006-04-03 at 15:23 -0500, Ian Bicking wrote:
>
>
>>This is all wandering off-topic, except that all these cases make me
>>think that different kinds of wrapping are very useful. For instance,
>>if you want to make sure everything is quoted before being inserted:
Ian Bicking wrote:
> Though I also agree that $"answer: $answer" introduces a confusing
> number of $'s.
If an interpolation feature like this were considered
desirable, maybe the backquote syntax could be
repurposed for it in Py3k?
--
Greg
___
Pytho
Michael P. Soulier wrote:
> If
> one is going to use a method obviously taken from the stack ADT, having a
> method normally called push() would be less confusing.
I think the confusion here really starts with using
the name pop(), since it's not clear which end of
the list it pops from. It might
Guido van Rossum wrote:
> The __hash__() method qualifies, which is why it's a tough call (I'll
> come back on that; I want to come up with a reason why __hash__()
> should remain a method). The iterator-getting example above doesn't
> qualify.
Yeah - I felt it was a borderline case, so thought i
On 4/4/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Just a data point. In our API, we've been converting all of our no-arg
> methods to attributes/properties, each of which may or may not be
> writable of course. It's simplified our Python code enormously, and
> made it much more readable. Cert
On 4/4/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-04-04 at 09:57 -0700, Guido van Rossum wrote:
> > On 4/3/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> > > I've been thinking that `hash` could be an attribute (or property if it
> > > needs to be calculated on-the-fly) rat
On 4/4/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I was going to comment about this one "check it in, we'll add to it
> > later", but then I realized it's not 100% clear whether this is a
> > feature PEP or a meta-PEP? It focuses on features so by that yardstick
> > i
On Tue, 2006-04-04 at 09:57 -0700, Guido van Rossum wrote:
> On 4/3/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> > I've been thinking that `hash` could be an attribute (or property if it
> > needs to be calculated on-the-fly) rather than the current method call.
> >
> > Or it could be an
On Tue, 2006-04-04 at 14:28 +1200, Greg Ewing wrote:
> If we're going to encourage use of named arguments
> (which I think we should) I think we also need to
> get rid of the need for %(foo)s constructs, which
> are extremely error-prone and hard to read.
In general, I agree.
> I'm -0.7 on havin
On 4/3/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Barry Warsaw wrote:
>
> > I don't much like the $"" prefix
>
> This was discussed during the last round of formatting
> wars, and the conclusion was that having $ both
> inside and outside the string would be too visually
> confusing.
>
> > I don't
On Mon, 2006-04-03 at 22:18 -0400, Adam DePrince wrote:
> Worse are the maintance problems when you have to change your
> expression ... inside every translation of your string.
You're right, that's far far worse. One thing about i18n is that it
introduces huge inertia against changing any hum
On Tue, 2006-04-04 at 10:41 -0500, Ian Bicking wrote:
> A $ prefix would act at parse time, i.e., $"answer: $answer" would be
> equivalent to ("answer: " + str(answer)).
Wouldn't it be equivalent to string.Template("answer: $answer") ? In
any event...
> Though I also agree that $"answer: $answ
On Tue, 2006-04-04 at 13:27 +1200, Greg Ewing wrote:
> If I were designing a formatting system from scratch,
> I think I'd separate the issue of formatting numbers into
> strings from the issue of inserting strings into other
> strings.
This really is a key observation. PEP 292 tried to make ins
On Mon, 2006-04-03 at 15:23 -0500, Ian Bicking wrote:
> This is all wandering off-topic, except that all these cases make me
> think that different kinds of wrapping are very useful. For instance,
> if you want to make sure everything is quoted before being inserted:
>
> class EscapingWrapper:
Considering generic function in combination adaption led to one more
small change in the Protocol implementation that I'm playing with, and
all of the sudden I'm left with something that I could actually use.
What I realized was that you could factor out the part that potentially
has a lot of
Ian Bicking wrote:
> Walter Dörwald wrote:
>> What happens, if I do the following
>>
>> @PrettyPrinter.pformat.when(object=list)
>> def foo(...):
>>...
>>
>> @PrettyPrinter.pformat.when(object=object)
>> def foo(...):
>>...
>>
>> How does it know which isinstance() check to do first?
>
>
On 4/3/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> I've been thinking that `hash` could be an attribute (or property if it
> needs to be calculated on-the-fly) rather than the current method call.
>
> Or it could be an easy thing to add to the "won't change" PEP ...
The latter, please.
Nick Coghlan wrote:
>Unfortunately the rules for choosing *which* implementation to dispatch to,
>even if restricting things to concrete types only, are necessarily complex.
>
>As Walter pointed out, the deliberately simplistic sample code elsewhere in
>this thread dispatches to a different method
Georg Brandl wrote:
> Greg Ewing wrote:
>
>>Barry Warsaw wrote:
>>
>>
>>>I don't much like the $"" prefix
>>
>>This was discussed during the last round of formatting
>>wars, and the conclusion was that having $ both
>>inside and outside the string would be too visually
>>confusing.
>
>
> Another
On 04/04/06 Gareth McCaughan said:
> [of course I meant to type "push". Lisp's operator names
> are obscure sometimes, but not that obscure]
Indeed.
> I'd forgotten that Perl has a "push" with that behaviour. And,
> come to think of it, Lisp has VECTOR-PUSH and VECTOR-PUSH-EXTEND
> that add ont
Tim Hochberg wrote:
> Rewriting this using "distributed" adapters looks like this:
>
> >>> pprint = Protocol('pprint')
I suppose this means that Protocol('pprint') implies an interface like:
class IPprint(Interface):
def __call__(object):
"""print the pretty representation of the
Walter Dörwald wrote:
> What happens, if I do the following
>
> @PrettyPrinter.pformat.when(object=list)
> def foo(...):
>...
>
> @PrettyPrinter.pformat.when(object=object)
> def foo(...):
>...
>
> How does it know which isinstance() check to do first?
It can see that isinstance(list, o
Phillip J. Eby wrote:
> At 11:03 PM 4/3/2006, Ian Bicking wrote:
>
>>Guido van Rossum wrote:
>>
>>>On 4/3/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>>>
As an alternative to adaptation, I'd like to propose generic functions.
I think they play much the same role, except they are much simp
On Tuesday 2006-04-04 13:52, Michael P. Soulier wrote:
> On 04/04/06 Gareth McCaughan said:
...
> > That would confuse anyone used to Lisp, where after
> >
> > (defvar foo (list 1 2 3 4))
> > (puch 99 foo)
[of course I meant to type "push". Lisp's operator names
are obscure sometimes, but
On Tue, Apr 04, 2006, Just van Rossum wrote:
>
> Has there been any discussion yet about StringIO vs cStringIO and pickle
> vs cPickle?
Now there is!
> While I appreciate that there are maintained pure Python versions of
> those modules, as a user it irritates me that I have the choice. The
> arg
> It's a minor thing, but it'd be nice to make a method alias for append() on
> mutable sequences called push(), to go with pop().
That would confuse anyone used to Lisp, where after
(defvar foo (list 1 2 3 4))
(puch 99 foo)
the value of FOO is (99 1 2 3 4) rather than (1 2 3 4 99).
I t
On 04/04/06 Gareth McCaughan said:
> > It's a minor thing, but it'd be nice to make a method alias for append() on
> > mutable sequences called push(), to go with pop().
>
> That would confuse anyone used to Lisp, where after
>
> (defvar foo (list 1 2 3 4))
> (puch 99 foo)
>
> the valu
Tim Hochberg wrote:
> Michael Chermside wrote:
>> Tim's proposal (if I understand it correctly) depends on transitivity --
>> his idea is to have the class authors register as satisfying a small
>> number of widely-known protocols (Psrc in his case),
>>
> Yes.
>
>
>> then use transitivity
>> to i
Greg Ewing wrote:
> Barry Warsaw wrote:
>
>> I don't much like the $"" prefix
>
> This was discussed during the last round of formatting
> wars, and the conclusion was that having $ both
> inside and outside the string would be too visually
> confusing.
Another issue is that current string prefi
Terry Reedy wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>I didn't see any comments on this PEP.
>
> For me, it is pretty clear and sensible, hence not much to say.
> Plus I expected others to says whatever was needed ;-).
>
>> I'm not sure that the
Guido van Rossum wrote:
> I was going to comment about this one "check it in, we'll add to it
> later", but then I realized it's not 100% clear whether this is a
> feature PEP or a meta-PEP? It focuses on features so by that yardstick
> it's a feature PEP. But in its list-of-miscellany nature it
>
At 11:03 PM 4/3/2006, Ian Bicking wrote:
>Guido van Rossum wrote:
>>On 4/3/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>>>As an alternative to adaptation, I'd like to propose generic functions.
>>> I think they play much the same role, except they are much simpler to
>>>use and think about.
>>Give
Ian Bicking wrote:
> As an alternative to adaptation, I'd like to propose generic functions.
> I think they play much the same role, except they are much simpler to
> use and think about.
Unfortunately the rules for choosing *which* implementation to dispatch to,
even if restricting things t
On 4/4/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> > Perhaps. The import-for-side-effect requirement sounds like a
> > showstopper though.
>
> There's a bunch of places where this is a problem. This is a problem
> anywhere you want to add functionality to something that doesn't belong
> to you.
Terry Reedy wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> I didn't see any comments on this PEP.
>
> For me, it is pretty clear and sensible, hence not much to say.
> Plus I expected others to says whatever was needed ;-).
>
>> I'm not sure that the
Ian Bicking wrote:
> Guido van Rossum wrote:
>
>[...]
>> What does when(object=list) mean? Does it do an isinstance() check?
>
> Yes; I think RuleDispatch has a form (though I can't remember what the
> form is -- it isn't .when()).
What happens, if I do the following
@PrettyPrinter.pformat.w
Greg Ewing wrote:
> Barry Warsaw wrote:
>
>> I don't much like the $"" prefix
>
> This was discussed during the last round of formatting
> wars, and the conclusion was that having $ both
> inside and outside the string would be too visually
> confusing.
>
>> I don't see a good
>> way to marry th
Has there been any discussion yet about StringIO vs cStringIO and pickle
vs cPickle?
While I appreciate that there are maintained pure Python versions of
those modules, as a user it irritates me that I have the choice. The
argument so far for not replacing StringIO with cStringIO was that
they're
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>I didn't see any comments on this PEP.
For me, it is pretty clear and sensible, hence not much to say.
Plus I expected others to says whatever was needed ;-).
> I'm not sure that the order in which the
> steps are t
79 matches
Mail list logo
