Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #75517 > unrolled thread

3 Suggestions to Make Python Easier For Children

Back to article view | Back to comp.lang.python

Contents

  3 Suggestions to Make Python Easier For Children Mark Summerfield <list@qtrac.plus.com> - 2014-08-01 23:45 -0700
    Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-02 10:14 +0300
      Re: 3 Suggestions to Make Python Easier For Children Mark Summerfield <list@qtrac.plus.com> - 2014-08-02 00:38 -0700
        Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-02 11:03 +0300
          Re: 3 Suggestions to Make Python Easier For Children Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-03 02:00 +1000
            Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-02 20:07 +0300
              Re: 3 Suggestions to Make Python Easier For Children Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-02 18:29 +0100
                Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-02 21:33 +0300
      Re: 3 Suggestions to Make Python Easier For Children Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-03 01:43 +1000
        Correct type for a simple “bag of attributes” namespace object (was: 3 Suggestions to Make Python Easier For Children) Ben Finney <ben+python@benfinney.id.au> - 2014-08-03 05:58 +1000
          Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children) Mark Summerfield <list@qtrac.plus.com> - 2014-08-02 13:46 -0700
            Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children) Chris Angelico <rosuav@gmail.com> - 2014-08-03 07:05 +1000
            Re: Correct type for a simple "bag of attributes" namespace object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-02 22:16 +0100
            Re: Correct type for a simple "bag of attributes" namespace object Chris Angelico <rosuav@gmail.com> - 2014-08-03 07:24 +1000
            Re: Correct type for a simple "bag of attributes" namespace object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-02 22:23 +0100
            Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children) Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-08-02 16:18 -0700
            Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children) Chris Angelico <rosuav@gmail.com> - 2014-08-03 09:27 +1000
            Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children) Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-02 18:59 -0600
            Re: Correct type for a simple "bag of attributes" namespace object Terry Reedy <tjreedy@udel.edu> - 2014-08-02 22:40 -0400
            Re: Correct type for a simple "bag of attributes" namespace object Terry Reedy <tjreedy@udel.edu> - 2014-08-02 22:43 -0400
            Re: Correct type for a simple "bag of attributes" namespace object Albert-Jan Roskam <fomcl@yahoo.com> - 2014-08-03 02:17 -0700
            Re: Correct type for a simple "bag of attributes" namespace object Peter Otten <__peter__@web.de> - 2014-08-03 11:37 +0200
            Re: Correct type for a simple "bag of attributes" namespace object Albert-Jan Roskam <fomcl@yahoo.com> - 2014-08-03 03:51 -0700
            Re: Correct type for a simple "bag of attributes" namespace object Albert-Jan Roskam <fomcl@yahoo.com> - 2014-08-03 04:14 -0700
            Re: Correct type for a simple "bag of attributes" namespace object Peter Otten <__peter__@web.de> - 2014-08-03 13:23 +0200
              Re: Correct type for a simple "bag of attributes" namespace object Marko Rauhamaa <marko@pacujo.net> - 2014-08-03 17:51 +0300
                Re: Correct type for a simple "bag of attributes" namespace object Roy Smith <roy@panix.com> - 2014-08-03 11:09 -0400
                  Re: Correct type for a simple "bag of attributes" namespace object Marko Rauhamaa <marko@pacujo.net> - 2014-08-03 18:52 +0300
                Re: Correct type for a simple "bag of attributes" namespace object Terry Reedy <tjreedy@udel.edu> - 2014-08-03 18:55 -0400
                  Re: Correct type for a simple "bag of attributes" namespace object Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-04 11:19 +1000
                    Re: Correct type for a simple "bag of attributes" namespace object Terry Reedy <tjreedy@udel.edu> - 2014-08-04 01:26 -0400
                Re: Correct type for a simple "bag of attributes" namespace object Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-04 10:13 +1000
                  Re: Correct type for a simple "bag of attributes" namespace object Roy Smith <roy@panix.com> - 2014-08-03 20:59 -0400
                  Re: Correct type for a simple "bag of attributes" namespace object Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-08-04 13:00 +1200
                  Re: Correct type for a simple "bag of attributes" namespace object Marko Rauhamaa <marko@pacujo.net> - 2014-08-04 08:41 +0300
                    Re: Correct type for a simple "bag of attributes" namespace object Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-04 00:41 -0600
                      Re: Correct type for a simple "bag of attributes" namespace object Marko Rauhamaa <marko@pacujo.net> - 2014-08-04 09:57 +0300
            Re: Correct type for a simple "bag of attributes" namespace object Akira Li <4kir4.1i@gmail.com> - 2014-08-03 18:22 +0400
        Re: Correct type for a simple “bag of attributes” namespace object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-03 13:28 +0100
          Re: Correct type for a simple “bag of attributes” namespace object Roy Smith <roy@panix.com> - 2014-08-03 08:40 -0400
            Re: Correct type for a simple “bag of attributes” namespace object Chris Angelico <rosuav@gmail.com> - 2014-08-03 22:56 +1000
              Re: Correct type for a simple “bag of attributes” namespace object Roy Smith <roy@panix.com> - 2014-08-03 09:25 -0400
                Re: Correct type for a simple “bag of attributes” namespace object Chris Angelico <rosuav@gmail.com> - 2014-08-03 23:35 +1000
                  Re: Correct type for a simple “bag of attributes” namespace object Roy Smith <roy@panix.com> - 2014-08-03 10:36 -0400
                    Re: Correct type for a simple “bag of attributes” namespace object Chris Angelico <rosuav@gmail.com> - 2014-08-04 01:00 +1000
        Re: Correct type for a simple “bag of attributes” namespace object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-03 18:38 +0100
          Re: Correct type for a simple “bag of attributes” namespace object Roy Smith <roy@panix.com> - 2014-08-03 13:44 -0400
    Re: 3 Suggestions to Make Python Easier For Children Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-02 08:46 +0100
      Re: 3 Suggestions to Make Python Easier For Children Mark Summerfield <list@qtrac.plus.com> - 2014-08-02 01:03 -0700
        Re: 3 Suggestions to Make Python Easier For Children Terry Reedy <tjreedy@udel.edu> - 2014-08-02 19:14 -0400
    Re: 3 Suggestions to Make Python Easier For Children Terry Reedy <tjreedy@udel.edu> - 2014-08-02 19:12 -0400
    Re: 3 Suggestions to Make Python Easier For Children Brian Blais <bblais@gmail.com> - 2014-08-05 07:36 -0400
      Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-05 15:04 +0300
        Re: 3 Suggestions to Make Python Easier For Children Skip Montanaro <skip@pobox.com> - 2014-08-05 07:31 -0500
          Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-05 16:19 +0300
            Re: 3 Suggestions to Make Python Easier For Children MRAB <python@mrabarnett.plus.com> - 2014-08-05 15:11 +0100
            Re: 3 Suggestions to Make Python Easier For Children Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-06 02:14 +1000
        Re: 3 Suggestions to Make Python Easier For Children Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-05 22:43 +1000
          Re: 3 Suggestions to Make Python Easier For Children Chris Angelico <rosuav@gmail.com> - 2014-08-05 23:08 +1000
        Re: 3 Suggestions to Make Python Easier For Children Chris Angelico <rosuav@gmail.com> - 2014-08-05 23:00 +1000

Page 3 of 3 — ← Prev page 1 2 [3]

#75594 — Re: Correct type for a simple “bag of attributes” namespace object

On Sun, Aug 3, 2014 at 10:40 PM, Roy Smith <roy@panix.com> wrote:
>  I usually just do:
>
> class Data:
>    pass
> my_obj = Data()
>
> That's all you really need.  It's annoying that you can't just do:
>
> my_obj = object()
>
> which would be even simpler, because (for reasons I don't understand),
> you can't create new attributes on my_obj.

Python 3.4 on Windows (32-bit):
>>> import sys
>>> class Data: pass
>>> sys.getsizeof(Data())
32
>>> sys.getsizeof(object())
8

Even before you add a single attribute, the object is four times the
size it needs to be. When you need a sentinel (for a function's
default argument, for instance), you don't need any attributes on it -
all you need is some object whose identity can be tested. And the
excess would be multiplied by a fairly large number of objects in the
system (it's not just object() that doesn't take attributes). If you
want a bag of attributes, get a bag of attributes, don't expect
object() to be it :) The only reason I can think of for expecting a
basic object to work this way is because of the parallel with
ECMAScript; it's not a fundamental part of the type hierarchy.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75595 — Re: Correct type for a simple “bag of attributes” namespace object

In article <mailman.12581.1407070605.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Sun, Aug 3, 2014 at 10:40 PM, Roy Smith <roy@panix.com> wrote:
> >  I usually just do:
> >
> > class Data:
> >    pass
> > my_obj = Data()
> >
> > That's all you really need.  It's annoying that you can't just do:
> >
> > my_obj = object()
> >
> > which would be even simpler, because (for reasons I don't understand),
> > you can't create new attributes on my_obj.
> 
> [...]
> The only reason I can think of for expecting a
> basic object to work this way is because of the parallel with
> ECMAScript; it's not a fundamental part of the type hierarchy.

I don't know about that.  I agree that your explanation about object 
size makes sense for why it wasn't built to work that way, but I don't 
think the expectation should be surprising.  When I write:

class Foo(Bar):
   # stuff

I'm saying, "make Foos be just like Bars, except for this stuff".  I can 
do:

>>> class Foo(object):
...     pass
... 
>>> f = Foo()
>>> f.x = 1

in which case, I've said, "make Foos just like objects, except for, oh, 
never mind, there aren't any differences".  But, in reality, the system 
bolted on the ability to have user-defined attributes without telling 
me.  I don't think it's unreasonable to be surprised at that.

[toc] | [prev] | [next] | [standalone]

#75596 — Re: Correct type for a simple “bag of attributes” namespace object

On Sun, Aug 3, 2014 at 11:25 PM, Roy Smith <roy@panix.com> wrote:
> in which case, I've said, "make Foos just like objects, except for, oh,
> never mind, there aren't any differences".  But, in reality, the system
> bolted on the ability to have user-defined attributes without telling
> me.  I don't think it's unreasonable to be surprised at that.

I agree that this is slightly surprising. However, imagine if it were
the other way:

class Foo(object):
    x = 1
    def __init__(self): self.y = 2

These would throw errors, unless you explicitly disable __slots__
processing. When there's two ways to do things and both would be
surprising, you pick the one that's going to be less of a surprise, or
surprising less often, and accept it. That doesn't mean it's not a
problem, but it's better than the alternative.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75601 — Re: Correct type for a simple “bag of attributes” namespace object

In article <mailman.12582.1407072928.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Sun, Aug 3, 2014 at 11:25 PM, Roy Smith <roy@panix.com> wrote:
> > in which case, I've said, "make Foos just like objects, except for, oh,
> > never mind, there aren't any differences".  But, in reality, the system
> > bolted on the ability to have user-defined attributes without telling
> > me.  I don't think it's unreasonable to be surprised at that.
> 
> I agree that this is slightly surprising. However, imagine if it were
> the other way:
> 
> class Foo(object):
>     x = 1
>     def __init__(self): self.y = 2
> 
> These would throw errors, unless you explicitly disable __slots__
> processing. When there's two ways to do things and both would be
> surprising, you pick the one that's going to be less of a surprise, or
> surprising less often, and accept it. That doesn't mean it's not a
> problem, but it's better than the alternative.
> 
> ChrisA

I'm not following you at all.  What does "the other way" mean, and how 
would that cause the above to generate errors, and what does this have 
to do with __slots__?

[toc] | [prev] | [next] | [standalone]

#75605 — Re: Correct type for a simple “bag of attributes” namespace object

On Mon, Aug 4, 2014 at 12:36 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.12582.1407072928.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>
>> On Sun, Aug 3, 2014 at 11:25 PM, Roy Smith <roy@panix.com> wrote:
>> > in which case, I've said, "make Foos just like objects, except for, oh,
>> > never mind, there aren't any differences".  But, in reality, the system
>> > bolted on the ability to have user-defined attributes without telling
>> > me.  I don't think it's unreasonable to be surprised at that.
>>
>> I agree that this is slightly surprising. However, imagine if it were
>> the other way:
>>
>> class Foo(object):
>>     x = 1
>>     def __init__(self): self.y = 2
>>
>> These would throw errors, unless you explicitly disable __slots__
>> processing. When there's two ways to do things and both would be
>> surprising, you pick the one that's going to be less of a surprise, or
>> surprising less often, and accept it. That doesn't mean it's not a
>> problem, but it's better than the alternative.
>>
>> ChrisA
>
> I'm not following you at all.  What does "the other way" mean, and how
> would that cause the above to generate errors, and what does this have
> to do with __slots__?

Fact #1: Some classes, like object, don't have a dictionary for
arbitrary attributes. (I'll call this __slots__ mode, although it's
not technically __slots__when it's a C-implemented class.)

Fact #2: You can subclass such objects.

There are two ways that this subclassing could be done. Either it
maintains __slots__ mode, which means you can see every change (and
going "class Foo(Bar): pass" will make an exact subclass of Bar with
identical behaviour), or it drops __slots__ and adds a dictionary
unless you explicitly reenable __slots__.

>>> class Base(object): __slots__ = ('a', 'b', 'c')
>>> class Deriv(Base): pass
>>> Base().d = 1
Traceback (most recent call last):
  File "<pyshell#71>", line 1, in <module>
    Base().d = 1
AttributeError: 'Base' object has no attribute 'd'
>>> Deriv().d = 1

Python opted to go with the second behaviour: the subclass is not
bound to the superclass's __slots__, but gets a dictionary unless it
itself specifies __slots__ (in which case it gets all of them,
parent's included):

>>> class SlottedDeriv(Base): __slots__ = ('d', 'e', 'f')
>>> SlottedDeriv().a = 1
>>> SlottedDeriv().d = 1
>>> SlottedDeriv().g = 1
Traceback (most recent call last):
  File "<pyshell#79>", line 1, in <module>
    SlottedDeriv().g = 1
AttributeError: 'SlottedDeriv' object has no attribute 'g'

The alternative would be for __slots__ to normally copy down, and to
have to be explicitly removed - for "pass" to be actually equivalent
to this:

>>> class Deriv(Base): __slots__ = Base.__slots__
>>> Deriv().d = 1
Traceback (most recent call last):
  File "<pyshell#82>", line 1, in <module>
    Deriv().d = 1
AttributeError: 'Deriv' object has no attribute 'd'

and for some other syntax to do what "pass" currently does. That has
the benefit of purity (it's easy to describe what happens, there's no
magic going on), but at the expense of practicality (you'd have to
explicitly de-slottify your classes before you can add functionality
to them). And we know what the Zen of Python says about which of those
takes priority.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75613 — Re: Correct type for a simple “bag of attributes” namespace object

On 02/08/2014 20:58, Ben Finney wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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
>      namespace(x=3)
>
> <URL:https://docs.python.org/3/library/types.html#types.SimpleNamespace>
>

A slight aside but from the link "SimpleNamespace may be useful as a 
replacement for class NS: pass."  I'm not quite sure how that class 
definition is meant to read, other than guessing that NS stands for 
NameSpace, any ideas?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#75614 — Re: Correct type for a simple “bag of attributes” namespace object

In article <mailman.12592.1407087500.18130.python-list@python.org>,
 Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:

> On 02/08/2014 20:58, Ben Finney wrote:
> > Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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
> >      namespace(x=3)
> >
> > <URL:https://docs.python.org/3/library/types.html#types.SimpleNamespace>
> >
> 
> A slight aside but from the link "SimpleNamespace may be useful as a 
> replacement for class NS: pass."  I'm not quite sure how that class 
> definition is meant to read, other than guessing that NS stands for 
> NameSpace, any ideas?

Trivia: argparse.ArgumentParser().parse_args() returns a Namespace.

[toc] | [prev] | [next] | [standalone]

#75523

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: 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.

>
> Suggestion #2: Make all the turtle examples begin "from turtle import *" so no leading turtle. is needed in the examples.

I'm not so sure about this, but raise an enhancement request and see 
what happens.  Worst case it gets rejected, best case it gets accepted, 
implemented and patch applied.

>
> Suggestion #3: Make object(key=value, ...) legal and equiv of types.SimpleNamespace(key=value, ...).

Haven't the faintest idea and too lazy to find out :)  I suggest follow 
advice from #2.

>
> Explanation & Rationale (long):
>
> They both had Windows laptops and so we began by installing Python. They didn't know if they had 32- or 64-bit computers but it didn't matter, the installs just worked. One child had no problem but the other ended up on the Download page which lists all the possible Windows downloads; so we had to go back and start again.
>
> We discovered that IDLE's working directory is C:\Python34 -- surely this is the wrong working directory for 99% of normal users and for 100% of beginners? Naturally they saved all their .py files there until I realised. And then when I got them to create a new directory for their own files ("Python" and "pie_thon") and dragged them across they also managed to move python.exe and pythonw.exe.
>
> Couldn't IDLE start in the home directory?
>
> The turtle package is quite nice and there is a very short but dramatic colored star example at the start of the docs. There really ought to be a little gallery of similar examples, including circle, polygon, and star (yes I know circle and polygon are built in but it is nice for children to see a simple implementation), and of course a few more -- but not any that compose shapes (e.g., face and house), since one would want them to learn how to compose themselves.
>
> Making them type turtle.this and turtle.that would be torture, so we began every file with
>
> from turtle import *
>
> I wish the doc examples did the same. (For randint we did from random import randint since only the one function was needed.)
>
> I stuck to pure procedural programming since OO would have been too much cognitive load to add given the time. I did make sure that once they'd created something (e.g., a face), they then put it inside a function.
>
> However, when it came to making a game ("hit the hippo") we needed to maintain some state that several functions could access. (I had to gloss over that we were doing higher order programming! -- e.g. onscreenclick(goto) etc.) What I wanted to write was this:
>
> state = object(moving=True, score=0) # Illegal!
> ...
> state.moving = False # etc.
>
> But was forced to do this:
>
> state = {'moving': True, 'score': 0}
> ...
> state['moving'] = False # so they get confused between {} and []
>
> There is an alternative:
>
> from types import SimpleNamespace
>
> state = SimpleNamespace(moving=True, score=0)
> ...
> state.moving = False # etc.
>
> But I felt that explaining what a namespace was would be too much -- remember they're having problems remembering to put () at the end of function calls etc.
> It would be nicer if object() acted as it does now but object(key=value,...) behaved like types.SimpleNamespace.
>

Finally I believe there's a very strong chance that of of this will be 
taken on board.  I've noticed activity on the bugtracker recently 
regarding turtle, GSOC student maybe?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#75525

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.

Done: http://bugs.python.org/issue22121

> > Suggestion #2: Make all the turtle examples begin "from turtle import *" so no leading turtle. is needed in the examples.
> 
> I'm not so sure about this, but raise an enhancement request and see 
> what happens.  Worst case it gets rejected, best case it gets accepted, 
> implemented and patch applied.

Done: http://bugs.python.org/issue22122

> > Suggestion #3: Make object(key=value, ...) legal and equiv of types.SimpleNamespace(key=value, ...).
> 
> Haven't the faintest idea and too lazy to find out :)  I suggest follow 
> advice from #2.

Done: http://bugs.python.org/issue22123

Mark.

[toc] | [prev] | [next] | [standalone]

#75563

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 an enhancement request on the bug tracker
>> if there isn't already one.
>
> Done: http://bugs.python.org/issue22121

As modified to fit existing behavior, this is a good idea and something 
will probably happen eventually.

>>> Suggestion #2: Make all the turtle examples begin "from turtle import *" so no leading turtle. is needed in the examples.
>>
>> I'm not so sure about this, but raise an enhancement request and see
>> what happens.  Worst case it gets rejected, best case it gets accepted,
>> implemented and patch applied.
>
> Done: http://bugs.python.org/issue22122

I suggest that the existing doc should be clarified instead.

>>> Suggestion #3: Make object(key=value, ...) legal and equiv of types.SimpleNamespace(key=value, ...).
>>
>> Haven't the faintest idea and too lazy to find out :)  I suggest follow
>> advice from #2.
>
> Done: http://bugs.python.org/issue22123

This idea would mask bugs and is not necessary for the goal of making 
types.SimpleNamespace more accessible.  It should have had more 
discussion here or on python-ideas.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#75560

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
>> other had done Scratch.
>>
>> 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.
>
>>
>> Suggestion #2: Make all the turtle examples begin "from turtle import
>> *" so no leading turtle. is needed in the examples.
>
> I'm not so sure about this, but raise an enhancement request and see
> what happens.   Worst case it gets rejected, best case it gets accepted,
> implemented and patch applied.
>
>>
>> Suggestion #3: Make object(key=value, ...) legal and equiv of
>> types.SimpleNamespace(key=value, ...).
>
> Haven't the faintest idea and too lazy to find out :)  I suggest follow
> advice from #2.

Mark L: I think that redirecting discussion to the tracker a hour after 
these ideas were posted, certainly for #2 and #3, which you were 
rightfully unsure about, was a bit premature.  Enhancement ideas 
generally benefit from being cooked a bit longer on one or another 
discussion list.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#75726

On Sat, Aug 2, 2014 at 2:45 AM, Mark Summerfield <list@qtrac.plus.com> 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.

When I've taught children (and adults!) with little programming
experience, I usually have a single import for all the things I want
them to use, something like:

from my_defined_functions import *

at the beginning of every script, usually named for the class I'm teaching.


>
> Suggestion #1: Make IDLE start in the user's home directory.

I use the iPython Notebook now for these things.

>
> Suggestion #2: Make all the turtle examples begin "from turtle import *" so no leading turtle. is needed in the examples.
>

in my universal import script I have the turtle imports, usually with
both from turtle import * and import turtle, so I have a choice.



> Suggestion #3: Make object(key=value, ...) legal and equiv of types.SimpleNamespace(key=value, ...).

 I also make a data structure, a simple wrapper around dict, which I
call Struct,  defined as:

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


then I can do:

x=Struct(a=5,b=10)
x.c=50
x['this']='that'  # or access like a dict


bb



-----------------

             bblais@gmail.com
             http://web.bryant.edu/~bblais

[toc] | [prev] | [next] | [standalone]

#75728

Brian Blais <bblais@gmail.com>:

> 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

Cool. I wonder if that should be built into dict.

Why can't I have:

   >>> d = {}
   >>> d.x = 3
   >>> d
   {'x': 3}


Marko

[toc] | [prev] | [next] | [standalone]

#75732

On Tue, Aug 5, 2014 at 7:04 AM, Marko Rauhamaa <marko@pacujo.net> 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
something[somethingelse], "somethingelse" is an index value or
key. Why destroy that symmetry in dictionaries?

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 also mildly surprising:

> var x = {};
undefined
> x.valueOf(47)
Object {}
> x["valueOf"] = 12
12
> x.valueOf
12
> x.valueOf(47)
TypeError: number is not a function

Still, in my own JS code I tend to lapse into that usage, probably
because so much other code out in the wild uses dot notation for key
references. (Doesn't make it right, just makes me lazy.)

Skip

[toc] | [prev] | [next] | [standalone]

#75738

Skip Montanaro <skip@pobox.com>:

> On Tue, Aug 5, 2014 at 7:04 AM, Marko Rauhamaa <marko@pacujo.net> 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
> something[somethingelse], "somethingelse" is an index value or key.
> Why destroy that symmetry in dictionaries?

I'm not sure I fully appreciate the dichotomy (which you euphemistically
refer to as symmetry).

> 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.

What's the inherent difference between an attribute and a key.


Marko

[toc] | [prev] | [next] | [standalone]

#75741

On 2014-08-05 14:19, Marko Rauhamaa wrote:
> Skip Montanaro <skip@pobox.com>:
>
>> On Tue, Aug 5, 2014 at 7:04 AM, Marko Rauhamaa <marko@pacujo.net> 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
>> something[somethingelse], "somethingelse" is an index value or key.
>> Why destroy that symmetry in dictionaries?
>
> I'm not sure I fully appreciate the dichotomy (which you euphemistically
> refer to as symmetry).
>
>> 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.
>
> What's the inherent difference between an attribute and a key.
>
An attribute is part of a container; a key is part of its contents.

[toc] | [prev] | [next] | [standalone]

#75744

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 between part of the object and the
object's content, if we so choose. As Lewis Carroll might have written
in "Through the Looking Glass" had he been a programmer:

   ‘When I use syntax,’ Humpty Dumpty said in rather a scornful tone, 
   ‘it means just what I choose it to mean — neither more nor less.’

   ’The question is,’ said Alice, ‘whether you can make syntax mean so 
    many different things.’

   ’The question is,’ said Humpty Dumpty, ‘which is to be master — 
    that’s all.’

If anyone wants a language where the same syntax means radically different
things, or radically different syntax means the same thing, then you know
where to find Perl, PHP and Javascript *wink*.

But more seriously, as Humpty might have said, of course the designer is the
master (and there are good masters and bad masters...), and sometimes there
is good reason to use attribute syntax for content. Sometimes it isn't
clear what counts as part of the object and what counts as part of the
contents, e.g. record or struct like objects exist in that grey area. In
that case, it may be a reasonable design choice to use attribute notation,
as namedtuple does, for example. But you'll note the cost: namedtuple is
forced to use leading underscore method names as *public* parts of the API,
so that they don't clash with field names.

If Guido was more like Perl's designer, Larry Wall, Python might have grown
a "short cut" notation for keys, say mydict$key, but the proliferation
of "many ways to do it" (to paraphrase the Perl motto) has costs of its
own. It's harder to learn, read and understand Perl code than Python code,
simply because there's more syntax to learn, and more special cases to
understand.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#75735

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 "<stdin>", line 1, in ?
TypeError: 'int' object is not callable


Conflating keys in a database with object attributes is one of the classic
blunders, like getting involved in a land war in Asia. It is, *maybe*,
barely acceptable as a quick-and-dirty convenience at the interactive
interpreter, in a Bunch or Bag class that has very little in the way of
methods or behaviour, but not acceptable for a class as fundamental and
important as dict. No matter what Javascript thinks.

Consider:

d['something else'] = 1
d.something else

    d.something else
                   ^
SyntaxError: invalid syntax



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#75737

On Tue, Aug 5, 2014 at 10:43 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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 "<stdin>", line 1, in ?
> TypeError: 'int' object is not callable
>
>
> Conflating keys in a database with object attributes is one of the classic
> blunders, like getting involved in a land war in Asia. It is, *maybe*,
> barely acceptable as a quick-and-dirty convenience at the interactive
> interpreter, in a Bunch or Bag class that has very little in the way of
> methods or behaviour, but not acceptable for a class as fundamental and
> important as dict. No matter what Javascript thinks.

It's not fundamentally bad, just fundamentally incompatible with any
other use of methods. Really, what you're pointing out isn't so much a
problem with conflating keys and attributes as it is with using
attributes for two purposes: key lookup, and method lookup. And that's
*always* going to be a bad thing. Imagine this class:

class BadDict(dict):
    def __getitem__(self, key):
        if key == 'copy': return self.copy
        return super().__getitem__(key)

Now I've just gone the other way - overloading square brackets to
sometimes mean key lookup, and sometimes attribute lookup. And it's
the two meanings on one notation, not the two notations for one
meaning, that's the bad idea.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75736

On Tue, Aug 5, 2014 at 10:31 PM, Skip Montanaro <skip@pobox.com> 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 also mildly surprising:
>
>> var x = {};
> undefined
>> x.valueOf(47)
> Object {}
>> x["valueOf"] = 12
> 12
>> x.valueOf
> 12
>> x.valueOf(47)
> TypeError: number is not a function

This is partly a consequence of prototype-based inheritance; x.valueOf
will shadow Object.valueOf. Pike allows a similar "dot or square
brackets" notation, but at the expense of not having any methods on
the mapping type itself:

Pike v8.0 release 3 running Hilfe v3.5 (Incremental Pike Frontend)
> mapping a=([]);
> a.foo="bar";
(1) Result: "bar"
> a.foo;
(2) Result: "bar"
> a;
(3) Result: ([ /* 1 element */
              "foo": "bar"
            ])

Since mappings (broadly equivalent to Python dicts) can't have
methods, anything that Python does as a method, Pike has to do as a
stand-alone function. (Swings and roundabouts, though, as those
functions tend to also accept other types, so they're more akin to
Python's len() than dict.pop().) Every design decision has a cost. The
convenience of short-handing mapping lookup is pretty handy
(especially when you're digging into deeply-nested mappings - imagine
parsing an XML or JSON message and then reaching into it for one
specific thing), but it means there are functions rather than methods
for working with them. Take your pick.

ChrisA

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web