Re: Hiding a progressbar in tkinter

[Cecil Westerhof]

MRAB  writes:

> On 2019-06-26 16:47, Cecil Westerhof wrote:
>> I just started with GUI stuff in tkinter. I have a progressbar, but I
>> want it to be only visible when it is used. So I tried the following:
>>  window = Tk()
>>  window.title(window_str)
>>  frame  = Frame(window)
>>  frame.pack(side = "top", fill = "both", expand = True)
>>  Button(window, text = button_str, command = select_dir).pack()
>>  progress = ttk.Progressbar(window, orient = "horizontal", length = 200,
>> mode = "determinate")
>>  progress.pack()
>>  progress.lower(frame)
>>  window.mainloop()
>>
>> But that does not hide the progressbar. What am I doing wrong?
>>
>> I could use pack_forget, but that will change the dimensions of the
>> window.
>>
> The progress bar isn't hidden because there's nothing on top of it to
> hide it.
>
> import tkinter as tk
> import tkinter.ttk as ttk
>
> window = tk.Tk()
> window.title(window_str)
> frame = tk.Frame(window)
> frame.pack(side='top', fill='both', expand=True)
> tk.Button(window, text=button_str, command=select_dir).pack()
>
> # Create a frame to hold the progress bar.
> progress_frame = tk.Frame(window)
> progress_frame.pack(fill='x', expand=True)
>
> # Put the progress bar into the progress frame, ensuring that it fills
> the grid cell.
> progress = ttk.Progressbar(progress_frame, orient='horizontal',
> length=200, mode='determinate')
> progress.grid(row=0, column=0, sticky='nsew')
>
> # Now put a blank frame into the progress frame over the progress bar,
> ensuring that it fills the same grid cell.
> blank = tk.Frame(progress_frame)
> blank.grid(row=0, column=0, sticky='nsew')
>
> # Raise the progress bar over the blank frame to reveal it.
> progress.tkraise()
>
> # Lower the progress bar underneath the blank frame to hide it.
> progress.lower()
>
> window.mainloop()

Works like a charm. Thanks.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Hiding a progressbar in tkinter

[MRAB]

On 2019-06-26 16:47, Cecil Westerhof wrote:

I just started with GUI stuff in tkinter. I have a progressbar, but I
want it to be only visible when it is used. So I tried the following:
 window = Tk()
 window.title(window_str)
 frame  = Frame(window)
 frame.pack(side = "top", fill = "both", expand = True)
 Button(window, text = button_str, command = select_dir).pack()
 progress = ttk.Progressbar(window, orient = "horizontal", length = 200,
mode = "determinate")
 progress.pack()
 progress.lower(frame)
 window.mainloop()

But that does not hide the progressbar. What am I doing wrong?

I could use pack_forget, but that will change the dimensions of the
window.

The progress bar isn't hidden because there's nothing on top of it to 
hide it.


import tkinter as tk
import tkinter.ttk as ttk

window = tk.Tk()
window.title(window_str)
frame = tk.Frame(window)
frame.pack(side='top', fill='both', expand=True)
tk.Button(window, text=button_str, command=select_dir).pack()

# Create a frame to hold the progress bar.
progress_frame = tk.Frame(window)
progress_frame.pack(fill='x', expand=True)

# Put the progress bar into the progress frame, ensuring that it fills 
the grid cell.
progress = ttk.Progressbar(progress_frame, orient='horizontal', 
length=200, mode='determinate')

progress.grid(row=0, column=0, sticky='nsew')

# Now put a blank frame into the progress frame over the progress bar, 
ensuring that it fills the same grid cell.

blank = tk.Frame(progress_frame)
blank.grid(row=0, column=0, sticky='nsew')

# Raise the progress bar over the blank frame to reveal it.
progress.tkraise()

# Lower the progress bar underneath the blank frame to hide it.
progress.lower()

window.mainloop()
--
https://mail.python.org/mailman/listinfo/python-list

Re: Hiding a progressbar in tkinter

[Wildman via Python-list]

On Wed, 26 Jun 2019 17:47:39 +0200, Cecil Westerhof wrote:

> I just started with GUI stuff in tkinter. I have a progressbar, but I
> want it to be only visible when it is used. So I tried the following:
> window = Tk()
> window.title(window_str)
> frame  = Frame(window)
> frame.pack(side = "top", fill = "both", expand = True)
> Button(window, text = button_str, command = select_dir).pack()
> progress = ttk.Progressbar(window, orient = "horizontal", length = 200,
>mode = "determinate")
> progress.pack()
> progress.lower(frame)
> window.mainloop()
> 
> But that does not hide the progressbar. What am I doing wrong?
> 
> I could use pack_forget, but that will change the dimensions of the
> window.

Here is an example using grid_forget().

https://stackoverflow.com/questions/33768577/tkinter-gui-with-progress-bar

Disclaimer:  I have not tested this code and cannot say for certain
that it will work the way you want.

-- 
 GNU/Linux user #557453
"Be vewy vewy qwiwet, I'm hunting wabbits."
  -Elmer Fudd
-- 
https://mail.python.org/mailman/listinfo/python-list

Hiding a progressbar in tkinter

[Cecil Westerhof]

I just started with GUI stuff in tkinter. I have a progressbar, but I
want it to be only visible when it is used. So I tried the following:
window = Tk()
window.title(window_str)
frame  = Frame(window)
frame.pack(side = "top", fill = "both", expand = True)
Button(window, text = button_str, command = select_dir).pack()
progress = ttk.Progressbar(window, orient = "horizontal", length = 200,
   mode = "determinate")
progress.pack()
progress.lower(frame)
window.mainloop()

But that does not hide the progressbar. What am I doing wrong?

I could use pack_forget, but that will change the dimensions of the
window.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32229] Simplify hiding developer warnings in user facing applications

[R. David Murray]

R. David Murray  added the comment:

Ah, OK, that makes more sense.  I don't run into warnings other than 
DeprecationWarnings in practice, so I tend to forget about them :)

I think specifying warnings filters is pretty inscrutable, in general.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32229] Simplify hiding developer warnings in user facing applications

[Nick Coghlan]

Nick Coghlan  added the comment:

Note: for consistency with the underlying action names, the API should probably 
be called "warnings.ignore_warnings". I'd still keep the proposed parameter 
name as "show" though (and we may want to consider introducing that as a more 
semantically meaningful alias for "default").

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32229] Simplify hiding developer warnings in user facing applications

[Nick Coghlan]

Nick Coghlan <ncogh...@gmail.com> added the comment:

Warnings aren't off by default in general - we just add implicit "ignore" 
filters for a few specific types.

So the primary functionality is to opt in to hiding *all* warnings, but to do 
it in a way that can be overridden by PYTHONWARNINGS, the interpreter's "-W" 
switch and the new "-X dev" mode.

For that, the usage looks like:

import warnings
warnings.hide_warnings()

Essentially, it flips the default behaviour over to "ignore everything", but 
reverts to the regular default if there are any config settings supplied.

The odd structure of my opening message arises from the fact that *given* such 
a modified default, it's then surprisingly tricky to say "hide warnings, except 
for those from modules I'm responsible for". That latter complication then 
becomes the rationale for the design of the proposed "show" parameter to carve 
out exceptions to the overall "hide everything" filter.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32229>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32229] Simplify hiding developer warnings in user facing applications

[R. David Murray]

R. David Murray  added the comment:

I haven't been following that discussion, and isolated from that that 
discussion the title of this issue and this proposal make no sense to me.  
Warnings are off by default, so you don't need to hide them.  In what context 
does this get used?  If this is going to be used to implement turning warnings 
on for the main application, why isn't it named "show_warnings"?

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32229] Simplify hiding developer warnings in user facing applications

[Nick Coghlan]

New submission from Nick Coghlan <ncogh...@gmail.com>:

One of the observations coming out of the PEP 565 discussions is that it's 
surprisingly tricky to opt-in to getting all warnings from a particular package 
and its subpackages, while opting out of warnings in general.

The simplest approximation is to do the following:

if not sys.warnoptions:
warnings.simplefilter("ignore")
warnings.filterwarnings("default", module="app_pkg.*")

That shows warnings for any module or package starting with `app_pkg`. A 
stricter filter that avoided warnings from top-level packages that merely 
shared the prefix would look like:

if not sys.warnoptions:
warnings.simplefilter("ignore")
warnings.filterwarnings("default", module="^app_pkg(\..*)?$")

It could be helpful to encapsulate that logic in a more declarative utility 
API, such that applications could do the following:

import warnings.
warnings.hide_warnings()

Or:

import warnings.
warnings.hide_warnings(override_warnoptions=True)

Or:

import warnings.
warnings.hide_warnings(show=["app_pkg"])

Proposed API:

def hide_warnings(*, show=(), override_warnoptions=False):
if override_warnoptions or not sys.warnoptions:
simplefilter("ignore")
for pkg_name in show:
pkg_filter =  _make_regex_for_pkg(pkg_name)
filterwarnings("default", module=pkg_filter)

--
messages: 307701
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Simplify hiding developer warnings in user facing applications
type: enhancement
versions: Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32229>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Hiding code from intruders, a different slant on an old question

[cl]

Dennis Lee Bieber  wrote:
> On Wed, 7 Oct 2015 13:05:07 + (UTC), alister
>  declaimed the following:
> 
> 
> >With a simple Cesar the method is "shift the alphabet by 'X' characters 
> >and X is the key
> >
> >if the key is unknown then the attacker still has to brute force the 
> >method (admittedly with only 25 options this is not difficult)
> 
> But who'd consider that with just one-case and alphabet only...
> 
> At the least include upper, lower, numbers, and basic punctuation --
> that will add a few more cycles of computation time to break 
> 
> 
> But the other point, yes... The most used encryption systems have
> publicly known/reviewed algorithms and rely on the secrecy of the key(s).

Which makes a nonsense of using a super-secure algorithm in many cases.

If you are doing in-place symmetric file encryption then it's the
security of the key hashing algorithm that matters much more than the
actual encryption used on the file.

Using ccrypt, enc, etc. for file encryption means the password that
encodes the encryption key is saved with the file so brute-force
attacks to get the key are quite straightforward.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Hiding code from intruders, a different slant on an old question

[alister]

On Thu, 08 Oct 2015 08:44:43 -0600, Ian Kelly wrote:

> On Wed, Oct 7, 2015 at 6:01 PM, Dennis Lee Bieber
>  wrote:
>> On Wed, 7 Oct 2015 13:05:07 + (UTC), alister
>>  declaimed the following:
>>
>>
>>>With a simple Cesar the method is "shift the alphabet by 'X' characters
>>>and X is the key
>>>
>>>if the key is unknown then the attacker still has to brute force the
>>>method (admittedly with only 25 options this is not difficult)
>>
>> But who'd consider that with just one-case and alphabet only...
>>
>> At the least include upper, lower, numbers, and basic
>> punctuation --
>> that will add a few more cycles of computation time to break 
> 
> It doesn't really matter how much you add; any Caesar cipher is going to
> fall easily to just a little bit of frequency analysis. Consider an
> extreme case, where the range of X is the size of the entire Unicode
> character set. If the message is written in a Latin-based character set,
> chances are good that the majority of the characters will fall within a
> range of <96, giving the attacker a great starting point to brute-force
> from.

Oh please
the Caesar cypher was mentioned as a simplification for the purpose of 
demonstration.
it was not intended to be even a remotely serious suggestion

which I am sure at least Denis understood when he posted his tongue in 
cheek reply.


-- 
Economists can certainly disappoint you.  One said that the economy would
turn up by the last quarter.  Well, I'm down to mine and it hasn't.
-- Robert Orben
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Hiding code from intruders, a different slant on an old question

[Ian Kelly]

On Wed, Oct 7, 2015 at 6:01 PM, Dennis Lee Bieber  wrote:
> On Wed, 7 Oct 2015 13:05:07 + (UTC), alister
>  declaimed the following:
>
>
>>With a simple Cesar the method is "shift the alphabet by 'X' characters
>>and X is the key
>>
>>if the key is unknown then the attacker still has to brute force the
>>method (admittedly with only 25 options this is not difficult)
>
> But who'd consider that with just one-case and alphabet only...
>
> At the least include upper, lower, numbers, and basic punctuation --
> that will add a few more cycles of computation time to break 

It doesn't really matter how much you add; any Caesar cipher is going
to fall easily to just a little bit of frequency analysis. Consider an
extreme case, where the range of X is the size of the entire Unicode
character set. If the message is written in a Latin-based character
set, chances are good that the majority of the characters will fall
within a range of <96, giving the attacker a great starting point to
brute-force from.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Hiding code from intruders, a different slant on an old question

[Ian Kelly]

On Thu, Oct 8, 2015 at 9:46 AM, alister
 wrote:
> Oh please
> the Caesar cypher was mentioned as a simplification for the purpose of
> demonstration.
> it was not intended to be even a remotely serious suggestion
>
> which I am sure at least Denis understood when he posted his tongue in
> cheek reply.

I understood that also. I don't see why that means I can't elaborate on it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Hiding code from intruders, a different slant on an old question

[cl]

I know questions similar to this are often asked but my reasons for
wanting to do this (and thus ways it can be done) are slightly different.

I have a number of little utility scripts (python and others) which I
use to automate the process of decrypting and displaying things like
files containing passwords.  

The encryption I use is reasonably secure anyway but I'd like to hide
the programs/methods I use so that:-

1 - The encrypted files are not identifiable as encrypted data (the file
command just returns 'data' so they can't be identified by that).  If
there's a script in my ~/bin directory that relates directly to the
files it's obvious they're encrypted.

2 - The method used for encryption isn't obvious, again an obvious
script will show the program I have used.


I *could* write a C program which just exec()'s the required programs,
if they're done separately this would be fairly well hidden but I was
wondering if there's anything more obvious I can do that enables me to
do things easily in Python.


This is for protecting against any possible intruder who has gained
access to my system by breaking an ssh password or stealing my laptop
for example.  It's *not* for hiding code that I'm giving to others,
I'd be quite happy to give the code in question to people who might
want to use it.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Hiding code from intruders, a different slant on an old question

[Littlefield, Tyler]

On 10/7/2015 5:38 AM, c...@isbd.net wrote:
> I know questions similar to this are often asked but my reasons for
> wanting to do this (and thus ways it can be done) are slightly different.
>
> I have a number of little utility scripts (python and others) which I
> use to automate the process of decrypting and displaying things like
> files containing passwords.  
>
> The encryption I use is reasonably secure anyway but I'd like to hide
> the programs/methods I use so that:-
>
> 1 - The encrypted files are not identifiable as encrypted data (the file
> command just returns 'data' so they can't be identified by that).  If
> there's a script in my ~/bin directory that relates directly to the
> files it's obvious they're encrypted.
>
> 2 - The method used for encryption isn't obvious, again an obvious
> script will show the program I have used.
>

You have two options here:
1) Use a strong encryption like aes256 etc and don't bother trying to
"hide" the code because it's just a blob of data and they'll not crack it.
2) Encrypt the whole drive if you use something like *nix/*bsd.
The only thing hiding the code will do is make them guess at the method.
But if you use a good method in the firstplace, you shouldn't have any
issues because it's not going to be cracked.

> I *could* write a C program which just exec()'s the required programs,
> if they're done separately this would be fairly well hidden but I was
> wondering if there's anything more obvious I can do that enables me to
> do things easily in Python.
>
>
> This is for protecting against any possible intruder who has gained
> access to my system by breaking an ssh password or stealing my laptop
> for example.  It's *not* for hiding code that I'm giving to others,
> I'd be quite happy to give the code in question to people who might
> want to use it.
>


-- 
Take care,
Ty
http://tds-solutions.net
He that will not reason is a bigot; he that cannot reason is a fool; he that 
dares not reason is a slave.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Hiding code from intruders, a different slant on an old question

[alister]

On Wed, 07 Oct 2015 10:38:37 +0100, cl wrote:

> I know questions similar to this are often asked but my reasons for
> wanting to do this (and thus ways it can be done) are slightly
> different.
> 
> I have a number of little utility scripts (python and others) which I
> use to automate the process of decrypting and displaying things like
> files containing passwords.
> 
> The encryption I use is reasonably secure anyway but I'd like to hide
> the programs/methods I use so that:-
> 
> 1 - The encrypted files are not identifiable as encrypted data (the file
> command just returns 'data' so they can't be identified by that).  If
> there's a script in my ~/bin directory that relates directly to the
> files it's obvious they're encrypted.
> 
> 2 - The method used for encryption isn't obvious, again an obvious
> script will show the program I have used.
> 
> 
> I *could* write a C program which just exec()'s the required programs,
> if they're done separately this would be fairly well hidden but I was
> wondering if there's anything more obvious I can do that enables me to
> do things easily in Python.
> 
> 
> This is for protecting against any possible intruder who has gained
> access to my system by breaking an ssh password or stealing my laptop
> for example.  It's *not* for hiding code that I'm giving to others,
> I'd be quite happy to give the code in question to people who might want
> to use it.

The general rule with all forms of encryption is that the method is not 
secret. it is the key that needs to be kept secret.

in the same way that the mechanical principles of the lock on your front 
door are public knowledge, the profile of the key itself (which is needed 
to unlock the door) is unknown.

Example:

With a simple Cesar the method is "shift the alphabet by 'X' characters 
and X is the key

if the key is unknown then the attacker still has to brute force the 
method (admittedly with only 25 options this is not difficult)



-- 
Down with categorical imperative!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.3 Tkinter Fullscreen - Taskbar not Hiding

[Jason Swails]

I've added some comments about the code in question as well...

On Wed, Apr 3, 2013 at 11:45 PM, teslafreque...@aol.com wrote:

 Hi, I am working with Tkinter, and I have set up some simple code to run:

 import tkinter
 import re
 from tkinter import *


If you import everything from tkinter into your top-level namespace, then
the import tkinter at the top serves no purpose.


 global master


This 'global master' statement does nothing (and is actually misleading
IMO).


 master = Tk()

 # Start game Launcher
 def FormGUI():
 master.title(GAME TITLE)
 SW = master.winfo_screenwidth() / 3.2
 SH = master.winfo_screenheight() / 3.2
 master.geometry(500x300+%d+%d % (SW, SH))
 Label(master,text=game:\nGAME TITLE).pack()
 Button(master, text=Start game, command=DestroyStart,
 takefocus=1).pack()
 master.wm_state(zoom)


What is zoom?  This variable is not defined.  In fact, I get a NameError
when I try running your code because of this:

Traceback (most recent call last):
  File test_tk.py, line 38, in module
FormGUI()
  File test_tk.py, line 18, in FormGUI
master.wm_state(zoom)
NameError: global name 'zoom' is not defined

If I change zoom to normal (with quotes), it appears to work (although
I'm testing on Linux, not Windows).


 # Destroy the GUI launcher window upon player starting the game.
 def DestroyStart():
 global master
 master.destroy()
 master = Tk()
 ReformGui()

 # Form the game's GUI window in full screen.
 def ReformGui():
 master.title(GAME TITLE)
 SW = master.winfo_screenwidth()
 SH = master.winfo_screenheight()
 master.geometry(%dx%d+0+0 % (SW,SH))
 master.attributes(-fullscreen, 1)
 master.configure(bg=black)
 Label(master, text=\GAME TESTING TEXT\,
 background=black, foreground=white).pack()


 FormGUI()

 master.mainloop()

 # END OF CODE

 Everything in this code runs appropriately. The main goal of this code is
 to open up two windows, one with fixed dimensions, the other with
 full-screen enabled.

 My problem is that with the code above, the full-screen window opens up
 properly, however my taskbar shows over the full-screen. Until I click on
 the full-screen window, the taskbar will not be hidden.

 Am I doing something wrong, or is there a better way to create a
 full-screen window in Tkinter with the taskbar hidden?


This sounds to me that your full screen window does not have the focus
(i.e., it is not the `active' window).  Try adding a master.focus_force()
call in the ReformGui function to force it to take focus.  Note that
focus_force() is often considered 'impolite'---it's akin to that kid that
always needs to be the center of attention. Of course it's not as bad as
master.grab_set_global :)

If your application already has 'focus', then you can use focus_set instead
of focus_force.  The problem may be that you are destroying the original
master window and re-creating another (I typically avoid destroying the
root window mid-application).

Also as a note, it would be helpful to have some kind of button or
something to exit the app or exit fullscreen.  I had to Alt-F4 in order to
quit your sample program ;).

Hope this helps,
Jason
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3.3 Tkinter Fullscreen - Taskbar not Hiding

[teslafrequency]

Thanks a lot for your help, I've implemented the code you suggested and it 
seems to be functioning properly now. I've cleaned up the code a bit as well. 
I'll also take into account not destroying the master. Thanks again for your 
help!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3.3 Tkinter Fullscreen - Taskbar not Hiding

[Rotwang]

On 04/04/2013 14:49, Jason Swails wrote:

I've added some comments about the code in question as well...

On Wed, Apr 3, 2013 at 11:45 PM, teslafreque...@aol.com
mailto:teslafreque...@aol.com wrote:

Hi, I am working with Tkinter, and I have set up some simple code to
run:

import tkinter
import re
from tkinter import *


If you import everything from tkinter into your top-level namespace,
then the import tkinter at the top serves no purpose.


I don't know whether this applies to the OP's code, but I can think of 
at least one reason why one would want both import module and from 
module import* at the top of one's code: monkey patching.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3.3 Tkinter Fullscreen - Taskbar not Hiding

[Jason Swails]

On Thu, Apr 4, 2013 at 1:30 PM, Rotwang sg...@hotmail.co.uk wrote:

 On 04/04/2013 14:49, Jason Swails wrote:

 I've added some comments about the code in question as well...

 On Wed, Apr 3, 2013 at 11:45 PM, teslafreque...@aol.com
 mailto:teslafreque...@aol.com** wrote:

 Hi, I am working with Tkinter, and I have set up some simple code to
 run:

 import tkinter
 import re
 from tkinter import *


 If you import everything from tkinter into your top-level namespace,
 then the import tkinter at the top serves no purpose.


 I don't know whether this applies to the OP's code, but I can think of at
 least one reason why one would want both import module and from module
 import* at the top of one's code: monkey patching.


That was not happening in the OP's code (it actually had no references to
tkinter after the initial import).  That said, if you change any attributes
inside tkinter (by binding names inside tkinter to another object) after
the top three lines, those changes will not percolate down to the
attributes imported via from tkinter import * -- you would obviously have
to do that work before importing the tkinter namespace into the toplevel
namespace.

I'd be interested to see if there's actually an example where someone does
this in a way that would not be done better another way.  In any case, it
served no purpose in this particular program :).


All the best,
Jason
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3.3 Tkinter Fullscreen - Taskbar not Hiding

[Rotwang]

On 04/04/2013 20:00, Jason Swails wrote:

On Thu, Apr 4, 2013 at 1:30 PM, Rotwang sg...@hotmail.co.uk
mailto:sg...@hotmail.co.uk wrote:
[...]

I don't know whether this applies to the OP's code, but I can think
of at least one reason why one would want both import module and
from module import* at the top of one's code: monkey patching.


That was not happening in the OP's code (it actually had no references
to tkinter after the initial import).


Sure.



That said, if you change any
attributes inside tkinter (by binding names inside tkinter to another
object) after the top three lines, those changes will not percolate down
to the attributes imported via from tkinter import * -- you would
obviously have to do that work before importing the tkinter namespace
into the toplevel namespace.


What I had in mind was something like this:

# begin module derp.py

global_variable = 4

def f():
print('global_variable == %i' % global_variable)

# end module derp.py

 # in the interactive interpreter...
 import derp
 from derp import *
 global_variable = 5
 f()
global_variable == 4
 derp.global_variable = 5
 f()
global_variable == 5


Off the top of my head I don't know whether there's any purpose to doing 
that kind of thing with tkinter, but I can conceive that it might be 
useful for e.g. changing widget default behaviour or something.




I'd be interested to see if there's actually an example where someone
does this in a way that would not be done better another way.


No idea, sorry.
--
http://mail.python.org/mailman/listinfo/python-list

Python 3.3 Tkinter Fullscreen - Taskbar not Hiding

[teslafrequency]

Hi, I am working with Tkinter, and I have set up some simple code to run:

import tkinter
import re
from tkinter import *

global master
master = Tk()

# Start game Launcher
def FormGUI():
master.title(GAME TITLE)
SW = master.winfo_screenwidth() / 3.2
SH = master.winfo_screenheight() / 3.2
master.geometry(500x300+%d+%d % (SW, SH))
Label(master,text=game:\nGAME TITLE).pack()
Button(master, text=Start game, command=DestroyStart, takefocus=1).pack()
master.wm_state(zoom)

# Destroy the GUI launcher window upon player starting the game.
def DestroyStart():
global master
master.destroy()
master = Tk()
ReformGui()

# Form the game's GUI window in full screen.
def ReformGui():
master.title(GAME TITLE)
SW = master.winfo_screenwidth()
SH = master.winfo_screenheight()
master.geometry(%dx%d+0+0 % (SW,SH))
master.attributes(-fullscreen, 1)
master.configure(bg=black)
Label(master, text=\GAME TESTING TEXT\,
background=black, foreground=white).pack()

FormGUI()

master.mainloop()

# END OF CODE

Everything in this code runs appropriately. The main goal of this code is to 
open up two windows, one with fixed dimensions, the other with full-screen 
enabled.

My problem is that with the code above, the full-screen window opens up 
properly, however my taskbar shows over the full-screen. Until I click on the 
full-screen window, the taskbar will not be hidden.

Am I doing something wrong, or is there a better way to create a full-screen 
window in Tkinter with the taskbar hidden?

Note: Removing the 'import re' code above fixes the taskbar problem, however 
the re module is apparently needed as I can't run the program properly as an 
executable. Importing re fixes this problem. I'm running this program under 
Windows.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Hiding token information from users

[Nobody]

On Tue, 23 Aug 2011 06:27:39 -0700, Tobiah wrote:

 I am making QR codes that cell phone users scan in order to make use of an
 application.  Part of the information is a token that needs to be passed
 on to the server, but I'd rather not allow a person examining the QR code
 to be able to see that plain bit of information.  I'd like to scramble up
 the token so that the result:

Can you not just encrypt the data with a fixed secret key?

A fixed key satisfies #2.

#3 can almost be satisfied by using base-64, or can be entirely satisfied
by using base-36 or base-62 (these are less efficient, but that doesn't
matter for small amounts of data).

#1 can be satisfied by compressing the text beforehand; this should almost
exactly compensate for the expansion caused by #3.

Any block cipher in CBC mode will satisfy #4 (it will even be satisfied in
ECB mode if the compressed token is smaller than the cipher block size).

-- 
http://mail.python.org/mailman/listinfo/python-list

Hiding token information from users

[Tobiah]

I am making QR codes that cell phone users scan in order
to make use of an application.  Part of the information
is a token that needs to be passed on to the server, but
I'd rather not allow a person examining the QR code to
be able to see that plain bit of information.  I'd like
to scramble up the token so that the result:

1) takes up the same (near, or less) number of characters as the 
original token.


2) They key can be derived from the input, and vise versa.

3) The result is alphanumeric.

4) When one character changes in the source,
   many characters are likely to change in the
   result.

So if my token is:

mytoken2011

The result might be something like:

xm23ffz4uuw

Then
mytoken2012

might yield something very different:

d8ru3jdhvhd

I was thinking of just stringing up all letters and
numbers into a 'wheel' and doing an 18 char rotation on
the chars in the token, but that fails #4.  The secret is not like
the key to Fort Knox.  We would rather not have the plain
token out there, as it's internal business information,
but we don't have to protect the information at all costs.
Just making it really inconvenient to extract is fine.

Thanks,

Tobiah
--
http://mail.python.org/mailman/listinfo/python-list

Re: Hiding token information from users

[Ian Kelly]

How many of these codes do you need, and do they only need to be decrypted
at a central server? You might be able to just create random strings of
whatever form you want and associate them with the tokens in a database.
Then they will be completely opaque.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Hiding token information from users

[Tobiah]

On 08/23/2011 08:08 AM, Ian Kelly wrote:

How many of these codes do you need, and do they only need to be
decrypted at a central server? You might be able to just create random
strings of whatever form you want and associate them with the tokens in
a database. Then they will be completely opaque.



The tokens have a year portion that increments each year, and
the base portion of the token will be created newly in accordance
with new accounts that we take on.  I really need some sort of
algorithm that will let me take an unknown string and generate
the encrypted bit on the fly.

Thanks,

Tobiah
--
http://mail.python.org/mailman/listinfo/python-list

Re: Hiding token information from users

[Steven D'Aprano]

Tobiah wrote:

 I really need some sort of
 algorithm that will let me take an unknown string and generate
 the encrypted bit on the fly.

Google broken for you? *wink*

Seriously, there are about a bazillion algorithms for encrypting and
obfuscating strings. Depending on your security requirements, that can be
as simple as rot13 and as complex as blowfish (or even more so).

If it helps, I have a module that implements a selection of classical (i.e.
insecure) encryption algorithms:

http://pypi.python.org/pypi/obfuscate


Earlier, you said:

 The secret is not like
 the key to Fort Knox.  We would rather not have the plain
 token out there, as it's internal business information,
 but we don't have to protect the information at all costs.
 Just making it really inconvenient to extract is fine.

I don't understand the point of this. What could your users do with the
plain token that they shouldn't? I don't see why, if it's not worth
encrypting properly, why it's worth obfuscating it at all.


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Hiding token information from users

[Tobiah]

On 08/23/2011 09:55 AM, Steven D'Aprano wrote:

Tobiah wrote:


I really need some sort of
algorithm that will let me take an unknown string and generate
the encrypted bit on the fly.


Google broken for you? *wink*


I had some requirements in the OP that I could not
find a solution for.


Seriously, there are about a bazillion algorithms for encrypting and
obfuscating strings. Depending on your security requirements, that can be
as simple as rot13 and as complex as blowfish (or even more so).

If it helps, I have a module that implements a selection of classical (i.e.
insecure) encryption algorithms:

http://pypi.python.org/pypi/obfuscate


Earlier, you said:


The secret is not like
the key to Fort Knox.  We would rather not have the plain
token out there, as it's internal business information,
but we don't have to protect the information at all costs.
Just making it really inconvenient to extract is fine.


I don't understand the point of this. What could your users do with the
plain token that they shouldn't? I don't see why, if it's not worth
encrypting properly, why it's worth obfuscating it at all.


The token ends up translating into the name of a database on our
server.  With that information alone, it's difficult to imagine
a serious vulnerability, yet we just thought it would be worth
it to disguise the plain text.
--
http://mail.python.org/mailman/listinfo/python-list

Re: hiding modules in __init__.py

[Chris Rebert]

On Sat, Oct 18, 2008 at 12:03 PM, Brendan Miller [EMAIL PROTECTED] wrote:
 How would I implement something equivalent to java's package private in
 python?

 Say if I have

 package/__init__.py
 package/utility_module.py

 and utility_module.py is an implementation detail subject to change.

 Is there some way to use __init__.py to hide modules that I don't want
 clients to see? Or is the best practice just to name the module you don't
 want clients to use _utility_module and have it private by convention?

Generally the latter on account of Python's we are all consenting
adults here philosophy.

Cheers,
Chris
-- 
Follow the path of the Iguana...
http://rebertia.com


 Thanks,
 Brendan
 --
 http://mail.python.org/mailman/listinfo/python-list

--
http://mail.python.org/mailman/listinfo/python-list

Re: hiding modules in __init__.py

[Gabriel Genellina]

En Sat, 18 Oct 2008 16:03:19 -0300, Brendan Miller [EMAIL PROTECTED]  
escribió:



How would I implement something equivalent to java's package private in
python?

Say if I have

package/__init__.py
package/utility_module.py

and utility_module.py is an implementation detail subject to change.

Is there some way to use __init__.py to hide modules that I don't want
clients to see? Or is the best practice just to name the module you don't
want clients to use _utility_module and have it private by convention?


If you don't import utility_module in __init__ (or delete the name after  
using it), it won't show up if someone does from package import *, nor  
in dir(package). Plus if you don't menction it in the docs, the only way  
to discover it would be to look at the directory contents - to peek the  
implementation, I'd say.
You could always name it _utility_module.py if you want to make perfectly  
clear that it's for internal use only, but I've seldom seen such module  
names.


--
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list

hiding modules in __init__.py

[Brendan Miller]

How would I implement something equivalent to java's package private in
python?

Say if I have

package/__init__.py
package/utility_module.py

and utility_module.py is an implementation detail subject to change.

Is there some way to use __init__.py to hide modules that I don't want
clients to see? Or is the best practice just to name the module you don't
want clients to use _utility_module and have it private by convention?

Thanks,
Brendan
--
http://mail.python.org/mailman/listinfo/python-list

[OT] Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Dennis Lee Bieber a écrit :

On Wed, 11 Jun 2008 10:10:14 +0200, Bruno Desthuilliers
[EMAIL PROTECTED] declaimed the following in
comp.lang.python:


are some *very* talented and *experimented* programmers here.


Pardon, but I think you mean experienced.


Indeed. Tim Golden already corrected me (in private) about my mistake. 
Please pardon my french :-/



Of course, GvR may qualify as experimented if one considers
designing a language from scratch to be an experiment G


g++ ?-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Luis Zarrabeitia]

Quoting Dennis Lee Bieber [EMAIL PROTECTED]:

 On Wed, 11 Jun 2008 21:54:33 -0700 (PDT), Michele Simionato
 [EMAIL PROTECTED] declaimed the following in
 comp.lang.python:
 
  
  It looks like in French (as in Italian) *experimented* has the
  meaning of tried and tested on the field when applied to a
  person.
 
   Spock raised eyebrow
 
   Fascinating

Spanish also. I translate experimentado to experienced, perhaps because I
had seen it before, but I never imagined that experimented would be wrong.

Fascinating x2

-- 
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Niklas Norrthon]

On 6 Juni, 03:09, Russ P. [EMAIL PROTECTED] wrote:
 On Jun 5, 2:57 pm, Hrvoje Niksic [EMAIL PROTECTED] wrote:

  Russ P. [EMAIL PROTECTED] writes:
   By the way, my recollection is that in C++ access defaults to private
   if nothing is declared explicity. So normally the private
   declaration is unnecessary. If it is left out, your little trick won't
   work.

  How about #define class struct

 I never thought of that one. I wonder what the C++ gurus would say
 about that.

 Let me guess. They'd probably say that the access restrictions are for
 your own good, and bypassing them is bound to do you more harm than
 good in the long run. And they'd probably be right. Just because you
 can break into a box labeled DANGER HIGH VOLTAGE, that doesn't make
 it a good idea.

 This just goes to show that the whole idea of using header files as
 simple text insertions is flaky to start with, and adding the
 preprocessor just compounds the flakiness. Needless to say, I'mnota
 big fan of C and C++.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 10, 11:58 am, Jonathan Gardner

 Who cares what the type of an object is? Only the machine. Being able
 to tell, in advance, what the type of a variable is is a premature
 optimization. Tools like psyco prove that computers (really,
 programmers) nowadays are smart enough to figure things out the right
 way without any hints from the developer. Static typing is no longer
 necessary in today's world.

You couldn't be more wrong. Even Guido recognizes the potential value
of static typing, which is why he is easing it into Python as on
optional feature. He recognizes, correctly, that it can detect errors
earlier and facilitate more efficient execution. But there's another,
more significant potential benefit for safety-critical and mission-
critical applications: static typing facilitates advanced static
analysis of software. To get an idea of what that is about, take a
look at

http://www.sofcheck.com

Here is an excerpt from their website:

SofCheck’s advanced static error detection solutions find bugs in
programs before programs are run. By mathematically analyzing every
line of software, considering every possible input, and every path
through the program, SofCheck’s solutions find any and all errors that
cause a program to crash or produce an undefined result.

Me again: static analysis does not replace traditional dynamic and
unit testing, but it is far more advanced and finds many errors very
quickly that might require weeks or months of dynamic testing  -- or
might not be found at all with dynamic testing until the product is in
the field.

With more and more automation of safety-critical systems these days,
we need this more than ever. Your assertion that Static typing is no
longer
necessary in today's world, is just plain naive.

 Who cares about private declarations, or interface declarations at
 all? It is only a message to the developers. If you have a problem
 with your users doing the right thing, that is a social problem, not a
 technical one, and the solution is social, not technical. Yes, it is
 work, but it is not coding---it is explaining to other living,
 breathing human beings how to do a specific task, which is what you
 should have been doing from the start.

You may be right to an extent for small or medium-sized non-critical
projects, but you are certainly not right in general. I read something
a while back about the flight software for the Boeing 777. I think it
was something like 3,000,000 lines of Ada code. Normally, for a
project of that magnitude the final integration would be expected to
take something like three months. However, the precise interface specs
and encapsulation methods in Ada allowed the integration to be
completed in just three days.

By your recommended method of social interaction, that would be one
hell of a lot of talking!

I realize that Python is not designed for such large projects, but
don't you think certain general principles can be learned anyway?
Perhaps the benefits of interface specs and encapsulation are not as
obvious for smaller projects, but certainly they are not zero.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[cokofreedom]

On Jun 11, 8:11 am, Russ P. [EMAIL PROTECTED] wrote:
 On Jun 10, 11:58 am, Jonathan Gardner

  Who cares what the type of an object is? Only the machine. Being able
  to tell, in advance, what the type of a variable is is a premature
  optimization. Tools like psyco prove that computers (really,
  programmers) nowadays are smart enough to figure things out the right
  way without any hints from the developer. Static typing is no longer
  necessary in today's world.

 You couldn't be more wrong. Even Guido recognizes the potential value
 of static typing, which is why he is easing it into Python as on
 optional feature. He recognizes, correctly, that it can detect errors
 earlier and facilitate more efficient execution. But there's another,
 more significant potential benefit for safety-critical and mission-
 critical applications: static typing facilitates advanced static
 analysis of software.

Can you provide me with any example of Guide wanting static typing to
be
optional? I haven't. Any why is it you keep going so abstract in this
discussion.


 You may be right to an extent for small or medium-sized non-critical
 projects, but you are certainly not right in general. I read something
 a while back about the flight software for the Boeing 777. I think it
 was something like 3,000,000 lines of Ada code. Normally, for a
 project of that magnitude the final integration would be expected to
 take something like three months. However, the precise interface specs
 and encapsulation methods in Ada allowed the integration to be
 completed in just three days.


Well, that isn't just because they used encapsulation, the likelihood
is well thoughtout planning, constant system testing (that DOES
require accessing of those more private methods to ensure there are no
problems throughout), and re-testing. Again since I'm not sure how
much I trust you and your statistics anymore, have you a link to
anything discussing this?


 I realize that Python is not designed for such large projects, but
 don't you think certain general principles can be learned anyway?
 Perhaps the benefits of interface specs and encapsulation are not as
 obvious for smaller projects, but certainly they are not zero.

Python is designed to be an efficient high level language for writing
clear readable code at any level. Considering the amount of use it
gets from Google, and the scope and size of many of their projects, I
find it foolish to say it is not designed for large projects. However
I do not myself have an example of a large python project, because I
don't program python at work.

I think the issue here is your want to have python perform exactly
like OO built languages such as Java, but it isn't Java, and that, is
a good thing.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Russ P. a écrit :

On Jun 10, 1:04 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:


If you hope to get a general agreement here in favor of a useless
keyword that don't bring anything to the language, then yes, I'm afraid
you're wasting your time.


Actually, what I hope to do is to take something away from the
language, and that is the need to clutter my identifiers with leading
underscores.

I find that I spend the vast majority of my programming time working
on the private aspects of my code, and I just don't want to look at
leading underscores everywhere. So I usually just leave them off and
resort to a separate user guide to specify the public interface.

I'll bet many Python programmers do the same. How many Python
programmers do you think use leading underscores on every private data
member or method, or even most of them for that matter?


First point : please s/private/implementation/g. As long as you don't 
get why it's primary to make this conceptual shift, the whole discussion 
is hopeless.


Second point : I've read millions of lines of (production) python code 
these last years, and I can assure you that everyone used this 
convention. And respected it.




I'll bet not
many. (See the original post on this thread.) That means that this
particular aspect of Python is basically encouraging sloppy
programming practices.


Bullshit. Working experience is here to prove that it JustWork(tm).


What I don't understand is your visceral hostility to the idea of a
priv or private keyword.


Because it's at best totally useless.


If it offends you, you wouldn't need to
use it in your own code. You would be perfectly free to continue using
the leading-underscore convention (unless your employer tells you
otherwise, of course).


My employer doesn't tell me how to write code. I'm not a java-drone. My 
employer employ me because he is confident in my abilities, not because 
he needs some monkey to type the code.


The point is not *my* code, but the whole free python codebase. I 
definitively do not want it to start looking anything like Java. Thanks.



I get the impression that Python suits your own purposes and you
really don't care much about what purpose others might have for it.


Strange enough, every time I read something like this, it happens that 
it comes from someone who is going to ask for some fundamental change in 
a language used by millions of persons for the 15+ past years just 
because they think it would be better for their own current project.



I
am using it to develop a research prototype of a major safety-critical
system. I chose Python because it enhances my productivity and has a
clean syntax, but my prototype will eventually have to be re-written
in another language. I took a risk in choosing Python, and I would
feel better about it if Python would move up to the next level with
more advanced features such as (optional) static typing and private
declarations.


I'm sorry, but I don't see any of this as being a move up to the next 
level.



But every time I propose something like that,


fundamental change in the language for your own (perceived, and mostly 
imaginary) needs, that is...



I get all
kinds of flak from people here who do their hacking and care little
about anyone else's needs.


No one needs another Java. Now what happens here is that *you* come here 
explaining everyone that they need to adapt to the way *you* think 
things should be.



With a few relatively small improvements, Python could expand its
domain considerably and make major inroads into territory that is now
dominated by C++, Java, and other statically compiled languages. But
that won't happen if reactionary hackers stand in the way.


So anyone not agreeing with you - whatever his experience, reasons etc - 
is by definition a reactionnary hacker ? Nice to know.



Side note: I've been looking at Scala, and I like what I see.  It may
actually be more appropriate for my needs, but I have so much invested
in Python at this point that the switch will not be easy.


So instead of taking time to learn the tool that would fit your needs, 
you ask for fundamental changes in a language that fits millions other 
persons needs ? Now let's talk about not caring about other's needs...

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Russ P. a écrit :

On Jun 10, 11:58 am, Jonathan Gardner


(snip)

Who cares about private declarations, or interface declarations at
all? It is only a message to the developers. If you have a problem
with your users doing the right thing, that is a social problem, not a
technical one, and the solution is social, not technical. Yes, it is
work, but it is not coding---it is explaining to other living,
breathing human beings how to do a specific task, which is what you
should have been doing from the start.


You may be right to an extent for small or medium-sized non-critical
projects, but you are certainly not right in general. I read something
a while back about the flight software for the Boeing 777. I think it
was something like 3,000,000 lines of Ada code.


I can't obviously back my claim, but you could probably have the same 
feature set implemented in 10 to 20 times less code in Python. Not that 
I suggest using Python here specifically, but just to remind you that 
kloc is not a very exact metric - it's relative to the design, the 
language and the programmer(s). The first project I worked on 
(professionaly) was about 100 000 locs when I took over it, and one year 
later it was about 50 000 locs, with way less bugs and way more 
features. FWIW, the bigger the project, the bigger the chances that you 
could cut it by half with a good refactoring.



Normally, for a
project of that magnitude  the final integration would be expected to
take something like three months. However, the precise interface specs
and encapsulation methods in Ada allowed the integration to be
completed in just three days.

By your recommended method of social interaction, that would be one
hell of a lot of talking!


Or just writing and reading.


I realize that Python is not designed for such large projects,


Clueless again. Python is pretty good for large projects. Now the point 
is that it tends to make them way smaller than some other much more 
static languages. As an average, you can count on something between 5:1 
to 10:1 ratio between Java (typical and well-known reference) and Python 
for a same feature set. And the larger the project, the greater the ratio.



but
don't you think certain general principles can be learned anyway?


Do you really think you're talking to a bunch of clueless newbies ? You 
can bet there are quite a lot of talented *and experimented* programmers 
here.



Perhaps the benefits of interface specs and encapsulation are not as
obvious for smaller projects,


Plain wrong.


but certainly they are not zero.


You still fail to get the point. Interface specifications and 
encapsulation are design principles. period. These principles are just 
as well expressed with documentation and naming conventions, and the 
cost is way lower.


Russ, do yourself a favor : get out of your cargo-cult one minute and 
ask yourself whether all python users are really such a bunch of 
clueless newbies and cowboy hackers. You may not have noticed, but there 
are some *very* talented and *experimented* programmers here.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Maric Michaud]

Le Wednesday 11 June 2008 08:11:02 Russ P., vous avez écrit :
 http://www.sofcheck.com

 Here is an excerpt from their website:

 SofCheck’s advanced static error detection solutions find bugs in
 programs before programs are run. By mathematically analyzing every
 line of software, considering every possible input, and every path
 through the program, SofCheck’s solutions find any and all errors that
 cause a program to crash or produce an undefined result.

Don't mix commercial discourse with technical, it desserves your point. 
Theoretically, wether a program has bugs or not is not computable. Static 
analysis as they imply is just nonsense.

AFAIK, the efforts needed to make good static analysis are proven, by 
experience, to be at least as time consuming than the efforts needed to make 
good unit and dynamic testing.

-- 
_

Maric Michaud
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Paul Boddie]

On 11 Jun, 10:10, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
 Russ P. a écrit :

  You may be right to an extent for small or medium-sized non-critical
  projects, but you are certainly not right in general. I read something
  a while back about the flight software for the Boeing 777. I think it
  was something like 3,000,000 lines of Ada code.

 I can't obviously back my claim, but you could probably have the same
 feature set implemented in 10 to 20 times less code in Python.

It's easy to make claims like this knowing that people aren't likely
to try and write such a system in Python.

Not that
 I suggest using Python here specifically, but just to remind you that
 kloc is not a very exact metric - it's relative to the design, the
 language and the programmer(s). The first project I worked on
 (professionaly) was about 100 000 locs when I took over it, and one year
 later it was about 50 000 locs, with way less bugs and way more
 features. FWIW, the bigger the project, the bigger the chances that you
 could cut it by half with a good refactoring.

Perhaps you should get in touch with the advocacy-sig mailing list and
provide them with the concrete details, because although you and I
(and many others) recognise intuitively that Python code is typically
shorter than, say, Java because the boilerplate of the latter is
unnecessary, the last big discussion I recall about Python code being
shorter than that of statically typed languages didn't really yield
much in the way of actual projects to make the case.

  Normally, for a
  project of that magnitude  the final integration would be expected to
  take something like three months. However, the precise interface specs
  and encapsulation methods in Ada allowed the integration to be
  completed in just three days.

  By your recommended method of social interaction, that would be one
  hell of a lot of talking!

 Or just writing and reading.

Maybe, but I'd imagine that the project mentioned is a fairly large
one with all the classic observations by Brooks highly applicable.
Such things can incur huge costs in a large project.

  I realize that Python is not designed for such large projects,

 Clueless again. Python is pretty good for large projects.

It might be good for large projects but is it good for large projects
*such as the one mentioned*?

   Now the point
 is that it tends to make them way smaller than some other much more
 static languages. As an average, you can count on something between 5:1
 to 10:1 ratio between Java (typical and well-known reference) and Python
 for a same feature set. And the larger the project, the greater the ratio.

Again, I don't doubt this intuitively, but many people do doubt it.
Citation needed!

[...]

 Do you really think you're talking to a bunch of clueless newbies ? You
 can bet there are quite a lot of talented *and experimented* programmers
 here.

Maybe, but with the style of discourse you've been using, you're not
really speaking for them, are you?

  Perhaps the benefits of interface specs and encapsulation are not as
  obvious for smaller projects,

 Plain wrong.

I'm not a big fan of lots of up-front declarations when the code is
easy to understand intuitively, but what are you trying to say here?
That interface specifications and encapsulation are as essential for a
three line script as they are for a large project?

  but certainly they are not zero.

 You still fail to get the point. Interface specifications and
 encapsulation are design principles. period. These principles are just
 as well expressed with documentation and naming conventions, and the
 cost is way lower.

I guess it depends on how the documentation gets written, because from
what I've seen documentation is one of the more neglected areas of
endeavour in software development, with many development organisations
considering it a luxury which requires only a cursory treatment in
order to get the code out of the door.

 Russ, do yourself a favor : get out of your cargo-cult one minute and
 ask yourself whether all python users are really such a bunch of
 clueless newbies and cowboy hackers. You may not have noticed, but there
 are some *very* talented and *experimented* programmers here.

Maybe, but I'd hope that some of those programmers would be at least
able to entertain what Russ has been saying rather than setting
themselves up in an argumentative position where to concede any
limitation in Python might be considered some kind of weakness that
one should be unwilling to admit.

Paul
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 11, 2:36 am, Paul Boddie [EMAIL PROTECTED] wrote:

 Maybe, but I'd hope that some of those programmers would be at least
 able to entertain what Russ has been saying rather than setting
 themselves up in an argumentative position where to concede any
 limitation in Python might be considered some kind of weakness that
 one should be unwilling to admit.

Thanks. I sometimes get the impression that Desthuilliers thinks of
this forum like a pack of dogs, where he is the top dog and I am a
newcomer who needs to be put in his place. I just wish he would take a
chill pill and give it a rest. I am not trying to challenge his
position as top dog.

All I did was to suggest that a keyword be added to Python to
designate private data and methods without cluttering my cherished
code with those ugly leading underscores all over the place. I don't
like that clutter any more than I like all those semi-colons in other
popular languages. I was originally attracted to Python for its clean
syntax, but when I learned about the leading-underscore convention I
nearly gagged.

If Desthuilliers doesn't like my suggestion, then fine. If no other
Python programmer in the world likes it, then so be it. But do we
really need to get personal about it? Python will not be ruined if it
gets such a keyword, and Desthuilliers would be perfectly free to
continue using the leading-underscore convention if he wishes. Where
is the threat to his way of life?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Patrick Mullen]

On Wed, Jun 11, 2008 at 12:28 PM, Russ P. [EMAIL PROTECTED] wrote:


 If Desthuilliers doesn't like my suggestion, then fine. If no other
 Python programmer in the world likes it, then so be it. But do we
 really need to get personal about it? Python will not be ruined if it
 gets such a keyword, and Desthuilliers would be perfectly free to
 continue using the leading-underscore convention if he wishes. Where
 is the threat to his way of life?


Well, you have to understand that a lot of python programmers are refugees
from the microsoft or sun worlds, where we were forced to do things a
certain way, and often it was not in our opinion the best way, but there
wasn't anything we could do about it.  Some of these refugees are very
experienced in that other world, and don't want to go back there.  So
proposing that python borrow these methods of control from the place we have
fled from can feel threatening.  Some people obviously take it more
personally than others, but this is a general feeling a lot of python
programmers share.

Also I'm fairly certain you're not the first to mention this topic.

Here's what the cookbook has to say:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/573442
Something like that is really your best bet.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Paul Boddie]

On 11 Jun, 21:28, Russ P. [EMAIL PROTECTED] wrote:

 All I did was to suggest that a keyword be added to Python to
 designate private data and methods without cluttering my cherished
 code with those ugly leading underscores all over the place. I don't
 like that clutter any more than I like all those semi-colons in other
 popular languages. I was originally attracted to Python for its clean
 syntax, but when I learned about the leading-underscore convention I
 nearly gagged.

I'm not bothered about having private instance data, but I think
there's definitely a case to be answered about the double-underscore
name-mangling convention. In the remote past, people were fairly
honest about it being something of a hack, albeit one which had mostly
satisfactory results, and unlike the private instance data argument
which can often be countered by emphasising social measures, there has
been genuine surprise about this particular method of preventing
attribute name collisions - it's an issue which can trip up even
careful programmers.

Note also that the double-underscore convention is listed as a Python
wart [1] and is described by Kuchling thus:

But it's a hack and a kludge; making privacy depend on an unrelated
property such as the attribute's name is clumsy. At least this
ugliness is limited to one specific and little-used case; few Python
programmers ever bother to use this private variable feature.

In my opinion there are too many people either defending the status
quo (warts and all) or pushing the envelope in many areas that didn't
overly bother people before (various Python 3000 features).

Paul

[1] http://wiki.python.org/moin/PythonWarts
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Michele Simionato]

On Jun 12, 6:43 am, Dennis Lee Bieber [EMAIL PROTECTED] wrote:
 On Wed, 11 Jun 2008 10:10:14 +0200, Bruno Desthuilliers
 [EMAIL PROTECTED] declaimed the following in
 comp.lang.python:

  are some *very* talented and *experimented* programmers here.

 Pardon, but I think you mean experienced.

 Of course, GvR may qualify as experimented if one considers
 designing a language from scratch to be an experiment G

It looks like in French (as in Italian) *experimented* has the
meaning of tried and tested on the field when applied to a
person.

 Michele Simionato
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Ben Finney]

Michele Simionato [EMAIL PROTECTED] writes:

 On Jun 12, 6:43 am, Dennis Lee Bieber [EMAIL PROTECTED] wrote:
  Pardon, but I think you mean experienced.
 
  Of course, GvR may qualify as experimented if one considers
  designing a language from scratch to be an experiment G
 
 It looks like in French (as in Italian) *experimented* has the
 meaning of tried and tested on the field when applied to a person.

That would, in English, be proven (from similar ideas: to prove
means to determine the truth by a test or trial).

-- 
 \ I went over to the neighbor's and asked to borrow a cup of |
  `\salt. 'What are you making?' 'A salt lick.'  -- Steven Wright |
_o__)  |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Russ P. a écrit :

On Jun 9, 2:10 pm, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:


But if it takes 6 month to get the mentioned developer to release
something I can use, I'm screwed up. Fine.


I've lost track of how many times I've said this now, but my
suggestion for a priv keyword allowed for indirect access to
private data through some name-mangling scheme. 


And I've lost track of how many times I've said this now, but we already 
have this. While we're at it, why not a 'prot' keyword that would 
restrict name-mangling to the addition of a single leading underscore ?



That could be your
temporary fix while you are waiting for the developer to release a
corrected version. And even if that option were not available, you
could simply open up the relevant source file in the editor of your
choice and remove the offending priv declaration.


Yes. And I can always edit the source code and add the methods I need 
etc. You probably never used monkeypatching, so I guess you just can't 
understand the difference between maintaining a monkeypatch and 
maintaining a fork.



I completely fail
to see how you are screwed.



Sorry, but when I have to keep repeating the same basic points over
and over, I can't help but think I might be wasting my time.


If you hope to get a general agreement here in favor of a useless 
keyword that don't bring anything to the language, then yes, I'm afraid 
you're wasting your time.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Antoon Pardon]

On 2008-06-09, Lie [EMAIL PROTECTED] wrote:

 That seems strange to me. The and-or simulation that was offerd in the
 FAQ allowed for about the same kind of structures as the ternary
 operator in C and was used in the standard library IIRC.

 So the same unreadable was already possible to write, plus that it
 could cause bugs and had to be made even more unreadable in order
 to work correctly. Considering this it I find it odd that hurting
 readability was a motivation not to have it.

 In case you didn't notice, the and-or simulation is a hack, it is not
 to be used by anyone writing real code (instead of for an entry to
 Obfuscated Python Code Contest) to substitute it for inline if. If
 inline if is formalized, that means the language encourages the use
 of inline if, which we don't want to have.

Who is we? The last poll I know about had a majority in favor of a
ternary operator.

-- 
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 10, 1:04 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:

 If you hope to get a general agreement here in favor of a useless
 keyword that don't bring anything to the language, then yes, I'm afraid
 you're wasting your time.

Actually, what I hope to do is to take something away from the
language, and that is the need to clutter my identifiers with leading
underscores.

I find that I spend the vast majority of my programming time working
on the private aspects of my code, and I just don't want to look at
leading underscores everywhere. So I usually just leave them off and
resort to a separate user guide to specify the public interface.

I'll bet many Python programmers do the same. How many Python
programmers do you think use leading underscores on every private data
member or method, or even most of them for that matter? I'll bet not
many. (See the original post on this thread.) That means that this
particular aspect of Python is basically encouraging sloppy
programming practices.

What I don't understand is your visceral hostility to the idea of a
priv or private keyword. If it offends you, you wouldn't need to
use it in your own code. You would be perfectly free to continue using
the leading-underscore convention (unless your employer tells you
otherwise, of course).

I get the impression that Python suits your own purposes and you
really don't care much about what purpose others might have for it. I
am using it to develop a research prototype of a major safety-critical
system. I chose Python because it enhances my productivity and has a
clean syntax, but my prototype will eventually have to be re-written
in another language. I took a risk in choosing Python, and I would
feel better about it if Python would move up to the next level with
more advanced features such as (optional) static typing and private
declarations. But every time I propose something like that, I get all
kinds of flak from people here who do their hacking and care little
about anyone else's needs.

With a few relatively small improvements, Python could expand its
domain considerably and make major inroads into territory that is now
dominated by C++, Java, and other statically compiled languages. But
that won't happen if reactionary hackers stand in the way.

Side note: I've been looking at Scala, and I like what I see.  It may
actually be more appropriate for my needs, but I have so much invested
in Python at this point that the switch will not be easy.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Patrick Mullen]

Hi Russ,

Here are just some pragmatic considerations.  Personally I am against data
hiding, but I obviously won't convince you in that regard.  There are some
pros and cons as with anything, and I feel the cons outweight the pros
(namely that users of code should be able to use how they want, even if it
means shooting themselves in the foot; and the fact that priv somewhat
breaks the dynamics of python)

Even if your proposal were to go through, you are looking at probably 2
years before it can even be used.  Python3 is basically in freeze mode, and
it contains the biggest change in python syntax for a long time.  I know it
doesn't seem like a big change to you to add a priv keyword, but python very
rarely adds keywords, so it's a long shot merely for that reason.  This is
something that potentially would be under consideration for something like
3.2 or higher I think, so if you want to get the job done now, this topic or
trying to convince other long time python users isn't going to accomplish
your goals.

Leading underscore takes two keystrokes to type (shift, _) while priv,
private, etc takes many more.  If you are too lazy to type _var then how
come you aren't too lazy to type priv var?  Too me it seems like more
typing.  If the primary objection to leading underscores is looks, it seems
like you unnecesarily avoid them for a pointless reason.  There are ugly
aspects to every language, and there isn't really a better convention to use
that I can see.  Without of course implementing keywords, which are
conceptually difficult to think about in terms of python object model -
although you might be able to come up with a way.  But if you have a better
naming convention or strategy that you want to try on your code, nothing is
stopping you.

You can use one of the hacks found in this thread, or come up with your own
hack, to more or less accomplish what you want.  It should take 30 minutes
or less to set up, and you are done with it.  The internals of python make
it difficult to do more than that, but you are welcome to create your own
python fork if you think you are up to it.  Although I think that would be
more than 30 minutes of work.

And feel free to try other languages.  No one claimed python is the best for
every circumstance.  Well, if someone claimed that they are just fooling
themselves.  Python is a good hacker language that scales pretty well into
enterprise and web services; and can be used for other things as well.  I
don't believe that data prevention (we aren't really talking about just
hiding here) is necessary for 99% of tasks, but other people think
differently, so there are plenty of languages that implement these features.

Good luck finding a solution to fit your project.  However I don't think
trying to get a priv keyword into official python is feasable unless you
want to wait a very long time and go hoarse from shouting :)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Jonathan Gardner]

On Jun 10, 11:21 am, Russ P. [EMAIL PROTECTED] wrote:
 I took a risk in choosing Python, and I would
 feel better about it if Python would move up to the next level with
 more advanced features such as (optional) static typing and private
 declarations. But every time I propose something like that, I get all
 kinds of flak from people here who do their hacking and care little
 about anyone else's needs.

Let me share my personal insight. I used Python for a mission-critical
application that needed, in effect, almost 100% uptime with superior
throughput. In other words, it was a very fine piece of art that
needed to be precise and correct. In the end, Python delivered, under
budget, under schedule, and with superbly low maintenance costs
(practically 0 compared to other systems written in Java and C). I
didn't have to use any of the features you mentioned, and I can't
imagine why you would need them. In fact, having them in the language
would encourage others to use them and make my software less reliable.

You may think we are all a bunch of hackers who are too stupid to
understand what you are saying, but that is your loss.

Now, let me try to explain something that perhaps the previous 166
post may not have thoroughly explained. If I am duplicating what
everyone else has already said, then it's my own fault.

Short answer: You don't need these features in Python. You do need to
use the right tools for the right tasks.

Long answer:

Who cares what the type of an object is? Only the machine. Being able
to tell, in advance, what the type of a variable is is a premature
optimization. Tools like psyco prove that computers (really,
programmers) nowadays are smart enough to figure things out the right
way without any hints from the developer. Static typing is no longer
necessary in today's world.

Who cares about private declarations, or interface declarations at
all? It is only a message to the developers. If you have a problem
with your users doing the right thing, that is a social problem, not a
technical one, and the solution is social, not technical. Yes, it is
work, but it is not coding---it is explaining to other living,
breathing human beings how to do a specific task, which is what you
should have been doing from the start.

When all you have is a hammer, the world seems full of nails. Think
about that. You have more tools than Python to solve these problems,
and Python will never be the panacea you wish it was. The panacea is
you, putting the right tools to use for the right tasks.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Samuel Bayer]

Jonathan Gardner wrote:


Let me share my personal insight. I used Python for a mission-critical
application that needed, in effect, almost 100% uptime with superior
throughput. In other words, it was a very fine piece of art that
needed to be precise and correct. In the end, Python delivered, under
budget, under schedule, and with superbly low maintenance costs
(practically 0 compared to other systems written in Java and C). I
didn't have to use any of the features you mentioned, and I can't
imagine why you would need them. In fact, having them in the language
would encourage others to use them and make my software less reliable.


At the risk of prolonging this thread, I'll add my own personal insight. 
I've spent a decent amount of time programming in Java, and the overhead 
of assigning a too-restrictive privacy level (which happens a lot, once 
privacy levels are in the language) has cost me an immense amount of 
time. I've lost count of how often I've had a software package which 
made an element non-public, in many cases for no apparent good reason, 
except that they hadn't anticipated the way I was going to use their 
code. Tracing down the consequences of these decisions, and trying to 
work around them, has been exceptionally time-consuming for me. You can 
say that I can go and modify the source code, as long as I have the 
source code, but that misses the point: I don't WANT to keep my own copy 
of the code, with the attended overhead in merging it with subsequent 
releases, etc.


I'm not going to claim that data hiding has no purpose - it clearly 
addresses a set of concerns that programmers have about managing APIs. 
But I've found that its difficulties far outweigh its benefits.


Sam Bayer
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Mark Wooding a écrit :

Russ P. [EMAIL PROTECTED] wrote:


The idea of being able to discern properties of an object by its name
alone is something that is not normally done in programming in
general. 


Really?  You obviously haven't noticed Prolog, Smalltalk, Haskell, ML,
or Erlang then.  And that's just the ones I can think of off the top of
my head.

  * Prolog and Erlang distinguish atoms from variables by the case of
the first letter; also `_' is magical and is equivalent to a new
variable name every time you use it.

  * Smalltalk distinguishes between global and local variables according
to the case of the first letter.

  * Haskell distinguishes between normal functions and constructors
(both data constructors and type constructors) by the case of the
first letter, and has Prolog's `_' convention.

  * ML allows a single-quote in variable names, but reserves names
beginning with a single-quote for type variables.  It also has
Prolog's `_' convention.


You could add Ruby's naming rules here. Or the very very common 
convention of using ALL_UPPER for symbolic constants (or 
pseudo-constants as in Python). And *quite a lot* of other either 
cross-language or language-specific naming conventions.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Russ P. a écrit :

On Jun 8, 5:40 am, Mark Wooding [EMAIL PROTECTED] wrote:

Russ P. [EMAIL PROTECTED] wrote:

The idea of being able to discern properties of an object by its name
alone is something that is not normally done in programming in
general.

Really?  You obviously haven't noticed Prolog, Smalltalk, Haskell, ML,
or Erlang then.  And that's just the ones I can think of off the top of
my head.

  * Prolog and Erlang distinguish atoms from variables by the case of
the first letter; also `_' is magical and is equivalent to a new
variable name every time you use it.

  * Smalltalk distinguishes between global and local variables according
to the case of the first letter.

  * Haskell distinguishes between normal functions and constructors
(both data constructors and type constructors) by the case of the
first letter, and has Prolog's `_' convention.

  * ML allows a single-quote in variable names, but reserves names
beginning with a single-quote for type variables.  It also has
Prolog's `_' convention.

As far as I can see, discerning properties of a thing from its name
seems relatively common.


Well, common in Prolog, Smalltalk, Haskell, ML, and Erlang is hardly
common in general. I'll bet that Java and C/C++ are used more in North
Dakota than all those languages combined are used in the entire world.


And you'll very probably loose.


That's not to say they aren't interesting academic languages, of
course.


Erlang an academic language ? Man, you're either a troll or totally 
clueless.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Mark Wooding a écrit :

Fuzzyman [EMAIL PROTECTED] wrote:


So, you are stating that no API programmer using Python *ever* has a
valid or genuine reason for wanting (even if he can't have it) genuine
'hiding' of internal state or members from consumers of his (or
her...) API?


I don't want to speak for whoever you were responding to, but from my
point of view...

Yes.

I understand the difference between the documented interface of a system
and the details of its implementation.  But sometimes it can be useful
to take advantage of implementation details, particularly if the
published interface is inadequate in some way.  Whether or not I choose
to make use of implementation details is a trade-off between immediate
convenience and maintainability, but that's something I can make a
rational decision about.

By enforcing your `data hiding', you're effectively telling me that I'm
too stupid to make rational decisions of this sort.  And that's actually
extremely insulting.


I couldn't state it better. +1QOTW btw.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Russ P. a écrit :

On Jun 6, 8:25 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:


I also realize, by the way, that Python allows a client of a class to
define a new class member from completely outside the class
definition. Obviously, that cannot be declared private.

Why so ?

Why should the client of a class not be able to declare a *private*
member of the class? You're kidding, right?

I'm dead serious. I often add implementation attributes to either a
class or an instance. These *are* implementation parts, not API.


If a client accesses a data member of a class,


Please stop thinking in C++. This is Python, and all you have are 
attributes. Whether they're callable of not doesn't change much here.



then by definition that
member is not really private,


Who cares about it being private ? The important point is that it's 
*implementation*, not *interface*.



so letting the client create a new data
member and declare it as private seems a bit silly to me. 


There are two ways to decorate a class or instance object (nb: Python's 
classes are objects too): the static way where you wrap the object in 
a decorator class or instance and use delegation, and the dynamic way 
where you just modify the original class or object at runtime. The fact 
that an attribute is added (or replaced) outside the class statement 
doesn't mean it has to be part of the interface. You sometime have 
pretty legitimate reason to modify the implementation at runtime.



Actually,
just letting the client create the new data member, private or not,
seems like a bit of a stretch to me, but I'll leave that be.


You're way too much in the Java/C++ way of thinking.


For the record, I have made it abundantly clear that I don't think
Python should not have as rigorous an encapsulation regime as C++ or
Java. The worst that could happen with my proposition is that you
would need to use a mangled name to access private data or methods.

That's already the case - when you use __name_mangling. And if there's
no effective access restriction, then what the point of having this
'priv' keyword ?


But you will be using the name many times, you can reassign your own
name, of course, so the mangled name need not appear more than once
where it is needed.

Once again, I just don't see the point. Either you want effective access
restriction in Python, or you don't. And if you don't, what would this
'priv' keyword be useful to ?


In the end, I suppose it boils down to aesthetics and personal
preference.

The leading-underscore convention bothers me for two reasons: (1) like
the OP, I don't like the way it makes my code look, and (2) it is a
signal to a person reading the code, but it has no actual effect in
the interpreter.


Indeed. The target of the signal is definitively the person reading the 
code.



I think the concept of private data and methods is important enough to
be implemented with more than just a tacky naming convention.


The concept of private attributes is not important. What's important 
is the concept of implementation attributes.



That is
why I suggested the priv keyword. At the same time, I realize that
people will occasionally be frustrated if they are rigorously denied
access to all private data, which is why I suggested an indirect
method of access through mangled names.


We already have all this. Either you want language-enforced access 
restriction - then you might be happier with another language - or you 
just want to have a clear way to know whether an attribute is part of 
the API or not - in which case a naming convention is not only enough, 
but even better.



You can argue that such indirect access defeats the whole idea of
private data,  but at least it alerts the client to the fact that he
(or she or it) is accessing private data


So does the naming convention, with much less work.


-- and it does so without
using Hungarian notation.


I wouldn't label this hungarian notation - or at least, not the way 
hungarian notation is now commonly understood.



I would let the priv keyword also be used for data or functions at
file scope. It just seems logical to me. Again, some name mangling
convention could be concocted for those who think they really need
access.

Actually, the whole objection to denied access baffles me a bit.


Free your mind from the very peculiar, restricted and IMHO braindead 
conception of OO they taught you with Java and C++. Python is older 
than Java, it's by now a very very commonly used language on all major 
platforms, and experience prooves that you just don't need anything more 
than a simple naming convention.



Does
anyone object to not having access from outside a function to local
variables within the function? I doubt it. The other thing is that the
vast majority of Python software, I would guess, is provided with
source code. How many Python applications or libraries are provided
without source code? If you have the source code, you can obviously
just delete 

Re: Why does python not have a mechanism for data hiding?

[Antoon Pardon]

On 2008-06-07, BJörn Lindqvist [EMAIL PROTECTED] wrote:
 On Wed, Jun 4, 2008 at 2:02 PM, Antoon Pardon [EMAIL PROTECTED] wrote:
 Now of course noone would defend such a limitation on the grounds
 that one doesn't need the general case and that the general case
 will only save you some vertical space.

 But when it came to the ternary operator that was exactly the
 argument used, to defend the lack of it.

 As far as I remember, the primary motivation was developers experience
 with the ternary operator in other languages, especially C, where it
 was found to hurt readability. At least in my experience, it is much
 much more common to see the ternary operator making code more
 obfuscated than easing readability. Time will tell if Python's if-else
 expression will be abused in the same way.

That seems strange to me. The and-or simulation that was offerd in the
FAQ allowed for about the same kind of structures as the ternary
operator in C and was used in the standard library IIRC.

So the same unreadable was already possible to write, plus that it
could cause bugs and had to be made even more unreadable in order
to work correctly. Considering this it I find it odd that hurting
readability was a motivation not to have it.

-- 
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Lie]

On Jun 9, 7:20 pm, Antoon Pardon [EMAIL PROTECTED] wrote:
 On 2008-06-07, BJörn Lindqvist [EMAIL PROTECTED] wrote:

  On Wed, Jun 4, 2008 at 2:02 PM, Antoon Pardon [EMAIL PROTECTED] wrote:
  Now of course noone would defend such a limitation on the grounds
  that one doesn't need the general case and that the general case
  will only save you some vertical space.

  But when it came to the ternary operator that was exactly the
  argument used, to defend the lack of it.

  As far as I remember, the primary motivation was developers experience
  with the ternary operator in other languages, especially C, where it
  was found to hurt readability. At least in my experience, it is much
  much more common to see the ternary operator making code more
  obfuscated than easing readability. Time will tell if Python's if-else
  expression will be abused in the same way.

 That seems strange to me. The and-or simulation that was offerd in the
 FAQ allowed for about the same kind of structures as the ternary
 operator in C and was used in the standard library IIRC.

 So the same unreadable was already possible to write, plus that it
 could cause bugs and had to be made even more unreadable in order
 to work correctly. Considering this it I find it odd that hurting
 readability was a motivation not to have it.

In case you didn't notice, the and-or simulation is a hack, it is not
to be used by anyone writing real code (instead of for an entry to
Obfuscated Python Code Contest) to substitute it for inline if. If
inline if is formalized, that means the language encourages the use
of inline if, which we don't want to have.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 9, 2:23 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
 Mark Wooding a écrit :



  Fuzzyman [EMAIL PROTECTED] wrote:

  So, you are stating that no API programmer using Python *ever* has a
  valid or genuine reason for wanting (even if he can't have it) genuine
  'hiding' of internal state or members from consumers of his (or
  her...) API?

  I don't want to speak for whoever you were responding to, but from my
  point of view...

  Yes.

  I understand the difference between the documented interface of a system
  and the details of its implementation.  But sometimes it can be useful
  to take advantage of implementation details, particularly if the
  published interface is inadequate in some way.  Whether or not I choose
  to make use of implementation details is a trade-off between immediate
  convenience and maintainability, but that's something I can make a
  rational decision about.

  By enforcing your `data hiding', you're effectively telling me that I'm
  too stupid to make rational decisions of this sort.  And that's actually
  extremely insulting.

 I couldn't state it better. +1QOTW btw.

Please see my previous reply to that post.

Being insulted by data hiding is the QOTW? I'd call that an insult
to everyone else who has posted on this forum in the past week. Unless
of course you mean silliest QOTW.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 9, 2:22 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:

  Does
  anyone object to not having access from outside a function to local
  variables within the function? I doubt it. The other thing is that the
  vast majority of Python software, I would guess, is provided with
  source code. How many Python applications or libraries are provided
  without source code? If you have the source code, you can obviously
  just delete the priv keyword anywhere or everywhere it appears.

 Yes, fine. And then have to maintain a fork of the source code, and
 distribute it with the application. Honking great idea. doh :-(

A client who wishes to bypass access restrictions need not maintain
any fork. If you have access to the source code, removing my
proposed priv keyword from an entire library or application is a one-
liner in sed.

If you wish to remove only specific instances of its occurrences, that
is also a trivial matter, and all that needs to be maintained by the
client is a record of which instances were removed. In fact, the
client doesn't even need to do that, because when the next version
comes out they will be reminded very quickly of where they removed
priv.

But such a client would be a real fool for depending on private data
and/or methods, of course, because those are not part of the public
API and are not guaranteed to remain unchanged. The whole reason for
private data and methods is that they give the developers freedom to
change the implementation without changing the interface.

How about some common sense here. If you, the client, are convinced
that something declared private should really be public, then perhaps
you should contact the developer and explain your reasoning. If the
developer agrees, then the problem is solved. If not, then perhaps it
is *you*, the client who does not understand the proper usage of the
code.

I don't have time to reply to all or your claims, but my lack of a
reply to any particular point should not be construed as implicit
agreement.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[[EMAIL PROTECTED]]

On 9 juin, 20:43, Russ P. [EMAIL PROTECTED] wrote:

(snip argument about s/private/public/g on a whole source tree not
being a fork, and not being by far a worse hack than monkeypatching a
small specific part of a whole lib - what can I say ?)

 How about some common sense here.

Good question.

But for which definition of common sense ? May I remind you that,
for a long time, common sense dictated that the earth was flat and
at the center of the universe, and that anything heavier than air
could by no mean fly ? Or, more recently,  that their was a market for
at most 5 computers on earth, and that 640kb of RAM ought to be enough
for anyone ?


 If you, the client, are convinced
 that something declared private should really be public, then perhaps
 you should contact the developer and explain your reasoning.

Indeed.  At least something we seem to agree on.

 If the
 developer agrees, then the problem is solved.

Indeed again. But...

But if it takes 6 month to get the mentioned developer to release
something I can use, I'm screwed up. Fine.

As strange as it might be, I prefer to *first* make it work, *then*
contact the developer. And while we're at it:

 If not,

Then I prefer to be able to monkeypatch the code and only maintain my
monkeypatch than to have to maintain a whole fork of the original
lib.

But YMMV of course...

  then perhaps it
 is *you*, the client who does not understand the proper usage of the
 code.

Do you really think that I'm fiddling with implementation stuff that
may break my code any other release because I don't *understand* that
code ? But anyway : even if it happened to be the case, it would still
be my own responsability. So what's the matter ? Should we forbid
hammers because you could use one to bang your head with ?

 I don't have time to reply to all or your claims, but my lack of a
 reply to any particular point should not be construed as implicit
 agreement.

Sounds like a lawyer's notice. Anyway, your lack of agreement won't
keep me from happily add implentation attributes to existing objects
whenever I find it appropriate. Sorry for being more on the pragmatic
side than on the cargo-cult one.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 9, 2:10 pm, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

 But if it takes 6 month to get the mentioned developer to release
 something I can use, I'm screwed up. Fine.

I've lost track of how many times I've said this now, but my
suggestion for a priv keyword allowed for indirect access to
private data through some name-mangling scheme. That could be your
temporary fix while you are waiting for the developer to release a
corrected version. And even if that option were not available, you
could simply open up the relevant source file in the editor of your
choice and remove the offending priv declaration. I completely fail
to see how you are screwed.

Sorry, but when I have to keep repeating the same basic points over
and over, I can't help but think I might be wasting my time.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Fuzzyman]

On Jun 9, 10:23 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
 Mark Wooding a écrit :



  Fuzzyman [EMAIL PROTECTED] wrote:

  So, you are stating that no API programmer using Python *ever* has a
  valid or genuine reason for wanting (even if he can't have it) genuine
  'hiding' of internal state or members from consumers of his (or
  her...) API?

  I don't want to speak for whoever you were responding to, but from my
  point of view...

  Yes.

  I understand the difference between the documented interface of a system
  and the details of its implementation.  But sometimes it can be useful
  to take advantage of implementation details, particularly if the
  published interface is inadequate in some way.  Whether or not I choose
  to make use of implementation details is a trade-off between immediate
  convenience and maintainability, but that's something I can make a
  rational decision about.

  By enforcing your `data hiding', you're effectively telling me that I'm
  too stupid to make rational decisions of this sort.  And that's actually
  extremely insulting.

 I couldn't state it better. +1QOTW btw.

By telling me that I can never have a valid reason for wanting 'data
hiding' you're effectively telling me that I'm too stupid to make
rational decisions of this sort.  And that's actually extremely
insulting.

Fuzzyman
http://www.ironpython.info/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Mark Wooding]

Paul Rubin http wrote:

 This is bogus about 95% of the time though.  For the cases where it is
 really desired, I think it's best to require the target class to be
 enable it specifically somehow, maybe by inheriting from a special
 superclass.  That could let the compiler statically resolve member
 lookups the rest of the time.

No it wouldn't.  Think about multiple inheritance.

-- [mdw]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Mark Wooding]

Hrvoje Niksic [EMAIL PROTECTED] wrote:

 How about #define class struct

Won't work.  Consider `templateclass T ...'.

-- [mdw]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Mark Wooding]

Russ P. [EMAIL PROTECTED] wrote:

 The idea of being able to discern properties of an object by its name
 alone is something that is not normally done in programming in
 general. 

Really?  You obviously haven't noticed Prolog, Smalltalk, Haskell, ML,
or Erlang then.  And that's just the ones I can think of off the top of
my head.

  * Prolog and Erlang distinguish atoms from variables by the case of
the first letter; also `_' is magical and is equivalent to a new
variable name every time you use it.

  * Smalltalk distinguishes between global and local variables according
to the case of the first letter.

  * Haskell distinguishes between normal functions and constructors
(both data constructors and type constructors) by the case of the
first letter, and has Prolog's `_' convention.

  * ML allows a single-quote in variable names, but reserves names
beginning with a single-quote for type variables.  It also has
Prolog's `_' convention.

As far as I can see, discerning properties of a thing from its name
seems relatively common.

-- [mdw]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Mark Wooding]

Fuzzyman [EMAIL PROTECTED] wrote:

 So, you are stating that no API programmer using Python *ever* has a
 valid or genuine reason for wanting (even if he can't have it) genuine
 'hiding' of internal state or members from consumers of his (or
 her...) API?

I don't want to speak for whoever you were responding to, but from my
point of view...

Yes.

I understand the difference between the documented interface of a system
and the details of its implementation.  But sometimes it can be useful
to take advantage of implementation details, particularly if the
published interface is inadequate in some way.  Whether or not I choose
to make use of implementation details is a trade-off between immediate
convenience and maintainability, but that's something I can make a
rational decision about.

By enforcing your `data hiding', you're effectively telling me that I'm
too stupid to make rational decisions of this sort.  And that's actually
extremely insulting.

-- [mdw]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Roy Smith]

In article [EMAIL PROTECTED],
 Mark Wooding [EMAIL PROTECTED] wrote:

   * Prolog and Erlang distinguish atoms from variables by the case of
 the first letter; also `_' is magical and is equivalent to a new
 variable name every time you use it.

Can you explain that in more detail?  A literal reading of what you wrote 
would mean that if you did (assuming this is even legal syntax):

   _ = 1;
   y = _;

the _'s are different variables, which is absurd enough to make me believe 
I just misunderstood you.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Roy Smith]

In article [EMAIL PROTECTED],
 Mark Wooding [EMAIL PROTECTED] wrote:

 By enforcing your `data hiding', you're effectively telling me that I'm
 too stupid to make rational decisions of this sort.  And that's actually
 extremely insulting.

I think that's taking it a bit far.  Python doesn't let you manipulate 
pointers directly.  For example, I can't do:

   s = foo
   sp = address(s)
   sp[2] = 'x'
   print s

and have it print fox.  Is this because I'm too stupid to make rational 
decision of this sort?  No, it's because the Python programming model 
exposes some things and hides others which are deemed inappropriate or too 
low level.  One of the things it hides is direct access to raw memory.  I 
don't see that as fundamentally different from a C++ string class which 
declares its internal buffer to be private.  If the goose's pot is black, 
then the gander's kettle is an equal shade of dark grey.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Luis Zarrabeitia]

I don't know about Erlang (though I'd think it's behaviour sould be similar to
prolog), but at least in Prolog, yes, _ and _ are different variables. The whole
idea of _ is that it is a placeholder that can bind to anything, but will be
immediately discarded. It's just syntactic sugar so you don't have to create new
names for things you don't care about, which could be a problem in prolog (once
bound, cannot be bound again on the same branch) or erlang (once bound, bound
forever).

I just tried on erlang:

f(0,_) - 1+_;
f(X,_) - X*f(X-1,_).

produces an error:

./t.erl:4: variable '_' is unbound
./t.erl:5: variable '_' is unbound

(referring to the right side uses of the _ symbol)

while the definition:

f(0,Y)-1+Y;
f(X,Y)-X*f(X-1,Y).

produces a [very weird, just for testing purposes, don't use it at home] version
of 'factorial'.

So, you understood well.

As I haven't been following this thread, I won't go offtopic talking about
functional languages. But yes, on functional (and declarative?) languages, it
makes a lot of sense to have a 'symbol' that represents a new variable any time
you use it.

Cheers,

-- 
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie


Quoting Roy Smith [EMAIL PROTECTED]:

 In article [EMAIL PROTECTED],
  Mark Wooding [EMAIL PROTECTED] wrote:
 
* Prolog and Erlang distinguish atoms from variables by the case of
  the first letter; also `_' is magical and is equivalent to a new
  variable name every time you use it.
 
 Can you explain that in more detail?  A literal reading of what you wrote 
 would mean that if you did (assuming this is even legal syntax):
 
_ = 1;
y = _;
 
 the _'s are different variables, which is absurd enough to make me believe 
 I just misunderstood you.
 --
 http://mail.python.org/mailman/listinfo/python-list
 

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 8, 5:52 am, Mark Wooding [EMAIL PROTECTED] wrote:

 By enforcing your `data hiding', you're effectively telling me that I'm
 too stupid to make rational decisions of this sort.  And that's actually
 extremely insulting.

1) I suggest you not take it personally.

2) Local data within functions is hidden. Should you have access to
that too? Are you insulted that you don't?

3) I have suggested that indirect or back door access could be
provided to private data and methods via some sort of name mangling
rule akin to the current rule for leading double underscores. This
would provide access in a pinch, but it would make sure the client is
aware that he or she or it is accessing private data (and it would do
so without leading underscores).

4) My understanding is that most Python software is released or
shipped as source code (or at least with the source code included).
That means that the client would need only to remove my suggested
priv keyword to gain access. Have you ever actually had to use
Python software for which you had no access to the source code?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 8, 5:40 am, Mark Wooding [EMAIL PROTECTED] wrote:
 Russ P. [EMAIL PROTECTED] wrote:
  The idea of being able to discern properties of an object by its name
  alone is something that is not normally done in programming in
  general.

 Really?  You obviously haven't noticed Prolog, Smalltalk, Haskell, ML,
 or Erlang then.  And that's just the ones I can think of off the top of
 my head.

   * Prolog and Erlang distinguish atoms from variables by the case of
 the first letter; also `_' is magical and is equivalent to a new
 variable name every time you use it.

   * Smalltalk distinguishes between global and local variables according
 to the case of the first letter.

   * Haskell distinguishes between normal functions and constructors
 (both data constructors and type constructors) by the case of the
 first letter, and has Prolog's `_' convention.

   * ML allows a single-quote in variable names, but reserves names
 beginning with a single-quote for type variables.  It also has
 Prolog's `_' convention.

 As far as I can see, discerning properties of a thing from its name
 seems relatively common.

Well, common in Prolog, Smalltalk, Haskell, ML, and Erlang is hardly
common in general. I'll bet that Java and C/C++ are used more in North
Dakota than all those languages combined are used in the entire world.
That's not to say they aren't interesting academic languages, of
course.

As for using the case of the first letter to distinguish between local
and global variables, is that just a naming convention or is it
actually enforced by the compiler (or interpreter)? If it's actually
enforced, that seems rather restrictive to me. What if I want to name
a local variable after a proper name or an uppercase acronym? I guess
I'm just out of luck.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[John Salerno]

Sh4wn wrote:


data hiding. I know member vars are private when you prefix them with
2 underscores, but I hate prefixing my vars, I'd rather add a keyword
before it.


Others touched on this, but I thought I'd throw it in here as well since 
I was just reading about this. Apparently the double underscore 
convention has nothing to do with data hiding. It's simply a mechanism 
for avoiding name clashes, and data hiding only *seems* to be a result 
of it.


Not that that helps your situation any. :)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Patrick Mullen]

Well, common in Prolog, Smalltalk, Haskell, ML, and Erlang is hardly
common in general. I'll bet that Java and C/C++ are used more in North
Dakota than all those languages combined are used in the entire world.

I would say python has more in common with the mentioned family than with
the C or java families, although I guess it's more in between.

Perl, PHP and Ruby all have significant variable names also.  It is not that
uncommon.

2) Local data within functions is hidden. Should you have access to
that too? Are you insulted that you don't?

Local data within functions is not hidden.  Local data within functions
vanish when the function completes.  The ability for temporary
data is important, and the convention of having functions be
temporary keeps things sane.  Not quite the same as what this
discussion is about.  All of the attributes of an object also vanish
when the object does...

3) I have suggested that indirect or back door access could be
provided to private data and methods via some sort of name mangling
rule akin to the current rule for leading double underscores. This
would provide access in a pinch, but it would make sure the client is
aware that he or she or it is accessing private data (and it would do
so without leading underscores).

I honestly don't get the strong objection to leading underscores.
They are a low-tech way of saying don't touch, which won't
muck about with very sticky implementation problems that
private attributes would have, potential performance problems
etc.  They work NOW.  Even if priv or some such is in the
running to be added to python, it's going to be years.

4) My understanding is that most Python software is released or
shipped as source code (or at least with the source code included).
That means that the client would need only to remove my suggested
priv keyword to gain access. Have you ever actually had to use
Python software for which you had no access to the source code?

So when someone releases an api doesn't match what I am doing 100%,
I should fork the project?  This doesn't seem to be a good solution
for anybody.  And it seems exceptionally dumb to do so just to
go through and remove some keywords.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[BJörn Lindqvist]

On Wed, Jun 4, 2008 at 2:02 PM, Antoon Pardon [EMAIL PROTECTED] wrote:
 Now of course noone would defend such a limitation on the grounds
 that one doesn't need the general case and that the general case
 will only save you some vertical space.

 But when it came to the ternary operator that was exactly the
 argument used, to defend the lack of it.

As far as I remember, the primary motivation was developers experience
with the ternary operator in other languages, especially C, where it
was found to hurt readability. At least in my experience, it is much
much more common to see the ternary operator making code more
obfuscated than easing readability. Time will tell if Python's if-else
expression will be abused in the same way.


-- 
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list

Re: expression IF (was: Why does python not have a mechanism for data hiding?)

[John Nagle]

BJörn Lindqvist wrote:

On Wed, Jun 4, 2008 at 2:02 PM, Antoon Pardon [EMAIL PROTECTED] wrote:

Now of course noone would defend such a limitation on the grounds
that one doesn't need the general case and that the general case
will only save you some vertical space.

But when it came to the ternary operator that was exactly the
argument used, to defend the lack of it.


As far as I remember, the primary motivation was developers experience
with the ternary operator in other languages, especially C, where it
was found to hurt readability. At least in my experience, it is much
much more common to see the ternary operator making code more
obfuscated than easing readability. Time will tell if Python's if-else
expression will be abused in the same way.


Expression IF statements are most useful in situations where you can't
have multiple statements.  In C, that was usually in macros, or occasionally
in a function call:

printf(Boolean value: %s\n, b ? True : False);

was useful, for example.  The syntax was probably a bad choice.
The classic expression IF (an ALGOL extension) was

x := IF b THEN 1 ELSE 0;

Surrounded with parentheses, that form could be used in any expression
context.

Given Python's approach to indentation, conditionals
within expressions (and iteration; one could have FOR / YIELD) don't
fit the syntax.  That's why lambda expressions in Python are so limited.
Python already has local functions; you can write:

def foo(n) :
def bar(m) :
print In BAR,n, m
bar(n+1)

which also allows you to do anything you can do with a lambda expression.
You can have control structure, and it reads like ordinary Python.
So there's no real need for an expression IF operator.

John Nagle

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[cokofreedom]

Someone asked about Java;

class FieldTest {
public String publicString = Foobar;
private String privateString = Hello, World!;
}

import java.lang.reflect.Field;

public class Test4 {
  public static void main(String args[]) {
final Field fields[] =
FieldTest.class.getDeclaredFields();
for (int i = 0; i  fields.length; ++i) {
  System.out.println(Field:  + fields[i]);
}
  }
}

OUTPUT 
Field: public java.lang.String FieldTest.publicString
Field: private java.lang.String FieldTest.privateString

And to edit it;

import java.lang.reflect.Field;

public class Test7 {
  public static void main(String args[])
throws Exception {
final Field fields[] =
FieldTest.class.getDeclaredFields();
for (int i = 0; i  fields.length; ++i) {
  if (privateString.equals(fields[i].getName())) {
FieldTest fieldTest = new FieldTest();
Field f = fields[i];
f.setAccessible(true);
System.out.println(f.get(fieldTest));
f.set(fieldTest, Modified Field);
System.out.println(f.get(fieldTest));
break;
  }
}
  }
}

OUTPUT 
Hello, World!
Modified Field

Enjoy.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Russ P. a écrit :

On Jun 4, 4:29 am, NickC [EMAIL PROTECTED] wrote:

On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote:


What is it about leading underscores that bothers me? To me, they are
like a small pebble in your shoe while you are on a hike. Yes, you can
live with it, and it does no harm, but you still want to get rid of it.

With leading underscores, you can see *at the point of dereference*
that the code is accessing private data. With a this is private
keyword you have no idea whether you're accessing private or public
data, because the two namespaces get conflated together.


That is true. But with the priv keyword you'll discover quickly
enough that you are trying to access private data (as soon as you run
the program).


With the current convention, you don't even have to run the program - as 
soon as you *type* the name, you know you're accessing implementation stuff.



And even if a priv keyword is added, you are still
free to use the leading underscore convention if you wish.


What does this priv keyword buy you then ? Seriously ?


The idea of being able to discern properties of an object by its name
alone is something that is not normally done in programming in
general. 


Want to talk about the hungarian notation that is everywhere in MS 
Windows code ?-) or about the so common C++ coding guideline that 
insists on prefixing data members with a m_ or a w_ ?-)


More seriously: yes, you usually try to convey something about some 
relevant properties of the object in the identifier. Like, you know, 
using plurals for collections. Or i, j as loop indices.



Yes, of course you should choose identifiers to be
descriptive of what they represent in the real world, but you don't
use names like intCount, floatWeight, or MyClassMyObject would
you? 


Nope.


Why not?


Because the naming convention for variables is all_lower_with_underscores.

Also, because 'count' is likely enough to be an integer and 'weight' 
likely enough to be a float - and else another numeric. While 'counts' 
and 'weights' are likely enough to be collections (likely lists) of 
resp. integers and floats.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Russ P. a écrit :

On Jun 5, 4:53 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:

Russ P. a écrit :



Given your very recent discovery of what 'dynamic' *really* means in
Python (like, for exemple, dynamically adding / replacing attributes -
including methods - on a per-class or per-instance basis), possibly, yes.


My very recent discovery? Funny, I thought I knew that several years
ago. 


Looks like I mistook your

I also realize, by the way, that Python allows a client of a class to
define a new class member from completely outside the class
definition


as I just realized (...)

Sorry for having read too fast.


I also realize, by the way, that Python allows a client of a class to
define a new class member from completely outside the class
definition. Obviously, that cannot be declared private.

Why so ?


Why should the client of a class not be able to declare a *private*
member of the class? You're kidding, right?


I'm dead serious. I often add implementation attributes to either a 
class or an instance. These *are* implementation parts, not API.



Do you mind if I tell you
how to arrange the furniture in your bedroom?


I must be a bit dumb, but I don't see how human interaction problems 
relate to enforced access restriction in an OO programming language.



But if the
same identifier is already declared private within the class, than the
new definition should not be allowed (because it would defeat the
whole idea of private class members).

Why so ?

Metaprogramming (including monkeypatching) is part of the pythoneer's
toolbox, and while it's not something to use without pretty good
reasons, it has many times proven to be a real life saver. In languages
not allowing it, the solutions to the class of problems easily solved by
monkeypatching happens to be at best a kludge, at worst plain
unsolvable, at least without too much effort to be even worth it. Your
above proposition would arbitrarily make possible and useful things
either uselessly complicated or near impossible.


For the record, I have made it abundantly clear that I don't think
Python should not have as rigorous an encapsulation regime as C++ or
Java. The worst that could happen with my proposition is that you
would need to use a mangled name to access private data or methods.


That's already the case - when you use __name_mangling. And if there's 
no effective access restriction, then what the point of having this 
'priv' keyword ?



But you will be using the name many times, you can reassign your own
name, of course, so the mangled name need not appear more than once
where it is needed.


Once again, I just don't see the point. Either you want effective access 
restriction in Python, or you don't. And if you don't, what would this 
'priv' keyword be useful to ?

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Russ P. a écrit :

On Jun 5, 2:27 pm, Dennis Lee Bieber [EMAIL PROTECTED] wrote:

On Thu, 5 Jun 2008 11:36:28 -0700 (PDT), Russ P.
[EMAIL PROTECTED] declaimed the following in comp.lang.python:


would need to use a mangled name to access private data or methods.
But you will be using the name many times, you can reassign your own
name, of course, so the mangled name need not appear more than once
where it is needed.

Which will break the first time the innards rebind a value to the
mangled name, as the simplified external name will still be bound to
the previous value.


I'm not sure you understood what I meant. In current Python, if I need
access to data element __XX in class YourClass, I can use
ZZ._YourClass__XX, but if I don't want to clutter my code with that
mangled name, I can just write

XX = ZZ._YourClass__XX

and refer to it from that point on as XX. 



Obviously if the meaning of
__XX changes within class ZZ, this will break, but that's why you are
supposed to avoid using private data in the first place.


AFAICT, What Dennis meant is that the binding of ZZ._YourClass__XX 
changes between the moment you bind it to local XX and the moment you 
use it, then you're out.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 6, 8:25 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:

  I also realize, by the way, that Python allows a client of a class to
  define a new class member from completely outside the class
  definition. Obviously, that cannot be declared private.
  Why so ?

  Why should the client of a class not be able to declare a *private*
  member of the class? You're kidding, right?

 I'm dead serious. I often add implementation attributes to either a
 class or an instance. These *are* implementation parts, not API.

If a client accesses a data member of a class, then by definition that
member is not really private, so letting the client create a new data
member and declare it as private seems a bit silly to me. Actually,
just letting the client create the new data member, private or not,
seems like a bit of a stretch to me, but I'll leave that be.

  For the record, I have made it abundantly clear that I don't think
  Python should not have as rigorous an encapsulation regime as C++ or
  Java. The worst that could happen with my proposition is that you
  would need to use a mangled name to access private data or methods.

 That's already the case - when you use __name_mangling. And if there's
 no effective access restriction, then what the point of having this
 'priv' keyword ?

  But you will be using the name many times, you can reassign your own
  name, of course, so the mangled name need not appear more than once
  where it is needed.

 Once again, I just don't see the point. Either you want effective access
 restriction in Python, or you don't. And if you don't, what would this
 'priv' keyword be useful to ?

In the end, I suppose it boils down to aesthetics and personal
preference.

The leading-underscore convention bothers me for two reasons: (1) like
the OP, I don't like the way it makes my code look, and (2) it is a
signal to a person reading the code, but it has no actual effect in
the interpreter.

I think the concept of private data and methods is important enough to
be implemented with more than just a tacky naming convention. That is
why I suggested the priv keyword. At the same time, I realize that
people will occasionally be frustrated if they are rigorously denied
access to all private data, which is why I suggested an indirect
method of access through mangled names.

You can argue that such indirect access defeats the whole idea of
private data, but at least it alerts the client to the fact that he
(or she or it) is accessing private data -- and it does so without
using Hungarian notation.

I would let the priv keyword also be used for data or functions at
file scope. It just seems logical to me. Again, some name mangling
convention could be concocted for those who think they really need
access.

Actually, the whole objection to denied access baffles me a bit. Does
anyone object to not having access from outside a function to local
variables within the function? I doubt it. The other thing is that the
vast majority of Python software, I would guess, is provided with
source code. How many Python applications or libraries are provided
without source code? If you have the source code, you can obviously
just delete the priv keyword anywhere or everywhere it appears. And
if you have a major client who insists on access to all the internals,
just delete all occurrences of priv before you ship the code (or
don't use it to start with).

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 6, 8:28 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
 Russ P. a écrit :



  On Jun 5, 2:27 pm, Dennis Lee Bieber [EMAIL PROTECTED] wrote:
  On Thu, 5 Jun 2008 11:36:28 -0700 (PDT), Russ P.
  [EMAIL PROTECTED] declaimed the following in comp.lang.python:

  would need to use a mangled name to access private data or methods.
  But you will be using the name many times, you can reassign your own
  name, of course, so the mangled name need not appear more than once
  where it is needed.
  Which will break the first time the innards rebind a value to the
  mangled name, as the simplified external name will still be bound to
  the previous value.

  I'm not sure you understood what I meant. In current Python, if I need
  access to data element __XX in class YourClass, I can use
  ZZ._YourClass__XX, but if I don't want to clutter my code with that
  mangled name, I can just write

  XX = ZZ._YourClass__XX

  and refer to it from that point on as XX.

  Obviously if the meaning of
  __XX changes within class ZZ, this will break, but that's why you are
  supposed to avoid using private data in the first place.

 AFAICT, What Dennis meant is that the binding of ZZ._YourClass__XX
 changes between the moment you bind it to local XX and the moment you
 use it, then you're out.

Perhaps I should have stipulated that this should be done only in a
local scope and in an application that is not multi-threaded. Then I
don't see how you can have a problem.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Antoon Pardon]

On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
 On Wed, 04 Jun 2008 09:34:58 +, Antoon Pardon wrote:

 On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
 
 it makes sense to me to also test if they work as documented.
 
 If they affect the behaviour of some public component, that's where
 the documentation should be.

 As I said they are public themselves for someone.
 
 Isn't that contradictory: Public for someone I always
 thought public meant accessible to virtually anyone.
 Not to only someone.

 For the programmer who writes or uses the private API it isn't really
 private, he must document it or know how it works.

How does that make it not private. Private has never meant accessible
to noone. And sure he must document it and know how it works. But that
documentation can remain private, limited to the developers of the
product. It doesn't have to be publicly documented.

-- 
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Marc 'BlackJack' Rintsch]

On Thu, 05 Jun 2008 08:21:41 +, Antoon Pardon wrote:

 On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
 On Wed, 04 Jun 2008 09:34:58 +, Antoon Pardon wrote:

 On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
 
 it makes sense to me to also test if they work as documented.
 
 If they affect the behaviour of some public component, that's where
 the documentation should be.

 As I said they are public themselves for someone.
 
 Isn't that contradictory: Public for someone I always
 thought public meant accessible to virtually anyone.
 Not to only someone.

 For the programmer who writes or uses the private API it isn't really
 private, he must document it or know how it works.
 
 How does that make it not private. Private has never meant accessible
 to noone. And sure he must document it and know how it works. But that
 documentation can remain private, limited to the developers of the
 product. It doesn't have to be publicly documented.

If the audience is the programmer(s) who implement the private API it
is not private but public.  Even the public API is somewhat private to
a user of a program that uses that API.  The public is not virtually
anyone here.  Depends at which level you look in the system.

Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Antoon Pardon]

On 2008-06-05, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
 On Thu, 05 Jun 2008 08:21:41 +, Antoon Pardon wrote:

 On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
 On Wed, 04 Jun 2008 09:34:58 +, Antoon Pardon wrote:

 On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
 
 it makes sense to me to also test if they work as documented.
 
 If they affect the behaviour of some public component, that's where
 the documentation should be.

 As I said they are public themselves for someone.
 
 Isn't that contradictory: Public for someone I always
 thought public meant accessible to virtually anyone.
 Not to only someone.

 For the programmer who writes or uses the private API it isn't really
 private, he must document it or know how it works.
 
 How does that make it not private. Private has never meant accessible
 to noone. And sure he must document it and know how it works. But that
 documentation can remain private, limited to the developers of the
 product. It doesn't have to be publicly documented.

 If the audience is the programmer(s) who implement the private API it
 is not private but public.  Even the public API is somewhat private to
 a user of a program that uses that API.  The public is not virtually
 anyone here.  Depends at which level you look in the system.

I think there is a general consensus about on what level to look when we
are talking about private and public attributes. You can of course
start talking at a whole different level and as such use these words
with a meaning different than normally understood. But that will just
make it harder for you to get your ideas accross.

-- 
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Antoon Pardon a écrit :

On 2008-06-04, NickC [EMAIL PROTECTED] wrote:

On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote:

What is it about leading underscores that bothers me? To me, they are
like a small pebble in your shoe while you are on a hike. Yes, you can
live with it, and it does no harm, but you still want to get rid of it.

With leading underscores, you can see *at the point of dereference*
that the code is accessing private data.


@NickC : InMyArms(tm) !


But the leading underscore doesn't tell you whether it is your own
private date, which you can use a you see fit, or those of someone
else, which you have to be very carefull with.


That's why we have __name_mangling too. Consider '_' as 'protected' and 
'__' as private.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Russ P. a écrit :

(snip)
(answering to Carl Bank) I thought you were saying that encapsulation or so-called 
data
hiding is worthless.


As far as I'm concerned, I view encapsulation as very desirable, and 
data-hidding as totally worthless when applied to Python's object model.



Here's what I think Python should have. I think it should have a
keyword, something like priv, to identify data or functions as
private. As I said earlier, private for class data or functions
(methods) could be implemented like protected in C++. That means
that derived classes would have access to it, but clients of the class
would not. If the client really needs or wants access, he could be
given a sort of back door access similar to the current Python rule
regarding double leading underscores. Thus, the client would have
access, but he would know very well that he is using something that
the original designer did not intend for him to use.




It's just a suggestion. I'm not a language expert, and I realize that
I could be missing something important.


Given your very recent discovery of what 'dynamic' *really* means in 
Python (like, for exemple, dynamically adding / replacing attributes - 
including methods - on a per-class or per-instance basis), possibly, yes.



I also realize, by the way, that Python allows a client of a class to
define a new class member from completely outside the class
definition. Obviously, that cannot be declared private.


Why so ?


But if the
same identifier is already declared private within the class, than the
new definition should not be allowed (because it would defeat the
whole idea of private class members).


Why so ?

Metaprogramming (including monkeypatching) is part of the pythoneer's 
toolbox, and while it's not something to use without pretty good 
reasons, it has many times proven to be a real life saver. In languages 
not allowing it, the solutions to the class of problems easily solved by 
monkeypatching happens to be at best a kludge, at worst plain 
unsolvable, at least without too much effort to be even worth it. Your 
above proposition would arbitrarily make possible and useful things 
either uselessly complicated or near impossible.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Fuzzyman]

On Jun 3, 6:54 pm, sturlamolden [EMAIL PROTECTED] wrote:
 On May 24, 3:41 pm, Sh4wn [EMAIL PROTECTED] wrote:

  first, python is one of my fav languages, and i'll definitely keep
  developing with it. But, there's 1 one thing what I -really- miss:
  data hiding. I know member vars are private when you prefix them with
  2 underscores, but I hate prefixing my vars, I'd rather add a keyword
  before it.

 Python has no data hiding because C++ has (void *).

 Python underscores does some name mangling, but does not attempt any
 data hiding.

 Python and C has about the same approach to data hiding. It is well
 tried, and works equally well in both languages:

# this is mine, keep your filthy paws off!!!

 Irresponsible programmers should not be allowed near a computer
 anyway. If you use data hiding to protect your code from yourself,
 what you really need is some time off to reconsider your career.

So, you are stating that no API programmer using Python *ever* has a
valid or genuine reason for wanting (even if he can't have it) genuine
'hiding' of internal state or members from consumers of his (or
her...) API?

Michael Foord
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[sturlamolden]

On Jun 5, 3:26 pm, Fuzzyman [EMAIL PROTECTED] wrote:

 So, you are stating that no API programmer using Python *ever* has a
 valid or genuine reason for wanting (even if he can't have it) genuine
 'hiding' of internal state or members from consumers of his (or
 her...) API?

 Michael Foordhttp://www.ironpythoninaction.com/

If you are an API programmer, the __all__ attribute of a package or
module provides all the internal data hiding you need.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 5, 4:47 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
 Antoon Pardon a écrit :

  On 2008-06-04, NickC [EMAIL PROTECTED] wrote:
  On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote:
  What is it about leading underscores that bothers me? To me, they are
  like a small pebble in your shoe while you are on a hike. Yes, you can
  live with it, and it does no harm, but you still want to get rid of it.
  With leading underscores, you can see *at the point of dereference*
  that the code is accessing private data.

 @NickC : InMyArms(tm) !

  But the leading underscore doesn't tell you whether it is your own
  private date, which you can use a you see fit, or those of someone
  else, which you have to be very carefull with.

 That's why we have __name_mangling too. Consider '_' as 'protected' and
 '__' as private.

Only in some vague, fuzzy sense.

My understanding is that the single underscore in a class definition
is a convention only and has no actual effect whatsoever. In C++ (and
Java?), on the other hand, the protected keyword *really* prevents
the client from accessing the data or method, but it allows access to
derived classes. The private keyword goes further and prevents
access even by derived classes. The double leading underscore in
Python does no such thing.

By the way, people often claim that friend classes in C++ violate
encapsulation. That is a common misunderstanding. They do not violate
encapsulation because a class must declare its own friends. In other
words, the determination of who gets acces to the private data in a
class is determined within the class itself. Declaring another class a
friend gives it access to your data but does not give you access to
its data. (At least that's my recollection, though I haven't used C++
for several years.)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[George Sakkis]

On Jun 5, 2:07 pm, Russ P. [EMAIL PROTECTED] wrote:

 The private keyword goes further and prevents
 access even by derived classes. The double leading underscore in
 Python does no such thing.

Who develops these derived classes ? A competitor ? A malicious
hacker ? A spammer ? Who are you trying to hide your precious classes
from that the double leading underscore is not good enough
protection ? Even with a 'private' keyword, what stops them from doing
s/private/public/g ? Seriously, the underscores are ugly argument
has some merit but language enforced data hiding is overrated, if not
downright silly.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 5, 4:53 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
 Russ P. a écrit :

 Given your very recent discovery of what 'dynamic' *really* means in
 Python (like, for exemple, dynamically adding / replacing attributes -
 including methods - on a per-class or per-instance basis), possibly, yes.

My very recent discovery? Funny, I thought I knew that several years
ago. You must know more about me than I know about myself.

  I also realize, by the way, that Python allows a client of a class to
  define a new class member from completely outside the class
  definition. Obviously, that cannot be declared private.

 Why so ?

Why should the client of a class not be able to declare a *private*
member of the class? You're kidding, right? Do you mind if I tell you
how to arrange the furniture in your bedroom?

  But if the
  same identifier is already declared private within the class, than the
  new definition should not be allowed (because it would defeat the
  whole idea of private class members).

 Why so ?

 Metaprogramming (including monkeypatching) is part of the pythoneer's
 toolbox, and while it's not something to use without pretty good
 reasons, it has many times proven to be a real life saver. In languages
 not allowing it, the solutions to the class of problems easily solved by
 monkeypatching happens to be at best a kludge, at worst plain
 unsolvable, at least without too much effort to be even worth it. Your
 above proposition would arbitrarily make possible and useful things
 either uselessly complicated or near impossible.

For the record, I have made it abundantly clear that I don't think
Python should not have as rigorous an encapsulation regime as C++ or
Java. The worst that could happen with my proposition is that you
would need to use a mangled name to access private data or methods.
But you will be using the name many times, you can reassign your own
name, of course, so the mangled name need not appear more than once
where it is needed.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 5, 11:25 am, George Sakkis [EMAIL PROTECTED] wrote:
 On Jun 5, 2:07 pm, Russ P. [EMAIL PROTECTED] wrote:

  The private keyword goes further and prevents
  access even by derived classes. The double leading underscore in
  Python does no such thing.

 Who develops these derived classes ? A competitor ? A malicious
 hacker ? A spammer ? Who are you trying to hide your precious classes
 from that the double leading underscore is not good enough
 protection ? Even with a 'private' keyword, what stops them from doing
 s/private/public/g ? Seriously, the underscores are ugly argument
 has some merit but language enforced data hiding is overrated, if not
 downright silly.

I did not claim that Python should have the same encapsulation rules
as C++. I was merely comparing the two in reply to a post that claimed
a similarity.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

 For the record, I have made it abundantly clear that I don't think
 Python should not have as rigorous an encapsulation regime as C++ or
 Java. The worst that could happen with my proposition is that you
 would need to use a mangled name to access private data or methods.
 But you will be using the name many times, you can reassign your own
 name, of course, so the mangled name need not appear more than once
 where it is needed.

Let me try that again:

For the record, I have made it abundantly clear that I don't think
Python should have as rigorous an encapsulation regime as C++ or
Java. The worst that could happen with my proposition is that you
would need to use a mangled name to access private data or methods.
But if you will be using the name many times, you can reassign your
own
name, of course, so the mangled name need not appear more than once
where it is needed.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[[EMAIL PROTECTED]]

On 5 juin, 20:07, Russ P. [EMAIL PROTECTED] wrote:
 On Jun 5, 4:47 am, Bruno Desthuilliers bruno.



 [EMAIL PROTECTED] wrote:
  Antoon Pardon a écrit :

   On 2008-06-04, NickC [EMAIL PROTECTED] wrote:
   On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote:
   What is it about leading underscores that bothers me? To me, they are
   like a small pebble in your shoe while you are on a hike. Yes, you can
   live with it, and it does no harm, but you still want to get rid of it.
   With leading underscores, you can see *at the point of dereference*
   that the code is accessing private data.

  @NickC : InMyArms(tm) !

   But the leading underscore doesn't tell you whether it is your own
   private date, which you can use a you see fit, or those of someone
   else, which you have to be very carefull with.

  That's why we have __name_mangling too. Consider '_' as 'protected' and
  '__' as private.

 Only in some vague, fuzzy sense.

 My understanding is that the single underscore in a class definition
 is a convention only and has no actual effect whatsoever.

It has the expected effect: warn adult programmers that this is
implementation, not interface, so mess with it and you're on your
own.

  In C++ (and
 Java?), on the other hand, the protected keyword *really* prevents
 the client from accessing the data or method, but it allows access to
 derived classes.

And ?

 The private keyword goes further and prevents
 access even by derived classes.

And ?

  The double leading underscore in
 Python does no such thing.

No. It only make sure a child class won't *accidentally* mess things
up. And that's enough as far as I'm concerned.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Roy Smith]

In article 
[EMAIL PROTECTED],
 Russ P. [EMAIL PROTECTED] wrote:
 
 In C++ (and
 Java?), on the other hand, the protected keyword *really* prevents
 the client from accessing the data or method, but it allows access to
 derived classes. The private keyword goes further and prevents
 access even by derived classes.

In C++, it does no such thing.  Consider this class declaration in 
MySecretClass.h:

class MySecretClass {
private:
   int foo;
};

All somebody has to do to get at the private data is:

#define private public
# include MySecretClass.h
#undef private

If playing preprocessor games isn't your thing, there's a whole multitude 
of other tricks you can play with pointers and typecasts that will get you 
access to foo in other ways.

But, you protest, you're not supposed to do that!  Well, of course not.  
But you're not supposed to ignore the leading underscore convention in 
Python either.  That's the nice thing about freedom of religion; you get to 
pick which particular sins you want to get freaked out about.

I'm pretty weak on Java, but my understanding is that it's in better shape 
here, since it has neither textual inclusion of header files, nor pointers.  
You might have to resort to JNI :-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 5, 12:20 pm, Roy Smith [EMAIL PROTECTED] wrote:

 All somebody has to do to get at the private data is:

 #define private public
 # include MySecretClass.h
 #undef private

Well, that shows the weakness of the C/C++ header files. The include
directive merely does a simple text substitution, which is pretty lame
as far as I am concerned. As you say, Java has moved beyond that, and
Ada has always been more sophisticated than that.

By the way, my recollection is that in C++ access defaults to private
if nothing is declared explicity. So normally the private
declaration is unnecessary. If it is left out, your little trick won't
work. But your point is still valid.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Larry Bates]

Russ P. wrote:

On Jun 2, 5:11 pm, Paul Rubin http://[EMAIL PROTECTED] wrote:

Russ P. [EMAIL PROTECTED] writes:

I also realize, by the way, that Python allows a client of a class to
define a new class member from completely outside the class
definition. Obviously, that cannot be declared private.

This is bogus about 95% of the time though.  For the cases where it is
really desired, I think it's best to require the target class to be
enable it specifically somehow, maybe by inheriting from a special
superclass.  That could let the compiler statically resolve member
lookups the rest of the time.


It did seem a bit odd to me when I realized that you can add data
members (or even a methods) to a class from completely outside the
class definition. That can be risky, of course, and as you suggest,
perhaps it shouldn't even be allowed by default.

I usually find that it's safer to initialize in the constructor all
(or nearly all) of the data members that will be needed in a class. If
I need a list that will be populated later, for example, I reserve the
name with an empty list in the constructor. Then, if for some reason
the list gets accessed before it is populated, I don't get an
exception.


That is EXACTLY when I want an exception, I did something that shouldn't happen. 
 You also are missing the nice ability of python to use hasattr() to find out 
if a class instance has a method/attribute.  I use hasattr() to test for 
presence or absence of methods/attributes quite a lot.  In the past I did what 
you describe, but found that to be limiting and a throwback to when I used 
languages that could not do introspection.  I can test to see if the attribute 
exists, if it is empty, which can be two very different conditions that require 
two different actions.  The only way you can do that is to initialize it to 
None.  While this works it is a fictitious construct that we all learned when we 
were writing Fortran, Basic or Cobol years ago (oops I think I just revealed 
that I'm an 'old timer').  Now I just do: if hasattr(self, 'listInQuestion') and 
I can tell if it has been created (either by constructor) or by some other 
method.  This works particularly well when I do caching of data in objects that 
are shared among methods.  I can also do hasattr(object, 'methodInQuestion') to 
see if the object implements an interface that I require.


May be a little off topic, but I think it is relevant.

-Larry
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Matthieu Brucher]

2008/6/5 Russ P. [EMAIL PROTECTED]:

 On Jun 5, 12:20 pm, Roy Smith [EMAIL PROTECTED] wrote:

  All somebody has to do to get at the private data is:
 
  #define private public
  # include MySecretClass.h
  #undef private

 Well, that shows the weakness of the C/C++ header files. The include
 directive merely does a simple text substitution, which is pretty lame
 as far as I am concerned. As you say, Java has moved beyond that, and
 Ada has always been more sophisticated than that.

 By the way, my recollection is that in C++ access defaults to private
 if nothing is declared explicity. So normally the private
 declaration is unnecessary. If it is left out, your little trick won't
 work. But your point is still valid.


And also

#define class struct
#include something.h
#undef class

;)

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[David]

On Wed, Jun 4, 2008 at 2:54 PM, Roy Smith [EMAIL PROTECTED] wrote:
 In article [EMAIL PROTECTED],
  Ben Finney [EMAIL PROTECTED] wrote:

 By definition, private functions are not part of the publicly
 documented behaviour of the unit. Any behaviour exhibited by some
 private component is seen externally as a behaviour of some public
 component.

 You know the difference between theory and reality?  In theory, there is
 none...  Sometimes it's useful to test internal components.  Imagine this
 class:

 class ArmegeddonMachine:
   def pushTheButton(self):
  Destroy a random city
  city = self._pickCity()
  self._destroy(city)

   def _pickCity():
  cities = ['New York', 'Moscow', 'Tokyo', 'Beijing', 'Mumbai']
  thePoorSchmucks = random.choice(cities)
  return 'New York'

   def _destroy(self, city):
  missle = ICBM()
  missle.aim(city)
  missle.launch()

 The only externally visible interface is pushTheButton(), yet you don't
 really want to call that during testing.  What you do want to do is test
 that a random city really does get picked.

 You can do one of two things at this point.  You can say, But, that's not
 part of the externally visible interface and refuse to test it, or you can
 figure out a way to test it.  Up to you.
 --
 http://mail.python.org/mailman/listinfo/python-list


Sorry for the long post in advance. I'm busy studying unit testing、and
here is how I would go about testing the above code.

1) Make the code more testable through public (not private)
interfaces. ie, split out the functionality into more public, but
still properly encapsulated forms (modules/classes, etc). Don't need
to make everything public, just enough that it's testable without
digging into privates attributes, but still well-encapsulated.

2) Link the split-up logic together (eg, in class constructors). Use
public attributes for this. Or use private attributes, but make them
updatable through public methods.

3) In the unit tests update the object being tested, so it uses mock
objects instead of the ones it uses by default (aka dependency
injection).

4) Run the methods to be tested, and check that the mock objects were
updated correctly.

Here is an example (very rough, untested  incomplete):

# Updated armageddonmachine module:

class CityPicker:
   def pick(self):
  cities = ['New York', 'Moscow', 'Tokyo', 'Beijing', 'Mumbai']
  thePoorSchmucks = random.choice(cities)
  return 'New York' # Your bug is still here

class Destroyer:
   def destroy(self, city):
  missle = ICBM()
  missle.aim(city)
  missle.launch()

class ArmegeddonMachine:
   def __init__(self):
  self.city_picker = CityPicker()
  self.destroyer = Destroyer()

   def pushTheButton(self):
  Destroy a random city
  city = self.city_picker.pick()
  self.destroyer.destroy(city)

# unit test module for armageddonmachine
# Only has tests for CityPicker and ArmageddonMachine

import armageddonmachine

# Unit test code for CityPicker


# -- Mock objects --


class MockRandom:
   def __init__(self):
  self.choose = None
   def choice(self, list_):
  assert self.choose is not None
 return list_[self.choose]


class TestCityPicker:
   def setup()
  # Setup code run before each unit test in this class
  self.city_picker = CityPicker()
  self._bkp_random = armaggedonmachine.random

   def teardown()
  # Teardown  code run after each unit test in this class
  armaggedonmachine.random = self._bkp_random

   def test_should_pick_random_cities_correctly(self):
  armaggedonmachine.random = MockRandom()

  armaggedonmachine.choose = 0
  assert city_picker.pick() == 'New York'

  armaggedonmachine.choose = 1
  assert city_picker.pick() == 'Moscow' # This will catch your bug

  armaggedonmachine.choose = 2
  assert city_picker.pick() == 'Tokyo'

  armaggedonmachine.choose = 3
  assert city_picker.pick() == 'Beijing'

  armaggedonmachine.choose = 4
  assert city_picker.pick() == 'Mumbai'

# Unit test code for ArmageddonMachine

# -- Mock Classes --


class MockCityPicker:
  def __init__(self):
self.city_to_pick = Test City

  def pick(self):
return self.city_to_pick


class MockDestroyer:
  def __init__(self):
 self.destroyed_cities = set()

  def destroy(self, city):
 self.destroyed_cities.append(city)


# -- Unit Tests

class TestArmageddonMachine:

  def setup(self):
# Setup code that runs before each unit test in this class
self.machine = ArmageddonMachine()
self._bkp_picker = self.machine.city_picker
self._bkp_destroyer = self.machine.destroyer
self.machine.city_picker = MockCityPicker()
self.machine.destroyer = MockCityDestroyer()

  def test_should_destroy_a_city(self):
 self.machine.pushTheButton()
 assert self.machine.destroyer.destroyed_cities == Test City
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[Hrvoje Niksic]

Russ P. [EMAIL PROTECTED] writes:

 By the way, my recollection is that in C++ access defaults to private
 if nothing is declared explicity. So normally the private
 declaration is unnecessary. If it is left out, your little trick won't
 work.

How about #define class struct
--
http://mail.python.org/mailman/listinfo/python-list