Two minor syntactic proposals

[Steve Holden]

Of course, a possible solution to the original problem is to create a new
class, whose __init__() method creates an instance variable containing a
member of the original class, and to delegate non-implemented methods to
that instance. I'm aware such delegation takes a little more CPU time, but
it keeps the interface clean and guarantees that if the original class is
redefined later the revised interface is made available.

Probably preaching to the choir here, though.

regards
 Steve
--
http://www.holdenweb.com/


"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:9gkcsn0229c at enews2.newsguy.com...
> "Barry A. Warsaw" <barry at digicool.com> wrote in message
> news:mailman.992844567.4921.python-list at python.org...
>     ...
> > def Thing.new_method(self, x):
>     ...
> > It never caught on, but this was in the (way) pre-PEP days.  If
> > there's interest, I could write up a PEP on this.
>
> FWIW, I'd *LOVE* it if there was some relaxation of the
> current constraint that binding-statements (except assignment,
> and package-related import) can only affect 'bare' (unqualified)
> identifiers.  It *IS* (from my POV) a wart (albeit a minor one)
> that, to rebind anything BUT a bare identifier by class/def/import/
> from I must do a three-step -- first use the statement to bind a
> 'temporary' bare-identifier, then assign the bare-identifier
> to what I *really* want to bind, finally del the temp id.
>
> I understand that packages mean "import x.y" has very special
> meaning, of course -- but "import x as y.z", "from x import
> y as z.t", "def x.y", and "class x.y" all seem so natural to
> me, so typically Pythonic, that I do not really understand
> why they are currently forbidden in favour of, e.g.:
>     from x import y as temporaryname
>     z.t = temporaryname
>     del temporaryname
> and the like.  Where's the added-value in this restriction...?
>
> So, yes, I'd *LOVE* it if a PEP could remove at least SOME
> of these constraints -- I just hope it doesn't have to be
> as narrowly-worded as "allowing def x.y iff x is specifically
> a bare identifier that is bound to a class-object and is
> also the class's classname"...:-).  That may be the TYPICAL
> use, of course, but hopefully it need not be so tightly
> restricted again...?
>
>
> Alex
>
>
>