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

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

Encapsulation unpythonic?

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

Contents

  Encapsulation unpythonic? fsaldan1@gmail.com - 2013-08-17 05:26 -0700
    Re: Encapsulation unpythonic? Skip Montanaro <skip@pobox.com> - 2013-08-17 07:54 -0500
    Re: Encapsulation unpythonic? David <bouncingcats@gmail.com> - 2013-08-17 23:05 +1000
    Re: Encapsulation unpythonic? Chris Angelico <rosuav@gmail.com> - 2013-08-17 16:50 +0100
    Re: Encapsulation unpythonic? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-17 16:17 +0000
      Re: Encapsulation unpythonic? Joshua Landau <joshua@landau.ws> - 2013-08-18 18:15 +0100
        Re: Encapsulation unpythonic? Steven D'Aprano <steve@pearwood.info> - 2013-08-19 07:05 +0000
          Re: Encapsulation unpythonic? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-08-19 18:57 -0400
          Re: Encapsulation unpythonic? random832@fastmail.us - 2013-08-21 12:52 -0400
            Re: Encapsulation unpythonic? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-22 02:06 +0000
          Re: Encapsulation unpythonic? Ian Kelly <ian.g.kelly@gmail.com> - 2013-08-21 16:02 -0600
    Re: Encapsulation unpythonic? Gary Herron <gary.herron@islandtraining.com> - 2013-08-17 13:16 -0700
    Re: Encapsulation unpythonic? Terry Reedy <tjreedy@udel.edu> - 2013-08-17 17:22 -0400
    Re: Encapsulation unpythonic? Chris Angelico <rosuav@gmail.com> - 2013-08-18 01:59 +0100
    Re: Encapsulation unpythonic? chaz2cry@gmail.com - 2013-08-22 19:12 -0700
    Re: Encapsulation unpythonic? Fabrice Pombet <fp2161@gmail.com> - 2013-08-30 10:43 -0700
      Re: Encapsulation unpythonic? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-31 02:35 +0000
        Re: Encapsulation unpythonic? Fabrice Pombet <fp2161@gmail.com> - 2013-08-30 23:07 -0700
          Re: Encapsulation unpythonic? Marco Buttu <marco.buttu@gmail.com> - 2013-08-31 08:49 +0200
          Re: Encapsulation unpythonic? Gary Herron <gherron@digipen.edu> - 2013-08-31 00:03 -0700
            Re: Encapsulation unpythonic? Fabrice Pombet <fp2161@gmail.com> - 2013-08-31 00:42 -0700
              Re: Encapsulation unpythonic? Fabrice Pombet <fp2161@gmail.com> - 2013-08-31 01:00 -0700
          Re: Encapsulation unpythonic? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-31 11:46 +0000
            Re: Encapsulation unpythonic? Ned Batchelder <ned@nedbatchelder.com> - 2013-08-31 08:41 -0400
              Re: Encapsulation unpythonic? Fabrice Pombet <fp2161@gmail.com> - 2013-08-31 05:49 -0700
            Re: Encapsulation unpythonic? Fabrice Pombet <fp2161@gmail.com> - 2013-08-31 05:57 -0700
              Re: Encapsulation unpythonic? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-01 08:10 +0000
                Re: Encapsulation unpythonic? Chris Angelico <rosuav@gmail.com> - 2013-09-01 18:21 +1000
                  Re: Encapsulation unpythonic? Fabrice Pombet <fp2161@gmail.com> - 2013-09-01 03:09 -0700
                    Re: Encapsulation unpythonic? Ethan Furman <ethan@stoneleaf.us> - 2013-09-01 11:42 -0700
                      Re: Encapsulation unpythonic? Roy Smith <roy@panix.com> - 2013-09-01 15:13 -0400
                        Re: Encapsulation unpythonic? Ethan Furman <ethan@stoneleaf.us> - 2013-09-01 13:33 -0700
                        Re: Encapsulation unpythonic? Tim Delaney <timothy.c.delaney@gmail.com> - 2013-09-02 07:54 +1000
                          Re: Encapsulation unpythonic? Roy Smith <roy@panix.com> - 2013-09-01 18:02 -0400
                        Re: Encapsulation unpythonic? Ethan Furman <ethan@stoneleaf.us> - 2013-09-01 17:24 -0700
                          Re: Encapsulation unpythonic? Roy Smith <roy@panix.com> - 2013-09-01 20:59 -0400
                            Re: Encapsulation unpythonic? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-02 02:57 +0000
                            Re: Encapsulation unpythonic? Ethan Furman <ethan@stoneleaf.us> - 2013-09-01 21:15 -0700
                        Re: Encapsulation unpythonic? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-02 01:57 +0000
                Re: Encapsulation unpythonic? Ben Finney <ben+python@benfinney.id.au> - 2013-09-02 09:32 +1000
                  Re: Encapsulation unpythonic? Roy Smith <roy@panix.com> - 2013-09-01 20:52 -0400
            Re: Encapsulation unpythonic? "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2013-09-03 00:29 +0100
              Re: Encapsulation unpythonic? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-09-03 22:41 -0400
          Re: Encapsulation unpythonic? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-08-31 13:31 -0400
          Re: Encapsulation unpythonic? Tim Delaney <timothy.c.delaney@gmail.com> - 2013-09-01 03:47 +1000
      Re: Encapsulation unpythonic? 88888 Dihedral <dihedral88888@gmail.com> - 2013-09-02 14:43 -0700

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

#53446

In article <mailman.464.1378078348.19984.python-list@python.org>,
 Ben Finney <ben+python@benfinney.id.au> wrote:

> One of the more annoying traits of humanity is that whatever context we
> first encounter a term is disproportionately privileged, causing us to
> irrationally dismiss better (more useful, more reasonable, more
> pedagogically appropriate, more historically correct, etc.) definitions.

Known in the education world as "The law of primacy".

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

#53539

On Sat, 31 Aug 2013 12:46:52 +0100, Steven D'Aprano  
<steve+comp.lang.python@pearwood.info> wrote:

> # THIS DOES NOT HAPPEN IN PYTHON
> # or any other language, as far as I am aware
> x = 23
> y = x  # y now has the value 23
> x = 42  # change the value of the object  ### NOT SO! ###
> print y
> => prints 42

Not directly, but FORTRAN did (does?) allow you to achieve this  
oh-so-undesirable result indirectly.

FORTRAN passes arguments to functions and procedures by reference.  That  
includes passing constants, which effectively get put into hidden  
variables and passed across.  Changes to the "constant" parameters in the  
function can happen just as with any pass-by-reference, which would be  
fine if you promptly threw the constant away.  Unfortunately smart  
compilers used to (still do?) keep pools of these common constant  
"variables" around rather than creating new ones all the time, so changes  
to "constants" persisted.  Many's the poor natural scientist who was  
perplexed to find that 0 suddenly had the value 1!

-- 
Rhodri James *-* Wildebeest Herder to the Masses

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

#53591

On Tue, 03 Sep 2013 00:29:42 +0100, "Rhodri James"
<rhodri@wildebst.demon.co.uk> declaimed the following:

>On Sat, 31 Aug 2013 12:46:52 +0100, Steven D'Aprano  
><steve+comp.lang.python@pearwood.info> wrote:
>
>> # THIS DOES NOT HAPPEN IN PYTHON
>> # or any other language, as far as I am aware
>> x = 23
>> y = x  # y now has the value 23
>> x = 42  # change the value of the object  ### NOT SO! ###
>> print y
>> => prints 42
>
>Not directly, but FORTRAN did (does?) allow you to achieve this  
>oh-so-undesirable result indirectly.
>
>FORTRAN passes arguments to functions and procedures by reference.  That  
>includes passing constants, which effectively get put into hidden  
>variables and passed across.  Changes to the "constant" parameters in the  
>function can happen just as with any pass-by-reference, which would be  
>fine if you promptly threw the constant away.  Unfortunately smart  
>compilers used to (still do?) keep pools of these common constant  
>"variables" around rather than creating new ones all the time, so changes  
>to "constants" persisted.  Many's the poor natural scientist who was  
>perplexed to find that 0 suddenly had the value 1!

	Granted, this tended to be with older implementations. Most more modern
(F77 and later) tend to allocate such literals in a read-only block of
memory, so attempts to change them now cause a significant program failure.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#53371

On Fri, 30 Aug 2013 23:07:47 -0700 (PDT), Fabrice Pombet <fp2161@gmail.com>
declaimed the following:

>well, look at that:
>
>a=(1,2)
>a=2+3 ->a is an object and I have changed its type and value from outside. As far as I am concerned this is one hell of an encapsulation violation... Could you do this -strictly speaking- in Java or C++?

	There is where your major misunderstanding is...

"a" is a NAME attached (bound) to an object. In the first statement, the
object is the tuple (1,2). That object was not changed when you execute the
second statement -- which is taking two integer objects and creating a new
integer object having a value of '5', and then attaches the NAME "a" to the
new object. If no other names are bound to the (1,2) object, it will be
garbage collected.

	At no time do you change the type/value of the OBJECT.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#53372

[Multipart message — attachments visible in raw view] — view raw

On 1 September 2013 03:31, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

> On Fri, 30 Aug 2013 23:07:47 -0700 (PDT), Fabrice Pombet <fp2161@gmail.com
> >
> declaimed the following:
>
> >well, look at that:
> >
> >a=(1,2)
> >a=2+3 ->a is an object and I have changed its type and value from
> outside. As far as I am concerned this is one hell of an encapsulation
> violation... Could you do this -strictly speaking- in Java or C++?
>
>         There is where your major misunderstanding is...
>
> "a" is a NAME attached (bound) to an object. In the first statement, the
> object is the tuple (1,2). That object was not changed when you execute the
> second statement -- which is taking two integer objects and creating a new
> integer object having a value of '5', and then attaches the NAME "a" to the
> new object. If no other names are bound to the (1,2) object, it will be
> garbage collected.
>

I'll try another way to explain it, using Java terminology(since Fabrice
appears to be familiar with Java).

Object a = Arrays.asList(1, 2);  // a is a reference to the List<Integer>
returned by Arrays.asList
a = Integer.valueOf(2 + 3);  // a is now a reference to the Integer
returned by Integer.valueOf

You have not changed the type of 'a' in any way - you have simply changed
what the name 'a' refers to. This is functionally identical to your Python
code above,except that in Python you do not have to downcast the Object
reference 'a' or use reflection to call methods on it or access it's
members (think of it as Python does reflection automatically for you).

Tim Delaney

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

#53531

Fabrice Pombet於 2013年8月31日星期六UTC+8上午1時43分28秒寫道：
> On Saturday, August 17, 2013 2:26:32 PM UTC+2, Fernando Saldanha wrote:
> 
> > I am new to Python, with experience in Java, C++ and R. 
> 
> > 
> 
> > 
> 
> > 
> 
> > As I understand encapsulation is not a big thing in the Python world. I read that you can put two underscores before the name of a variable within a class declaration but in the many examples of code I looked at this is not widely used. I also read that encapsulation is "unpythonic."
> 
> > 
> 
> > 
> 
> > 
> 
> > Questions:
> 
> > 
> 
> > 
> 
> > 2) If it is in fact true that encapsulation is rarely used, how do I deal with the fact that other programmers can easily alter the values of members of my classes?
> 
> > 
> 
> Fernando, it is widely accepted that Python pays very little attention to encapsulation as a principle set in stone. Chaz's definition of encapsulation is also mine. Now you need to consider that taking this principle off the hostel of OOP does not mean that you can do whatever you fancy and you can't make anything unsettable.
> 
> 
> 
> There are plenty of techniques within Python that allow you to protect your arguments (in particular, decorators) inside a Class.
> 
> 
> 
> Now, lets get to the pretentious philosophical discussion: I guess encapsulation is quite the opposite of, say, dynamic typing, which is arguably core in Python. In practice this allows Python to be less verbose: at the end of the day, if you look back at your previous languages, don't you find that some of their compulsory features are usually more of a pain than something useful in practice? And after all, whither encapsulation? Can't we just have objects whose arguments are determined externally if we want to?
> 
> And that is the ballgame: as my old tutor says: "the claptrap of setters and getters does not need to be here if it is unnecessary". I would add: "so long as you can have them when you deem it necessary", and Python allows that.

The way to perform encapsulation in Python can be achieved by 
writing methods in C  to be compiled as an extension which 
can be used by all instances of some classes in the upper level.

CYTHON is  easy to be used for  the job.

[toc] | [prev] | [standalone]

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

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

csiph-web