Re: [Python-3000] String formating operations in python 3k

Ian D. Bollinger wrote: > On 4/5/06, *John J Lee* <[EMAIL PROTECTED] > wrote: > > But how about putting them at the start, after the $? That way, the > format character can't get mixed up with the text following it. For > example, $r{foo} would mean the same

[Python-3000] Removing repr

Ian D. Bollinger writes: > This is somewhat tangental, but hopefully an $r formatting operation > won't be necessary in Py3k, assuming repr() and str() can somehow be > combined. Nick Coghlan responds: > repr() (machine readable) and str() (human readable) do different things, > so why would combi

Re: [Python-3000] Removing repr

On 06/04/06 Michael Chermside said: > repr() and str() are both concerned with turning an object into a > string that vaguely describes it. (Turning it into a string that I thought that the distinction was as follows. str() should return a human-readable representation of something. repr() sh

Re: [Python-3000] Adaptation vs. Generic Functions

> What I'd like to see is how this changes if we use a generic functions > (multiple dispatch) implementation instead of adaptation. Adaptation > is pretty much isomorphic with a generic function of one argument (see > my blog). But the register_for() method couldn't (shouldn't) interpret > multipl

Re: [Python-3000] Removing repr

On Thu, 6 Apr 2006, Michael P. Soulier wrote: [...] > I thought that the distinction was as follows. > > str() should return a human-readable representation of something. > > repr() should return a machine-readable representation of something, suitable > for an exec command. [...] Is this old ches

[Python-3000] Sane transitive adaptation

One issue with generic functions and adaptation as currently being discussed (and something Tim mentioned a while back), it that it is very focused on dispatching based solely on obj.__class__.__mro__. That's all well and good, but (to use an example of Tim's), suppose we have a couple of frame

[Python-3000] Kill "generic functions"!

I cringe every time I see the phrase "generic function". It's way too generic -- it doesn't contain any hint of its meaning, and I find it confusing because Python already has what I think of as generic functions: def adder(a, b): return a+b That's a perfectly good generic function that depe

Re: [Python-3000] Sane transitive adaptation

Nick Coghlan wrote: > One issue with generic functions and adaptation as currently being discussed > (and something Tim mentioned a while back), it that it is very focused on > dispatching based solely on obj.__class__.__mro__. RuleDispatch allows any function to be used in selecting an impleme

Re: [Python-3000] Adaptation vs. Generic Functions

Walter Dörwald wrote: > Guido van Rossum wrote: > > >>On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote: >> >>>The problem with this is that it looks in the base protocol only if the >>>the class can't be found in the registry of the subprotocol. This mean >>>that an adapter from the subprotoco

Re: [Python-3000] Kill "generic functions"!

At 08:51 AM 4/6/2006, Aahz <[EMAIL PROTECTED]> wrote: >I cringe every time I see the phrase "generic function". It's way too >generic -- it doesn't contain any hint of its meaning, And worse - "generic" in US English often implies: * commodity * ordinary * cheap knock-off * low-quality etc. No

Re: [Python-3000] Sane transitive adaptation

At 08:51 AM 4/6/2006, Nick Coghlan <[EMAIL PROTECTED]> wrote: >There is, however, an alternative, which would be to include a mechanism for >telling a protocol about other equivalent protocols, and updating the >registration mechanism to distribute any registration updates to the >equivalent protoc

Re: [Python-3000] Kill "generic functions"!

On 4/6/06, Aahz <[EMAIL PROTECTED]> wrote: > I cringe every time I see the phrase "generic function". It's way too > generic -- it doesn't contain any hint of its meaning, and I find it > confusing because Python already has what I think of as generic > functions: > > def adder(a, b): > return

Re: [Python-3000] Sane transitive adaptation

At 08:51 AM 4/6/2006, Ian Bicking <[EMAIL PROTECTED]> wrote: >So... in theory you could register strings, and thus implement >RuleDispatches behavior (where those strings represent expressions). >Or, ideally, py3k will have something better than strings to represent >unevaluated expressions. Thoug

Re: [Python-3000] Kill "generic functions"!

Phillip J. Eby wrote: > As long as we're inventing our own terminology, I vote for > "extensible functions", as this emphasizes the benefit rather than > the technology. Without extensibility, there's nothing really > special about them. We wouldn't even be talking about them if you > had to

Re: [Python-3000] Sane transitive adaptation

Phillip J. Eby wrote: > At 08:51 AM 4/6/2006, Ian Bicking <[EMAIL PROTECTED]> wrote: > >> So... in theory you could register strings, and thus implement >> RuleDispatches behavior (where those strings represent expressions). >> Or, ideally, py3k will have something better than strings to represent

Re: [Python-3000] Sane transitive adaptation

> But I figured it was something worth throwing out there :) > > Cheers, > Nick. I'm finding most of this discussion very interesting although the fine details haven't clicked for me just yet. This reminds me of Guido's multi-method blog entry a while back. In both the cases being discuss

Re: [Python-3000] Kill "generic functions"!

At 10:07 AM 4/6/2006, Ian Bicking wrote: >I think "extensible" or other extend-ish terms imply a purpose, not >a mechanism. Which is why it's a good thing, IMO. >"Multimethod" or "multifunction" refers to dispatching on multiple >arguments based on type (where current class dispatch is done by

Re: [Python-3000] Kill "generic functions"!

On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > I have two problems with "overload": > > 1) You have to already be a programmer to make any sense of the term... You gotta be kidding. This wouldn't be true for other terms like class or method? I really don't care about non-programmers "getti

Re: [Python-3000] Removing repr

You are all correct. :-) The way I think of it is that str() is used by print; repr() is used by the interactive prompt. Clearly you want print 'abc' to print abc without quotes; but in the interactive prompt you want different output for the number 1 and the string '1', and that's what repr() is

Re: [Python-3000] Removing repr

Guido van Rossum wrote: > FWIW, for types that implement them the same, I'd like to see them > return something from which the type is obvious, i.e. repr()-like. > Just yesterday I helped someone debug an AttributeError where he was > convinced that an object was a string because its repr() looked

Re: [Python-3000] Kill "generic functions"!

At 10:56 AM 4/6/2006, Guido van Rossum wrote: >I disagree on principle -- if you were to invent a mechanism to do >function overloading purely at run-time, then surely you would come up >with something akin to what we're planning to do here. The issue is more that Java programmers think they need

Re: [Python-3000] Sane transitive adaptation

Nick Coghlan wrote: > One issue with generic functions and adaptation as currently being discussed > (and something Tim mentioned a while back), it that it is very focused on > dispatching based solely on obj.__class__.__mro__. > > That's all well and good, but (to use an example of Tim's), supp

Re: [Python-3000] Removing repr

On 6 Apr 2006, at 7:02, John J Lee wrote: > On Thu, 6 Apr 2006, Michael P. Soulier wrote: > [...] >> I thought that the distinction was as follows. >> >> str() should return a human-readable representation of something. >> >> repr() should return a machine-readable representation of >> somethin

Re: [Python-3000] Kill "generic functions"!

On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > The issue is more that Java programmers think they need to use > staticmethod because that sounds to them like a Java "static method", > instead of doing something more appropriate like a classmethod or a > module-level function. I worry that

Re: [Python-3000] Sane transitive adaptation

On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > I don't want to discourage people from working out their own ideas, > but a lot of the stuff that's being discussed here about protocol > adaptation is already implemented in PyProtocols. That's great. I believe that if we derive things from f

Re: [Python-3000] Removing repr

On 4/6/06, John J Lee <[EMAIL PROTECTED]> wrote: [suggests changing the docs for repr for Py3k] The current help(repr) may be even more misleading. I would suggest making the change as early as 2.4 (2.5 for the docstring. Changes: (1) It doesn't mention backquotes. They are already deprecate

Re: [Python-3000] Kill "generic functions"!

Le jeudi 06 avril 2006 à 13:33 -0700, Guido van Rossum a écrit : > I think that the solution to this would be a book or course "Python > for Java programmers". Not using the most natural name for a feature > because Java programmers might misunderstand it sound like the wrong > motivation. > > Pl

Re: [Python-3000] Sane transitive adaptation

At 02:15 PM 4/6/2006, Guido van Rossum wrote: >On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > I don't want to discourage people from working out their own ideas, > > but a lot of the stuff that's being discussed here about protocol > > adaptation is already implemented in PyProtocols. > >

Re: [Python-3000] Kill "generic functions"!

On 4/6/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > But overloaded methods as they exist now have exactly the same > expression as non-overloaded methods, all the machinery (mro walking > etc.) being hidden from the programmer. What type of overloading are you referring to? The way I think abou

Re: [Python-3000] Removing repr

Michael P. Soulier wrote: > I thought that the distinction was as follows. > > str() should return a human-readable representation of something. > > repr() should return a machine-readable representation of something, suitable > for an exec command. As Michael pointed out, this is totally im

Re: [Python-3000] Kill "generic functions"!

Aahz wrote: > I cringe every time I see the phrase "generic function". It's way too > generic "Multiple dispatch" seems to capture the important features. -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listin

Re: [Python-3000] Kill "generic functions"!

Phillip J. Eby wrote: > So overloading and extensible functions are different in two ways: > > 1. New overloads are added at runtime > 2. Implementation selection occurs at runtime Maybe "dynamically overloaded"? -- Greg ___ Python-3000 mailing list P

Re: [Python-3000] Removing repr

Greg Ewing wrote: > The guideline I use is quite different: str() is for > normal program output, repr() is for debugging > output. I think that another important difference between str() and repr() is that repr() is often used as an embedded string in other objects' representations; but str() u

Re: [Python-3000] Adaptation vs. Generic Functions

#!/usr/bin/env python2.5 # overloading.py """Here's another executable email. This is an implementation of (dynamically, or run-time) overloaded functions, formerly known as generic functions or multi-methods. I actually blogged on Artima about multi-methods about a year ago; but at the time I

Re: [Python-3000] Adaptation vs. Generic Functions

Guido wrote: > mros = tuple(t.__mro__ for t in types) > n = len(mros) > candidates = [sig for sig in self.registry > if len(sig) == n and > all(t in mro for t, mro in zip(sig, mros))] I believe this can be simplified to: n