On 10/17/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I'm not sure if you'll like it any better, but I combined Michael
> Urman's suggestion with my late-binding property recipe to get:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/442418
> It solves the name-repetition problem a
Barry Warsaw wrote:
> On Mon, 2005-10-17 at 21:55, Guido van Rossum wrote:
>
> > Let's change the property built-in so that its arguments can be either
> > functions or strings (or None). If they are functions or None, it
> > behaves exactly like it always has.
> >
> > If an argument is a string, i
At 08:46 PM 10/17/2005 -0700, Guido van Rossum wrote:
>Now, if I were to follow Paul Graham's recommendations strictly
>(http://www.paulgraham.com/diff.html), point 7 saysthat Python should
>have a symbol type. I've always maintained that this is unnecessary
>and that we can just as well use regula
On Mon, Oct 17, 2005, Guido van Rossum wrote:
>
> If an argument is a string, it should be a method name, and the method
> is looked up by that name each time the property is used. Because this
> is late binding, it can be put before the method definitions, and a
> subclass can override the methods
[Barry]
> > > IMO, there's not enough advantage in having the property() call before
> > > the functions than after.
[Guido]
> > Maybe you didn't see the use case that Greg had in mind? He wants to
> > be able to override the getter and/or setter in a subclass, without
> > changing the docstring o
On Mon, 2005-10-17 at 22:24, Guido van Rossum wrote:
> > IMO, there's not enough advantage in having the property() call before
> > the functions than after.
>
> Maybe you didn't see the use case that Greg had in mind? He wants to
> be able to override the getter and/or setter in a subclass, with
[Guido]
> > Let's change the property built-in so that its arguments can be either
> > functions or strings (or None). If they are functions or None, it
> > behaves exactly like it always has.
> >
> > If an argument is a string, it should be a method name, and the method
> > is looked up by that na
Barry Warsaw wrote:
> Ick, for all the reasons that strings are less appealing than names.
> IMO, there's not enough advantage in having the property() call before
> the functions than after.
That's not the only benefit - you also get overridability
of the accessor methods.
--
Greg Ewing, Comp
On Mon, 2005-10-17 at 21:55, Guido van Rossum wrote:
> Let's change the property built-in so that its arguments can be either
> functions or strings (or None). If they are functions or None, it
> behaves exactly like it always has.
>
> If an argument is a string, it should be a method name, and t
Guido van Rossum wrote:
> Let's change the property built-in so that its arguments can be either
> functions or strings (or None).
>
> If an argument is a string, it should be a method name, and the method
> is looked up by that name each time the property is used.
That sounds reasonable.
--
G
[Guido]
> > I looked at that, and now I believe it's actually *better* to mention
> > the property name twice, at least compared to Tim' s approach.
[Greg Ewing]
> I'm inclined to agree. Passing functions that you're not
> going to use as functions but just use the name of doesn't
> seem right.
>
Guido van Rossum wrote:
> With decorators there was a concrete issue: the modifier trailed after
> the function body, in a real sense "hiding" from the reader.
A similar thing happens with properties, the property
definition (which is the public interface) trailing
after the accessor methods (whi
Neal Norwitz wrote:
> We all know Guido likes Python. But the real question is do pythons like
> Guido?
>
> http://python.org/neal/
??? I get a 404 for this.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZ
Neal> This URL should work for a while longer.
Neal> http://creosote.python.org/neal/
Ah, the vagaries of URL redirection. Thanks...
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
At 11:56 AM +0200 10/16/05, Martin v. Löwis wrote:
>Tony Nelson wrote:
>> BTW, Martin, if you care to, would you explain to me how a Trie would be
>> used for charmap encoding? I know a couple of approaches, but I don't know
>> how to do it fast. (I've never actually had the occasion to use a Tri
On 10/17/05, Tim Peters <[EMAIL PROTECTED]> wrote:
[Skip]> Like Steve (and unlike Oleg), I get 404s for this page. I also tried> "www.python.org" and "~neal".The original
http://python.org/neal/ worked fine for me, and still does. OTOH, http://www.python.org/neal/gets a 404, and (the orig
For communicating with an exec/eval child, once exec
cannot run in the current namespace, I asked that it be
possible to pass a read-only "current view" and to see
a return value.
(Guido):
>... it's probably better to create an empty namespace and
> explicitly copy into it ...
> ... just pick cer
Hi Jeremy,
On Thu, Oct 13, 2005 at 04:52:14PM -0400, Jeremy Hylton wrote:
> I don't think the current test suite covers all of the possible syntax
> errors that can be raised. I'd like to add a new test suite that
> covers all of the remaining cases, perhaps moving some existing tests
> into this
[Skip]
> Like Steve (and unlike Oleg), I get 404s for this page. I also tried
> "www.python.org" and "~neal".
The original
http://python.org/neal/
worked fine for me, and still does. OTOH,
http://www.python.org/neal/
gets a 404, and (the original without the trailing backslash)
[EMAIL PROTECTED] wrote:
> Neal> We all know Guido likes Python. But the real question is do
> Neal> pythons like Guido?
>
> Neal> http://python.org/neal/
>
> Like Steve (and unlike Oleg), I get 404s for this page. I also tried
> "www.python.org" and "~neal".
>
This appears to b
Neal> We all know Guido likes Python. But the real question is do
Neal> pythons like Guido?
Neal> http://python.org/neal/
Like Steve (and unlike Oleg), I get 404s for this page. I also tried
"www.python.org" and "~neal".
Skip
___
Pyt
On 10/17/05, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Another idea might be to change the exec() spec so that you are
> > required to pass in a namespace (and you can't use locals() either!).
> > Then the whole point becomes moot.
>
> I think of exec as having two major
On 10/17/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Ah well, another idea runs aground on the harsh rocks of reality.
I should point out that it's intentional that there are very few
similarities between modules and classes. Many attempts have been made
to unify the two, but these never work ri
Guido van Rossum wrote:
> Another idea might be to change the exec() spec so that you are
> required to pass in a namespace (and you can't use locals() either!).
> Then the whole point becomes moot.
I think of exec as having two major uses:
(1) A run-time compiler
(2) A way to change the local
On Mon, Oct 17, 2005 at 12:55:00PM +0100, Steve Holden wrote:
> > http://python.org/neal/
> >
> Getting a 404 on this one right now.
No problems here, very nice fotos! :)
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die
Neal Norwitz wrote:
> We all know Guido likes Python. But the real question is do pythons like
> Guido?
>
> http://python.org/neal/
>
Neal:
Getting a 404 on this one right now.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.ho
Steven Bethard wrote:
> Nick Coghlan wrote:
>> Having module attribute access obey the descriptor protocol (__get__,
>> __set__,
>> __delete__) sounds like a pretty good option to me.
>>
>> It would even be pretty backwards compatible, as I'd be hardpressed to think
>> why anyone would have a desc
Andrew Koenig wrote:
>> PEP 343 has been updated on python.org.
>
>> Highlights of the changes:
>
>>- changed the name of the PEP to be simply "The 'with' Statement"
>
> Do you mean PEP 346, perchance? PEP 343 is something else entirely.
No, I mean PEP 343 - it describes Guido's proposal f
Guido van Rossum wrote:
> On 10/16/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I hope you reverted the status to "Proposed"...
I hadn't, but I've now fixed that in CVS (both in the PEP and the PEP index),
and added some text into the PEP saying why it was reverted to Draft.
> On the latter: I
Michael Urman wrote:
> class Test(object):
> class foo(Property):
> """The foo property"""
> def get(self): return self._foo
> def set(self, val): self._foo = val
> def delete(self): del self._foo
>
> test = Test()
> test.foo = 'Yay!'
> assert test._foo == 'Yay!
On 10/16/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 10/10/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > There's a problem with genexp's that I think really needs to get
> > fixed. See http://python.org/sf/1167751 the details are below. This
> > code:
> >
> > >>> foo(a = i for i in range(1
On 10/16/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> On and off, I've been looking for an elegant way to handle properties using
> decorators.
Why use decorators when a metaclass will already do the trick, and
save you a line? This doesn't necessarily get around Antoine's
complaint that it looks
32 matches
Mail list logo
