On Mon, 24 Jan 2005 12:17:13 -0600, Philippe C. Martin
[EMAIL PROTECTED] wrote:
I use __for private variables because I must have read on net it was
the way to do so - yet this seems to have changed - thanks:
http://www.network-theory.co.uk/docs/pytut/tut_77.html
Nope, that's still the
Name mangling is there to keep you from accidentally hiding such an
attribute in a subclass, but how often is this really a danger? Can
someone give me an example of where __-mangling really solved a
problem
for them, where a simple leading underscore wouldn't have solved the
same problem?
Look
Jeremy Bowers [EMAIL PROTECTED] wrote:
[ ... ] the Python community, and in general the dynamic language
community, has become increasingly confident that private variables don't
solve *real* problems.
Years of writing and maintaining others' C++ and Java code (plus
one year of maintaining
Well I _was_ a bit slow on that one !
So I will happily stick to the double underscore.
Regards,
Philippe
Le mardi 25 janvier 2005 10:28 +, Simon Brunning a crit :
On Mon, 24 Jan 2005 12:17:13 -0600, Philippe C. Martin
[EMAIL PROTECTED] wrote:
I use __for private variables
[Toby]
The problem occured because the double-underscore mangling uses the class
name, but ignores module names. A related project already had a class named C
derived from B (same name - different module).
Yikes! A pretty bizarre case, but nasty when it hits. I guess the
Toby Dickenson wrote:
I have a counterexample. Consider refactoring a class from
class B(A):
etc
into
class C(A):
etc
class B(C):
etc
Usage of some double-undescore attributes moved from B to the new intermediate
base class C. Unit tests on B still passed, so that change
Is it possible to create own statements, such that it would be
possible to do:
printDebug test
?
This question is well addressed in a neighbour group comp.lang.lisp .
--
http://mail.python.org/mailman/listinfo/python-list
Michael Hoffman [EMAIL PROTECTED] wrote:
Frans Englich wrote:
Nah, I don't think it's a function, but rather a builtin statement. But
it's
possible to invoke it as an function; print( test ) works fine.
That is not invoking it as a function. The parentheses are only for
ordering the
On Sun, 23 Jan 2005 18:01:50 +, Frans Englich wrote:
Nah, I don't think it's a function, but rather a builtin statement. But
it's possible to invoke it as an function; print( test ) works fine.
So I wonder, what _is_ exactly the print statement? The untraditional
way of invoking
Why don't you redirect stdout or stderr
#***
class Debug_Stderr:
__m_text = ''
__m_log_text = None
__m_dbg = None
__m_refresh_count = 0
Philippe C. Martin wrote:
class Debug_Stderr:
__m_text = ''
__m_log_text = None
__m_dbg = None
__m_refresh_count = 0
rant
I don't see the benefit in 99.9% of cases for making class variables
like this private. If you don't want people to use them, simply use
the standard
I use __for private variables because I must have read on net it was
the way to do so - yet this seems to have changed - thanks:
http://www.network-theory.co.uk/docs/pytut/tut_77.html
As far as the specific stderr reroute example - I just grabbed some of
my code and forgot to get rid of that
On Mon, 24 Jan 2005 12:17:13 -0600, Philippe C. Martin wrote:
I use __for private variables because I must have read on net it was the
way to do so - yet this seems to have changed -
It's still as true as ever, at least in terms of language support, it's
just that the Python community, and in
Frans Englich wrote:
Nah, I don't think it's a function, but rather a builtin statement. But it's
possible to invoke it as an function; print( test ) works fine.
That is not invoking it as a function. The parentheses are only for
ordering the expression on the right
You can do this too:
The reason I thinks about this is I need to implement a debug print for my
program; very simple, a function/print statement that conditionally prints
its message whether a bool is true. Not overly complex.
I tried this by overshadowing the print keyword, but that obviously didn't
work.. Is
On Sunday 23 January 2005 18:04, Michael Hoffman wrote:
Frans Englich wrote:
[...]
if command_line_debug_option:
debug = _debug_true
else
debug = _debug_false
I find this a nice solution. The most practical would be if it was possible to
do this with print, of course. But print
Frans Englich wrote:
I find this a nice solution. The most practical would be if it was possible to
do this with print, of course. But print won't budge.
you can disable print, though:
class dev_null:
def write(self, text):
pass
sys.stdout = dev_null()
or pipe all
Frans Englich [EMAIL PROTECTED] wrote:
Nah, I don't think it's a function, but rather a builtin statement. But
it's possible to invoke it as an function; print( test ) works fine.
That's not calling it as a function. The parens in this case are simply
evaluated as grouping operators around
Roy Smith wrote:
So I wonder, what _is_ exactly the print statement? The untraditional way of
invoking it(without paranteses) makes me wonder.
It's a statement, just like write in Fortran. When C came around, the
idea of a language having no built-in print statement and having to call
Frans Englich [EMAIL PROTECTED] writes:
The reason I thinks about this is I need to implement a debug print for my
program; very simple, a function/print statement that conditionally prints
its message whether a bool is true. Not overly complex.
As several folks have said, print is a
Frans Englich wrote:
The reason I thinks about this is I need to implement a debug print for my
program; very simple, a function/print statement that conditionally prints
its message whether a bool is true. Not overly complex.
Sounds like you want to override sys.stdout:
py class
21 matches
Mail list logo
