[Tutor] RE: Tutor digest, Vol 1 #359 - 6 msgs
Arthur Watts
arthur.watts@gbst.com
Thu, 13 Jul 2000 08:23:08 +1000
Tom,
I'm sure that you have seen the work that Guido and the others have
done for CNRI, where he maintains that Python lends itself well to
'intuitive' learning, whereby the class doesn't need to be given the basics
of OO theory before being able to use OO concepts. This is in stark contract
to languages like C++, where we have to jump through a lot hoops before
being able to create anything non-trivial. I fear that my own experience
with Python has been tainted by the need to see 'under the hood' a little
too early ! Hope this helps.
Regards,
Arthur
> -----Original Message-----
> From: tutor-request@python.org
> Sent: Thursday, 13 July 2000 2:01
> To: tutor@python.org
> Subject: Tutor digest, Vol 1 #359 - 6 msgs
>
> Send Tutor mailing list submissions to
> tutor@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.python.org/mailman/listinfo/tutor
> or, via email, send a message with subject or body 'help' to
> tutor-request@python.org
>
> You can reach the person managing the list at
> tutor-admin@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tutor digest..."
>
>
> Today's Topics:
>
> 1. Queens, NY - PYTHON Programming for Kids (Thomas A. Williams)
> 2. Re: newbie question (Alan Gauld)
> 3. Re: Re: newbie question (Remco Gerlich)
> 4. Implementing data hiding in Python (Arthur Watts)
> 5. Re: Implementing data hiding in Python (Sean 'Shaleh' Perry)
> 6. Re: Implementing data hiding in Python (Michael P. Reilly)
>
> --__--__--
>
> Message: 1
> From: "Thomas A. Williams" <Thomas_A._Williams@NEWYORKLIFE.COM>
> To: tutor@python.org
> Date: Tue, 11 Jul 2000 12:37:51 -0400
> Subject: [Tutor] Queens, NY - PYTHON Programming for Kids
>
> Hi Y'all,
> I'm looking at the prospect of starting a programming
> class for youth at the YMCA on Pasons Blvd. in
> Jamaica, Queens. I will definitely be building the class
> around PYTHON. Does anyone have any suggestions
> or directions?
>
> Also, MUCH THANKS to those who responded with suggestions
> on how to go about constructing a Coke Vending Machine
> from an object perspective in PYTHON. This is still a work in
> progress.
>
> Enjoy The Journey,
> TomW
>
>
>
>
> --__--__--
>
> Message: 2
> Date: Tue, 11 Jul 2000 17:01:03 +0000
> To: djansen@pobox.com
> From: Alan Gauld <alan.gauld@freenet.co.uk>
> Cc: tutor@python.org
> Subject: [Tutor] Re: newbie question
>
> Hi, Just back from a short vacation and found your
> query....
>
> > Now my question is why it is necessary to add
> > the sentences = sentences +...
> > and clauses = clauses +... lines? Why not just:
> >
> > self.c_sentence = self.c_sentence + self.c_punctuation[c]
>
> Nope, I don't know why I used a local variable
> - I don't in the non OO version. Maybe I was tired!
>
> Another poster generously suggested it was a
> possible performance improvement but I honestly
> doubt I was that alert. It certainly doesn't help
> a newbie...
>
> I'll change it in the next update to the site,
> thanks for pointing it out! (If I do find a valid
> reason I'll let you know!)
>
> That whole case study is getting a revisited as part
> of my book project, so that should get reflected
> back into the web site,
>
> The good news is that the fact you raised the question
> shows you have picked up a lot about programming Python!
> :-)
>
> Thanks agan,
>
> Alan G.
>
>
>
> --__--__--
>
> Message: 3
> Date: Tue, 11 Jul 2000 19:16:14 +0200
> From: Remco Gerlich <scarblac@pino.selwerd.nl>
> To: tutor@python.org
> Subject: Re: [Tutor] Re: newbie question
>
> On Tue, Jul 11, 2000 at 05:01:03PM +0000, Alan Gauld wrote:
> > Hi, Just back from a short vacation and found your
> > query....
> >
> > > Now my question is why it is necessary to add
> > > the sentences = sentences +...
> > > and clauses = clauses +... lines? Why not just:
> > >
> > > self.c_sentence = self.c_sentence + self.c_punctuation[c]
> >
> > Nope, I don't know why I used a local variable
> > - I don't in the non OO version. Maybe I was tired!
> >
> > Another poster generously suggested it was a
> > possible performance improvement but I honestly
> > doubt I was that alert. It certainly doesn't help
> > a newbie...
>
> Grin. I already had the feeling I was seeing too much into it when I
> thought
> up some explanations :).
>
> I don't know, I think I still like using the local better. But that's just
> a
> matter of taste, of course :)
>
> --
> Remco Gerlich, scarblac@pino.selwerd.nl
>
>
> --__--__--
>
> Message: 4
> From: Arthur Watts <arthur.watts@gbst.com>
> To: "'tutor@python.org'" <tutor@python.org>
> Date: Wed, 12 Jul 2000 11:56:05 +1000
> Subject: [Tutor] Implementing data hiding in Python
>
> Guys,
>
> I don't want to get into religious wars re the benefits of
> encapsulation and the use of 'private', 'const' or whatever. I know that I
> can use 'name-mangling' via '__foo' from Python 1.5 to give me a limited
> form of privacy and I have seen allusions to extensions that enforce data
> hiding :
>
> There is little direct support for data hiding within Python itself, but
> extensions and embeddings of Python can provide rock solid interfaces that
> expose only permitted foreign operations to the Python interpreter.
> Python's
> restricted execution mode may also provide some (usually extreme)
> protection
> within the interpreter itself.
>
> I need to know if anyone has written said extensions, as I am unable
> to find anything at the Vaults of Parnassus archive. I suspect that the
> above quote may indicate that we need to write our own extensions to
> enforce
> data-hiding on a class-by-class basis, but I'm open to suggestions. The
> issue is *not* coding to prevent breaking modules by trampling one
> anothers
> namespaces, it is convincing management that Python is the right tool for
> the bulk of the project.
>
> Thanks,
>
> Arthur
>
> Arthur Watts
> Systems Integrator
> GBST Pty Ltd
>
> 'Good programmers know what to use, great programmers know what to re-use'
> :
> Old Jungle Saying
>
>
>
> --__--__--
>
> Message: 5
> Date: Tue, 11 Jul 2000 19:08:33 -0700
> From: Sean 'Shaleh' Perry <shaleh@valinux.com>
> To: Arthur Watts <arthur.watts@gbst.com>
> Cc: "tutor@python.org" <tutor@python.org>
> Subject: Re: [Tutor] Implementing data hiding in Python
>
> On Wed, Jul 12, 2000 at 11:56:05AM +1000, Arthur Watts wrote:
> >
> > I need to know if anyone has written said extensions, as I am unable
> > to find anything at the Vaults of Parnassus archive. I suspect that the
> > above quote may indicate that we need to write our own extensions to
> enforce
> > data-hiding on a class-by-class basis, but I'm open to suggestions. The
> > issue is *not* coding to prevent breaking modules by trampling one
> anothers
> > namespaces, it is convincing management that Python is the right tool
> for
> > the bulk of the project.
> >
>
> I do not know of any working code for this. That said, do you NEED data
> privacy as granted by things like C++'s private? If you implement an
> object,
> document the ways to access and set data the languages support is there
> only
> to stop someone from misbehaving.
>
>
> --__--__--
>
> Message: 6
> From: "Michael P. Reilly" <arcege@shore.net>
> Subject: Re: [Tutor] Implementing data hiding in Python
> To: arthur.watts@gbst.com (Arthur Watts)
> Date: Tue, 11 Jul 2000 22:27:11 -0400 (EDT)
> Cc: tutor@python.org ('tutor@python.org')
> Reply-To: arcege@shore.net
>
> > I don't want to get into religious wars re the benefits of
> > encapsulation and the use of 'private', 'const' or whatever. I know that
> I
> > can use 'name-mangling' via '__foo' from Python 1.5 to give me a limited
> > form of privacy and I have seen allusions to extensions that enforce
> data
> > hiding :
> >
> > There is little direct support for data hiding within Python itself, but
> > extensions and embeddings of Python can provide rock solid interfaces
> that
> > expose only permitted foreign operations to the Python interpreter.
> Python's
> > restricted execution mode may also provide some (usually extreme)
> protection
> > within the interpreter itself.
> >
> > I need to know if anyone has written said extensions, as I am unable
> > to find anything at the Vaults of Parnassus archive. I suspect that the
> > above quote may indicate that we need to write our own extensions to
> enforce
> > data-hiding on a class-by-class basis, but I'm open to suggestions. The
> > issue is *not* coding to prevent breaking modules by trampling one
> anothers
> > namespaces, it is convincing management that Python is the right tool
> for
> > the bulk of the project.
>
> There is _no_ support for data hiding. The philosophy is based on
> introspection, not hiding. There are means that can "hide" values, but
> it gets into carefully constructed __getattr__ and __setattr__
> methods (there are issues with subclassing).
>
> Extensions enforce nothing in terms of data hiding, but.. as much or
> as little as the developer decides can be exposed. Extensions create
> Python types, not classes. You can make wrapper classes around the
> types (like UserList and UserDict).
>
> For documentation on making extensions you can read:
>
> "Extending and Embedding"
> http://www.python.org/doc/current/ext/ext.html
> "Python/C API"
> http://www.python.org/doc/current/api/api.html
> and (listed in the Vaults) "How to Write a Python Extension"
> http://starship.python.net/crew/arcege/extwriting/pyext.html
>
> SWIG can make this happen a little better, but with a little overhead
> and limitations.
>
> If you are looking for easy data hiding, Python might not be the
> language to go with. But then, data hiding is rarely a good reason to
> go with a language.
>
> -Arcege
>
> --
> ------------------------------------------------------------------------
> | Michael P. Reilly, Release Manager | Email: arcege@shore.net |
> | Salem, Mass. USA 01970 | |
> ------------------------------------------------------------------------
>
>
>
> --__--__--
>
> _______________________________________________
> Tutor maillist - Tutor@python.org
> http://www.python.org/mailman/listinfo/tutor
>
>
> End of Tutor Digest_______________________________________________
> Tutor maillist - Tutor@python.org
> http://www.python.org/mailman/listinfo/tutor