Marko Rauhamaa wrote:
> What's the inherent difference between an attribute and a key.
Here is my bucket. The handle of the bucket is part of the bucket:
bucket.handle
The pieces of coal I carry in the bucket is part of its content:
bucket['coal']
Of course, we can blur the distinction betw
On 2014-08-05 14:19, Marko Rauhamaa wrote:
Skip Montanaro :
On Tue, Aug 5, 2014 at 7:04 AM, Marko Rauhamaa wrote:
I wonder if that should be built into dict.
Short answer, no. I'm sure it's been proposed before. Attributes ≠
keys. When you see something.somethingelse anywhere else in Python
Skip Montanaro :
> On Tue, Aug 5, 2014 at 7:04 AM, Marko Rauhamaa wrote:
>> I wonder if that should be built into dict.
>
> Short answer, no. I'm sure it's been proposed before. Attributes ≠
> keys. When you see something.somethingelse anywhere else in Python,
> "somethingelse" is an attribute re
On Tue, Aug 5, 2014 at 10:43 PM, Steven D'Aprano
wrote:
> Because it's horrible and a bad idea.
>
> d = {'this': 23, 'word': 42, 'frog': 2, 'copy': 15, 'lunch': 93}
> e = d.copy()
>
> Traceback (most recent call last):
> File "", line 1, in ?
> TypeError: 'int' object is not callable
>
>
> Confl
On Tue, Aug 5, 2014 at 10:31 PM, Skip Montanaro wrote:
> JavaScript objects have that feature. I find it mildly confusing
> because whenever I see it I have to pause to consider whether the name
> I am looking at is an attribute or a key. This little JS code I just
> typed at my console prompt was
Marko Rauhamaa wrote:
> Why can't I have:
>
>>>> d = {}
>>>> d.x = 3
>>>> d
>{'x': 3}
Because it's horrible and a bad idea.
d = {'this': 23, 'word': 42, 'frog': 2, 'copy': 15, 'lunch': 93}
e = d.copy()
Traceback (most recent call last):
File "", line 1, in ?
TypeError: 'int'
On Tue, Aug 5, 2014 at 7:04 AM, Marko Rauhamaa wrote:
>
> I wonder if that should be built into dict.
Short answer, no. I'm sure it's been proposed before. Attributes ≠
keys. When you see something.somethingelse anywhere else in Python,
"somethingelse" is an attribute reference. When you see
som
Brian Blais :
> class Struct(dict):
>
> def __getattr__(self,name):
>
> try:
> val=self[name]
> except KeyError:
> val=super(Struct,self).__getattribute__(name)
>
> return val
>
> def __setattr__(self,name,val):
>
> self[name]=val
Co
On Sat, Aug 2, 2014 at 2:45 AM, Mark Summerfield wrote:
> Last week I spent a couple of days teaching two children (10 and 13 -- too
> big an age gap!) how to do some turtle graphics with Python. Neither had
> programmed Python before -- one is a Minecraft ace and the other had done
> Scratch.
On Sat, Aug 2, 2014 at 2:46 PM, Mark Summerfield wrote:
> On Saturday, 2 August 2014 20:58:59 UTC+1, Ben Finney wrote:
>> Steven D'Aprano writes:
>>
>> > If you need instances which carry state, then object is the wrong
>> > class.
>
> Fair enough.
>
>> Right. The 'types' module provides a Simple
On Sun, Aug 3, 2014 at 9:18 AM, Devin Jeanpierre wrote:
> On Sat, Aug 2, 2014 at 2:05 PM, Chris Angelico wrote:
>> On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield wrote:
>>> Naturally, I understand that adding a new name is a big deal and may be too
>>> much to ask for beginners.
>>
>> This is
On 8/2/2014 4:03 AM, Mark Summerfield wrote:
On Saturday, 2 August 2014 08:46:04 UTC+1, Mark Lawrence wrote:
On 02/08/2014 07:45, Mark Summerfield wrote:
Summarizing my responses on the tracker...
Suggestion #1: Make IDLE start in the user's home directory.
Entirely agree. Please raise a
On Sat, Aug 2, 2014 at 2:05 PM, Chris Angelico wrote:
> On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield wrote:
>> Naturally, I understand that adding a new name is a big deal and may be too
>> much to ask for beginners.
>
> This is where you might want to consider putting some imports into
> si
On 8/2/2014 3:46 AM, Mark Lawrence wrote:
On 02/08/2014 07:45, Mark Summerfield wrote:
Last week I spent a couple of days teaching two children (10 and 13 --
too big an age gap!) how to do some turtle graphics with Python.
Neither had programmed Python before -- one is a Minecraft ace and the
ot
On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield wrote:
> But perhaps what I should be asking for is for a new built-in that does what
> types.SimpleNamespace() does, so that without any import you can write, say,
>
> foo = namespace(a=1, b=2)
> # or
> bar = namespace()
> bar.a = 1
>
> where unde
On Saturday, 2 August 2014 20:58:59 UTC+1, Ben Finney wrote:
> Steven D'Aprano writes:
>
> > If you need instances which carry state, then object is the wrong
> > class.
Fair enough.
> Right. The 'types' module provides a SimpleNamespace class for the
> common "bag of attributes" use case::
>
Steven D'Aprano writes:
> If you need instances which carry state, then object is the wrong
> class.
Right. The ‘types’ module provides a SimpleNamespace class for the
common “bag of attributes” use case::
>>> import types
>>> foo = types.SimpleNamespace()
>>> foo.x = 3
>>> foo
Mark Lawrence :
> On 02/08/2014 18:07, Marko Rauhamaa wrote:
>> And the newest Python releases let you replace that with:
>>
>> import types
>> Object = types.SimpleNamespace
>
> With the latter being part of suggestion #3 in the original post.
Not quite. Even though Sugg. #3 would allow
On 02/08/2014 18:07, Marko Rauhamaa wrote:
Steven D'Aprano :
Marko Rauhamaa wrote:
__setattr__ could create __dict__ belatedly.
Are we designing Son Of PHP, or a sensible language? *wink*
If object.__setattr__ did this, then we're left with two equally
horrible choices:
Not a huge issue.
Steven D'Aprano :
> Marko Rauhamaa wrote:
>> __setattr__ could create __dict__ belatedly.
>
> Are we designing Son Of PHP, or a sensible language? *wink*
>
> If object.__setattr__ did this, then we're left with two equally
> horrible choices:
Not a huge issue. Only mildly annoying to have to crea
Marko Rauhamaa wrote:
> Mark Summerfield :
>
>> object() returns a minimal featureless object with no dictionary (no
>> __dict__ attribute). This makes sense for efficiency since not all
>> objects need a dictionary.
>
> __setattr__ could create __dict__ belatedly.
Are we designing Son Of PHP,
Marko Rauhamaa wrote:
> Expanding #3:
>
>>>> o = object()
>>>> o.x = 3
>Traceback (most recent call last):
> File "", line 1, in
>AttributeError: 'object' object has no attribute 'x'
>
> Why?
There are two intended uses for object and its instances:
- as the base class fo
On Saturday, 2 August 2014 08:46:04 UTC+1, Mark Lawrence wrote:
> On 02/08/2014 07:45, Mark Summerfield wrote:
>
[snip]
>
> > Suggestion #1: Make IDLE start in the user's home directory.
>
> Entirely agree. Please raise an enhancement request on the bug tracker
> if there isn't already one.
Mark Summerfield :
> object() returns a minimal featureless object with no dictionary (no
> __dict__ attribute). This makes sense for efficiency since not all
> objects need a dictionary.
__setattr__ could create __dict__ belatedly.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On 02/08/2014 07:45, Mark Summerfield wrote:
Last week I spent a couple of days teaching two children (10 and 13 -- too big
an age gap!) how to do some turtle graphics with Python. Neither had programmed
Python before -- one is a Minecraft ace and the other had done Scratch.
Suggestion #1: Mak
On Saturday, 2 August 2014 08:14:08 UTC+1, Marko Rauhamaa wrote:
> Mark Summerfield:
>
> > Suggestion #1: Make IDLE start in the user's home directory.
>
> > Suggestion #2: Make all the turtle examples begin "from turtle import
> > *" so no leading turtle. is needed in the examples.
> >
> > Sugge
Mark Summerfield :
> Suggestion #1: Make IDLE start in the user's home directory.
>
> Suggestion #2: Make all the turtle examples begin "from turtle import
> *" so no leading turtle. is needed in the examples.
>
> Suggestion #3: Make object(key=value, ...) legal and equiv of
> types.SimpleNamespac
Last week I spent a couple of days teaching two children (10 and 13 -- too big
an age gap!) how to do some turtle graphics with Python. Neither had programmed
Python before -- one is a Minecraft ace and the other had done Scratch.
Suggestion #1: Make IDLE start in the user's home directory.
Sug
28 matches
Mail list logo
