Brad Harms a écrit :
On Fri, 04 Dec 2009 18:05:03 +1100, Ben Finney wrote:
(snip)
2.) Attributes whose values are determined or assigned dynamically by
indirectly calling a function (like properties and instancemethods)
Yes, the term “property” seems to do what you want.
I wasn't asking what
Ben Finney a écrit :
Brad Harms writes:
(snip)
2.) Attributes whose values are determined or assigned dynamically by
indirectly calling a function (like properties and instancemethods)
Yes, the term “property” seems to do what you want.
The property type is just one possible application o
Brad Harms a écrit :
On Tue, 2009-12-01 at 16:58 +0100, Bruno Desthuilliers wrote:
The Music Guy a écrit :
(snip)
Lie Ryan, I think I see what you're saying about using __dict__ to add
members
No "members" in Python - only attributes.
to a class, but it's not quite the same. __dict__ is onl
On Thu, 03 Dec 2009 23:12:39 -0600, Brad Harms wrote:
> On Tue, 2009-12-01 at 14:38 +, Steven D'Aprano wrote:
[...]
>> It's just special double-underscore methods like __init__ __add__ etc
>> that have to be in the class rather than the instance. (To be precise,
>> you can add such a method to
On Fri, 04 Dec 2009 09:00:42 +, Steven D'Aprano wrote:
> Not all such attributes are actually found in instance.__dict__.
...I hadn't even considered __slots__ yet. Hm...
> Or dynamic attributes returned by __getattr__ or __getattribute__.
I'm looking for a generic term, because it's too cum
On Fri, 04 Dec 2009 18:05:03 +1100, Ben Finney wrote:
> Brad Harms writes:
>
>> Anyway, it looks like the docs agree with you
>> (http://docs.python.org/glossary.html#term-attribute), so I'm not going
>> to argue.
>
> That's good, because the terms are quite well established in Python
> termino
On Fri, 04 Dec 2009 18:05:03 +1100, Ben Finney wrote:
> Brad Harms writes:
...
>> 1.) "Regular" attributes, ie. those that are shortcuts to items in the
>> directly associated object's __dict__,
>
> I don't know what you mean by “shortcuts to items”. The names are looked
> up in dictionaries; wh
Brad Harms writes:
> Anyway, it looks like the docs agree with you
> (http://docs.python.org/glossary.html#term-attribute), so I'm not
> going to argue.
That's good, because the terms are quite well established in Python
terminology.
> However, for the purpose of clean communication, I'd still
On Tue, 2009-12-01 at 14:38 +, Steven D'Aprano wrote:
> On Mon, 30 Nov 2009 18:55:46 -0800, The Music Guy wrote:
>
> > Lie Ryan, I think I see what you're saying about using __dict__ to add
> > members to a class, but it's not quite the same. __dict__ is only for
> > attributes, NOT properties
On Tue, 2009-12-01 at 16:58 +0100, Bruno Desthuilliers wrote:
> The Music Guy a écrit :
> (snip)
> > Lie Ryan, I think I see what you're saying about using __dict__ to add
> > members
>
> No "members" in Python - only attributes.
> > to a class, but it's not quite the same. __dict__ is only for
>
On Tue, 2009-12-01 at 14:38 +, Steven D'Aprano wrote:
> On Mon, 30 Nov 2009 18:55:46 -0800, The Music Guy wrote:
>
> > Lie Ryan, I think I see what you're saying about using __dict__ to add
> > members to a class, but it's not quite the same. __dict__ is only for
> > attributes, NOT properties
On Dec 1, 10:21 am, Raymond Hettinger wrote:
> [Gregory Ewing]
>
> > >>I just posted to my blog about a feature that I'd like to see added to
> > >>Python.
>
> > >>http://alphaios.blogspot.com/2009/11/python-string-inferred-names-wor...
>
> > I don't think getattr and setattr are used anywhere nea
[Gregory Ewing]
> >>I just posted to my blog about a feature that I'd like to see added to
> >>Python.
>
> >>http://alphaios.blogspot.com/2009/11/python-string-inferred-names-wor...
>
> I don't think getattr and setattr are used anywhere near
> frequently enough to justify special syntax.
Perhaps
The Music Guy a écrit :
(snip)
Lie Ryan, I think I see what you're saying about using __dict__ to add
members
No "members" in Python - only attributes.
to a class, but it's not quite the same. __dict__ is only for
attributes, NOT properties, methods, etc. which all come from the
class of an o
On Mon, 30 Nov 2009 18:55:46 -0800, The Music Guy wrote:
> Lie Ryan, I think I see what you're saying about using __dict__ to add
> members to a class, but it's not quite the same. __dict__ is only for
> attributes, NOT properties, methods, etc. which all come from the class
> of an object rather
> Brad Harms FearsomeDragonfly at gmail.com
> Mon Nov 30 05:04:37 CET 2009
>
> That was a relatively simple example; classes as simple as the ones
> generated by the It is more likely that the class generation could would
> appear in a metaclass's class constructor or decorator function, and there
Brad Harms wrote:
Well, yes, the names would have to be determined at run time. That's
what getattr and setattr do, except that that do it in the context of an
object rather than the local scope. However, I was under the impression
that python's mechanism for looking up local names was the sam
On 12/1/2009 3:35 AM, Bruno Desthuilliers wrote:
Lie Ryan a écrit :
On 11/28/2009 3:08 PM, The Music Guy wrote:
(snip the part about the proposed feature - which I don't like but
that's not the point)
My
projects rely on a lot of metaclassing for the automatic generation of
properties and me
Lie Ryan a écrit :
On 11/28/2009 3:08 PM, The Music Guy wrote:
(snip the part about the proposed feature - which I don't like but
that's not the point)
My
projects rely on a lot of metaclassing for the automatic generation of
properties and methods, which saves tremendous amounts of coding.
P.S., not trying to start a flame war. It's just that I can't stand to
keep silent on the matter any longer.
-- Brad Harms
--
http://mail.python.org/mailman/listinfo/python-list
Cameron Simpson writes:
> The Zen promotes the guideline that there should be only one (obvious)
> way to do most things and that's a surprisingly effective design rule.
It's also important to realise that the Zen places the “preferably only
one” in a parenthetical, and note that “preferably” qu
Lie Ryan a écrit :
(snip)
> setattr, getattr, and delattr are already sugar for accessing
instance.__dict__.
They are actually much more than that - else descriptors and inheritance
wouldn't work.
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, Nov 29, 2009 at 11:01 PM, Brad Harms wrote:
>
> May the Penguin in the sky bless your every subroutine,
>
Um...feel free to ignore that. >_>
-- Brad Harms
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, Nov 29, 2009 at 9:59 PM, Carl Banks wrote:
> Another thing that can be determined through common sense is that if
> you have object that you are calling getattr and setattr on so much
> that you think you need special syntax, you should have been using a
> dict.
>
(Re-send; original was s
On Sun, Nov 29, 2009 at 7:49 PM, Lie Ryan wrote:
> On 11/29/2009 12:22 PM, The Music Guy wrote:
>
>> When I first started seeing @ show up in Python code, I said "what the
>> heck is that? It looks so weird and _ugly_.I would never try to mess
>> with that." But I started seeing it more and more,
On Nov 28, 3:38 am, The Music Guy wrote:
> On Nov 28, 3:07 am, Lie Ryan wrote:
> > If you use it a lot, it is likely 1) you have abused class syntax for
> > what should have been a dict or 2) what you need is to override
> > __getattr__/__getattribute__ and __setattr__
>
> Oh boy...here we go. :|
On Nov 26, 3:43 pm, The Music Guy wrote:
> That aside, I still feel that a new syntax would be a better solution
> than a new class. And, anyway, what I'm proposing isn't *quite* the
> same as what Ben North proposed. Ben's idea was *strictly* to create
> shorthand syntax to the getattr/setattr/de
On 11/29/2009 12:22 PM, The Music Guy wrote:
When I first started seeing @ show up in Python code, I said "what the
heck is that? It looks so weird and _ugly_.I would never try to mess
with that." But I started seeing it more and more, so I asked #python
what it was. They told me about decorators
The Music Guy wrote:
When I first started seeing @ show up in Python code, I said "what the
heck is that?
For future reference, PySymbols.html at
http://code.google.com/p/xploro/downloads/list
answers all such symbol questions.
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, Nov 29, 2009 at 6:58 AM, inhahe wrote:
> Did you say you were using gmail to post? I think mailing lists tend to
> have issues with gmail because it puts html in the message or something like
> that. Btw I recently set up this mailing list to send me a message back
> when I successfully
On Sun, Nov 29, 2009 at 5:15 AM, The Music Guy
wrote:
> Okay, I'm having a really hard time telling which messages are getting
> on to the list and which ones aren't. Some of the messages I send show
> up in the comp.lang.python mirror in Google Groups, and some aren't.
> Others show up on the Gro
Okay, I'm having a really hard time telling which messages are getting
on to the list and which ones aren't. Some of the messages I send show
up in the comp.lang.python mirror in Google Groups, and some aren't.
Others show up on the Groups mirror, but don't show up in Gmail, or
show up in a differe
>
>
On Sat, Nov 28, 2009 at 9:39 PM, Steven D'Aprano <
st...@remove-this-cybersource.com.au> wrote:
>
> Removing code redundancy is all very well, but beware of turning into an
>
>> architecture astronaut:
>
>>
> http://www.joelonsoftware.com/articles/fog18.html
>
>>
> There is such a thin
i like this idea (i posted some thoughts on it in the blog, but it's not
approved yet as of this writing)
in short, i suggested extending the idea to make it more a) generalized, b)
simple, c) intuitive, and d) flexible.
so instead of just using $ for attributes, you could use it anywhere you
def
On Sat, 28 Nov 2009 17:22:27 -0800, The Music Guy wrote:
> As for my specific use case, it's somewhat difficult to explain. The
> general idea was to isolate a pattern that I spotted repeated in several
> unrelated parts of my project. The pattern manifested itself as a set of
> 4-5 methods and/or
On Nov 28, 6:10 am, Lie Ryan wrote:
> On 11/28/2009 10:38 PM, The Music Guy wrote:
>
> >> If you use it a lot, it is likely 1) you have abused class syntax for
> >> what should have been a dict or 2) what you need is to override
> >> __getattr__/__getattribute__ and __setattr__
>
> > Oh boy...here
On Sat, 28 Nov 2009 03:38:38 -0800, The Music Guy wrote:
> Please listen. In all the time I've spent in the coding community
> (that's at least 7 years) and especially since I started paying
> attention to the Python community (2 years), I have noticed a trend:
> When one coder does something that
On Nov 28, 6:10 am, Lie Ryan wrote:
> On 11/28/2009 10:38 PM, The Music Guy wrote:
>
> >> If you use it a lot, it is likely 1) you have abused class syntax for
> >> what should have been a dict or 2) what you need is to override
> >> __getattr__/__getattribute__ and __setattr__
>
> > Oh boy...here
On 11/28/2009 10:38 PM, The Music Guy wrote:
If you use it a lot, it is likely 1) you have abused class syntax for
what should have been a dict or 2) what you need is to override
__getattr__/__getattribute__ and __setattr__
Oh boy...here we go. :|
ok, then what's your use case, AFAICT in the
The Music Guy writes:
> Please listen. In all the time I've spent in the coding community
> (that's at least 7 years) and especially since I started paying
> attention to the Python community (2 years), I have noticed a trend:
> When one coder does something that another cannot understand,
> freq
On Nov 28, 3:07 am, Lie Ryan wrote:
> On 11/28/2009 3:08 PM, The Music Guy wrote:
>
> > As for your code, I haven't seen it, so it would be hard for me to say
> > exactly how the new syntax would come into play. What I can tell you,
> > however, is that the parts of your code that would use it wou
On Fri, 27 Nov 2009 20:02:31 -0800, The Music Guy wrote:
> That PEP seems to pretty clearly state that it applies only to the 3.x
> branch and not to the 2.x branch. Is there maybe a slim chance of
> getting my idea added to 2.7, or even 2.8? :D
The only new features being added to 2.7 are featu
On 11/28/2009 3:08 PM, The Music Guy wrote:
As for your code, I haven't seen it, so it would be hard for me to say
exactly how the new syntax would come into play. What I can tell you,
however, is that the parts of your code that would use it would
probably be easier to read and change to anyone
Gred, thanks for your comments.
On Nov 26, 7:49 pm, Gregory Ewing wrote:
>
> [...] Also, many of the uses of getattr in the std lib appear
> to be of the 3-argument form, which your suggested syntax
> doesn't cover. [...]
Good point. After excluding those, only ~435 uses would work for my
propos
On Nov 26, 9:10 pm, "Gabriel Genellina"
wrote:
> En Thu, 26 Nov 2009 20:43:04 -0300, The Music Guy
> escribió:
>
> > Nonetheless, the fact remains that the feature I'm proposing closely
> > resembles one that has already been rejected... Well, it's been a few
> > years since then. Maybe its abo
Testing, testing...is this thing on? Hang on guys, I'm having some
trouble posting to the mailing list suddenly.
--
http://mail.python.org/mailman/listinfo/python-list
En Thu, 26 Nov 2009 20:43:04 -0300, The Music Guy
escribió:
Nonetheless, the fact remains that the feature I'm proposing closely
resembles one that has already been rejected... Well, it's been a few
years since then. Maybe its about time for another PEP to be proposed?
You'll have to wait a
The Music Guy wrote:
As for it not being useful enough to justify new syntax, well, I think
Ben showed pretty well that it actually is. Approximately 600 uses of
the get*r functions were used in the Python 2.5 standard library
alone.
The standard library isn't necessarily representative of
Pyt
On 25Nov2009 21:45, Brad wrote:
| On Nov 25, 10:49 pm, Chris Rebert wrote:
| > On Wed, Nov 25, 2009 at 6:35 PM, The Music Guy
| > wrote:
| > > I just posted to my blog about a feature that I'd like to see added to
| > > Python. Before I go through the trouble of learning how to write a PEP or
|
The Music Guy writes:
> Nonetheless, the fact remains that the feature I'm proposing closely
> resembles one that has already been rejected... Well, it's been a few
> years since then.
The passage of time is insufficient. The idea also needs to have greater
merit now than before. You haven't dem
On Nov 27, 10:43 am, The Music Guy wrote:
[snip]
> Nonetheless, the fact remains that the feature I'm proposing closely
> resembles one that has already been rejected... Well, it's been a few
> years since then. Maybe its about time for another PEP to be proposed?
Judging by the response you've
On Nov 26, 12:30 am, "Gabriel Genellina"
wrote:
> En Wed, 25 Nov 2009 23:35:06 -0300, The Music Guy
> escribió:
>
> > I just posted to my blog about a feature that I'd like to see added to
> > Python. Before I go through the trouble of learning how to write a PEP or
> > how to extend the Python
Gregory Ewing wrote:
On Wed, 25 Nov 2009 20:44:36 -0600, The Music Guy
declaimed the following in
gmane.comp.python.general:
I just posted to my blog about a feature that I'd like to see added to
Python.
http://alphaios.blogspot.com/2009/11/python-string-inferred-names-working.html
I don'
On Wed, 25 Nov 2009 20:44:36 -0600, The Music Guy
declaimed the following in
gmane.comp.python.general:
I just posted to my blog about a feature that I'd like to see added to
Python.
http://alphaios.blogspot.com/2009/11/python-string-inferred-names-working.html
I don't think getattr and seta
Brad wrote:
On Nov 25, 10:49 pm, Chris Rebert wrote:
On Wed, Nov 25, 2009 at 6:35 PM, The Music Guy
wrote:
Hello all,
I just posted to my blog about a feature that I'd like to see added to
Python. Before I go through the trouble of learning how to write a PEP or
how to extend the Python inte
En Wed, 25 Nov 2009 23:35:06 -0300, The Music Guy
escribió:
I just posted to my blog about a feature that I'd like to see added to
Python. Before I go through the trouble of learning how to write a PEP or
how to extend the Python interpreter, I want to know what people in the
community have t
P.S., my apologies for sending replies with different email addresses. This
is an unintentional technical issue and I am currently trying to get it
fixed.
On Wed, Nov 25, 2009 at 11:45 PM, Brad wrote:
> On Nov 25, 10:49 pm, Chris Rebert wrote:
> > On Wed, Nov 25, 2009 at 6:35 PM, The Music Guy
On Nov 25, 10:49 pm, Chris Rebert wrote:
> On Wed, Nov 25, 2009 at 6:35 PM, The Music Guy
>
> wrote:
> > Hello all,
>
> > I just posted to my blog about a feature that I'd like to see added to
> > Python. Before I go through the trouble of learning how to write a PEP or
> > how to extend the Pyth
On Wed, Nov 25, 2009 at 6:35 PM, The Music Guy
wrote:
> Hello all,
>
> I just posted to my blog about a feature that I'd like to see added to
> Python. Before I go through the trouble of learning how to write a PEP or
> how to extend the Python interpreter, I want to know what people in the
> comm
I just posted to my blog about a feature that I'd like to see added to
Python. Before I go through the trouble of learning how to write a PEP or
how to extend the Python interpreter, I want to know what people in the
community have to say about it.
http://alphaios.blogspot.com/2009/11/python-strin
Hello all,
I just posted to my blog about a feature that I'd like to see added to
Python. Before I go through the trouble of learning how to write a PEP or
how to extend the Python interpreter, I want to know what people in the
community have to say about it.
http://alphaios.blogspot.com/2009/11/
61 matches
Mail list logo
