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 1 of 3  [1] 2 3  Next page →

#75517 — 3 Suggestions to Make Python Easier For Children

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.

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.SimpleNamespace(key=value, ...).

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.

[toc] | [next] | [standalone]

#75519

Mark Summerfield <list@qtrac.plus.com>:

> 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.SimpleNamespace(key=value, ...).

Great suggestions for adults as well.

Expanding #3:

   >>> o = object()
   >>> o.x = 3
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   AttributeError: 'object' object has no attribute 'x'

Why?


Marko

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

#75521

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.
> >
> > Suggestion #3: Make object(key=value, ...) legal and equiv of
> > types.SimpleNamespace(key=value, ...).
> 
> Great suggestions for adults as well.
> 
> Expanding #3:
> 
>    >>> o = object()
>    >>> o.x = 3
>    Traceback (most recent call last):
>      File "<stdin>", line 1, in <module>
>    AttributeError: 'object' object has no attribute 'x'
> 
> Why?
> 
> Marko

object() returns a minimal featureless object with no dictionary (no __dict__ attribute). This makes sense for efficiency since not all objects need a dictionary.

What I'm suggesting is that _in addition_ to the existing behavior, a new behavior is introduced whereby object() called with keyword arguments creates a types.SimpleNamespace object (i.e., a basic object that has a dictionary initialized by the keyword arguments).

Mark.

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

#75526

Mark Summerfield <list@qtrac.plus.com>:

> 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

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

#75539

Marko Rauhamaa wrote:

> Mark Summerfield <list@qtrac.plus.com>:
> 
>> 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, or a sensible language? *wink*

If object.__setattr__ did this, then we're left with two equally horrible
choices:

- only object works this way, not subclasses of object, which violates
  the Liskov substitution principle;

- all instances, of every type, work this way, which causes chaos and 
  destruction everywhere. Some of the consequences:

  * Classes with __slots__ will stop working as expected.
  * Immutable instances will no longer be immutable, since they can
    have mutable state.
  * The CPython interpreter shares immutable built-ins like ints 
    across multiple processes. Either CPython would have to stop
    doing this (increasing memory requirements significantly), or
    one process could reach across to another and mutate its ints.

Well, perhaps not *equally* horrible. Compared to the second alternative,
violating the LSP seems relatively benign.

There's also the implementation difficulty that instance.__dict__ is kept in
a slot (obviously, since it cannot be stored in the per instance
__dict__ !), which means that you cannot easily or practically expect to
dynamically add/or delete it from instances. Now I'm sure with sufficient
effort we could do so, but that's a lot of effort for negligible (or even
negative) gain.



-- 
Steven

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

#75541

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

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

   class Object: pass

in every application.

And the newest Python releases let you replace that with:

   import types
   Object = types.SimpleNamespace


Marko

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

#75542

On 02/08/2014 18:07, Marko Rauhamaa wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>
>> 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 create:
>
>     class Object: pass
>
> in every application.
>
> And the newest Python releases let you replace that with:
>
>     import types
>     Object = types.SimpleNamespace
>
>
> Marko
>

With the latter being part of suggestion #3 in the original post.

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

#75544

Mark Lawrence <breamoreboy@yahoo.co.uk>:

> 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 me to do:

   object(x=3)

this wouldn't work:

   object().x = 3

However, these would continue working:

   types.SimpleNamespace(x=3)
   types.SimpleNamespace().x = 3

Also, assuming Sugg. #3, would this work:

   object(x=3).y = 2

as this does:

   types.SimpleNamespace(x=3).y = 2


Marko

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

#75538

Marko Rauhamaa wrote:

> Expanding #3:
> 
>    >>> o = object()
>    >>> o.x = 3
>    Traceback (most recent call last):
>      File "<stdin>", line 1, in <module>
>    AttributeError: 'object' object has no attribute 'x'
> 
> Why?

There are two intended uses for object and its instances:

- as the base class for all other classes;

- instances can be used as featureless sentinel objects where
  only identity matters.

If you need instances which carry state, then object is the wrong class.


-- 
Steven

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

#75545 — Correct type for a simple “bag of attributes” namespace object (was: 3 Suggestions to Make Python Easier For Children)

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>

-- 
 \      “Nothing is more sacred than the facts.” —Sam Harris, _The End |
  `\                                                   of Faith_, 2004 |
_o__)                                                                  |
Ben Finney

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

#75546 — Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children)

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::
> 
>     >>> import types
>     >>> foo = types.SimpleNamespace()
>     >>> foo.x = 3
>     >>> foo
>     namespace(x=3)

This is too much for children (& beginners).

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 under the hood namespace has the same behavior as types.SimpleNamespace().

Naturally, I understand that adding a new name is a big deal and may be too much to ask for beginners.

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

#75547 — Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children)

On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield <list@qtrac.plus.com> 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 under the hood namespace has the same behavior as types.SimpleNamespace().
>
> 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
site.py. That way, you can set up your own customized Python, without
waiting for changes to be approved for core (which they probably won't
- new builtins have a high requirement for necessity, not just "I
don't want to have to type import").

ChrisA

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

#75549 — Re: Correct type for a simple "bag of attributes" namespace object

On 02/08/2014 22:05, Chris Angelico wrote:
> On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield <list@qtrac.plus.com> 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 under the hood namespace has the same behavior as types.SimpleNamespace().
>>
>> 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
> site.py. That way, you can set up your own customized Python, without
> waiting for changes to be approved for core (which they probably won't
> - new builtins have a high requirement for necessity, not just "I
> don't want to have to type import").
>
> ChrisA
>

I'd forgotten all about site.py so went to the 3.4.1 docs and found 
"Deprecated since version 3.4: Support for the “site-python” directory 
will be removed in 3.5.".

Plan B? :)

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

#75551 — Re: Correct type for a simple "bag of attributes" namespace object

On Sun, Aug 3, 2014 at 7:16 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> I'd forgotten all about site.py so went to the 3.4.1 docs and found
> "Deprecated since version 3.4: Support for the “site-python” directory will
> be removed in 3.5.".
>
> Plan B? :)

Oh. Hrm. I've no idea... but I'm sure there'll be a way to say
"execute this at the beginning of an interactive session". Dig in the
docs.

ChrisA

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

#75552 — Re: Correct type for a simple "bag of attributes" namespace object

On 02/08/2014 22:16, Mark Lawrence wrote:
> On 02/08/2014 22:05, Chris Angelico wrote:
>> On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield <list@qtrac.plus.com>
>> 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 under the hood namespace has the same behavior as
>>> types.SimpleNamespace().
>>>
>>> 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
>> site.py. That way, you can set up your own customized Python, without
>> waiting for changes to be approved for core (which they probably won't
>> - new builtins have a high requirement for necessity, not just "I
>> don't want to have to type import").
>>
>> ChrisA
>>
>
> I'd forgotten all about site.py so went to the 3.4.1 docs and found
> "Deprecated since version 3.4: Support for the “site-python” directory
> will be removed in 3.5.".
>
> Plan B? :)
>

Plan B is revert to plan A, I didn't read things anything like 
thoroughly enough, sorry about the noise :(

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

#75562 — Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children)

On Sat, Aug 2, 2014 at 2:05 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield <list@qtrac.plus.com> 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
> site.py. That way, you can set up your own customized Python, without
> waiting for changes to be approved for core (which they probably won't
> - new builtins have a high requirement for necessity, not just "I
> don't want to have to type import").

Teaching a beginner a new programming language, but pretending it's
Python, doesn't sound like a fantastic idea.

-- Devin

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

#75564 — Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children)

On Sun, Aug 3, 2014 at 9:18 AM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
> On Sat, Aug 2, 2014 at 2:05 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield <list@qtrac.plus.com> 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
>> site.py. That way, you can set up your own customized Python, without
>> waiting for changes to be approved for core (which they probably won't
>> - new builtins have a high requirement for necessity, not just "I
>> don't want to have to type import").
>
> Teaching a beginner a new programming language, but pretending it's
> Python, doesn't sound like a fantastic idea.

It would still be Python, you just teach that certain lines just
always go at the top of your scripts (like "from __future__ import
print_function" if you're on Py2).

ChrisA

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

#75569 — Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children)

On Sat, Aug 2, 2014 at 2:46 PM, Mark Summerfield <list@qtrac.plus.com> 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 SimpleNamespace class for the
>> common "bag of attributes" use case::
>>
>>     >>> import types
>>     >>> foo = types.SimpleNamespace()
>>     >>> foo.x = 3
>>     >>> foo
>>     namespace(x=3)
>
> This is too much for children (& beginners).
>
> 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 under the hood namespace has the same behavior as types.SimpleNamespace().
>
> Naturally, I understand that adding a new name is a big deal and may be too much to ask for beginners.

from types import SimpleNamespace as namespace

Just have them put that at the top of each file, and tell them not to
worry about what it does.

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

#75574 — Re: Correct type for a simple "bag of attributes" namespace object

On 8/2/2014 5:16 PM, Mark Lawrence wrote:
> On 02/08/2014 22:05, Chris Angelico wrote:
>> On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield <list@qtrac.plus.com>
>> 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 under the hood namespace has the same behavior as
>>> types.SimpleNamespace().
>>>
>>> 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
>> site.py. That way, you can set up your own customized Python, without
>> waiting for changes to be approved for core (which they probably won't
>> - new builtins have a high requirement for necessity, not just "I
>> don't want to have to type import").
>>
>> ChrisA
>>
>
> I'd forgotten all about site.py so went to the 3.4.1 docs and found
> "Deprecated since version 3.4: Support for the “site-python” directory
> will be removed in 3.5.".

site-python is *nix only and differetn from site.py, which will not go 
away. I believe PYTHONSTARTUP is also cross platform.


-- 
Terry Jan Reedy

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

#75575 — Re: Correct type for a simple "bag of attributes" namespace object

On 8/2/2014 8:59 PM, Ian Kelly wrote:
> On Sat, Aug 2, 2014 at 2:46 PM, Mark Summerfield <list@qtrac.plus.com> 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 SimpleNamespace class for the
>>> common "bag of attributes" use case::
>>>
>>>      >>> import types
>>>      >>> foo = types.SimpleNamespace()
>>>      >>> foo.x = 3
>>>      >>> foo
>>>      namespace(x=3)
>>
>> This is too much for children (& beginners).
>>
>> 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 under the hood namespace has the same behavior as types.SimpleNamespace().
>>
>> Naturally, I understand that adding a new name is a big deal and may be too much to ask for beginners.
>
> from types import SimpleNamespace as namespace
>
> Just have them put that at the top of each file, and tell them not to
> worry about what it does.

In fact, for the original usecase, put it in a 'template file' that also 
includes a turtle import.  For one of my projects, I have @template with 
several lines of boilerplate that I use for new files.


-- 
Terry Jan Reedy

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web