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
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
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
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
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,
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
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
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
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
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
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,
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
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
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
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
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,
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
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,
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
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,
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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[] =
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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),
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
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
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
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
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,
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
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
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
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
--
Roy Smith [EMAIL PROTECTED] writes:
In article [EMAIL PROTECTED],
Ben Finney [EMAIL PROTECTED] wrote:
Then what you're really testing is the interactions of the push
the button function with its external interface: you're asserting
that the push the red button function actually uses
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
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
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] writes:
On Wed, 04 Jun 2008 13:50:42 +1000, Ben Finney wrote:
It seems you [alex23] have a different idea of what unit testing
is for from me.
For me it's about finding bugs where documentation and
implementation disagree.
Where documentation
On 2008-06-03, Lie [EMAIL PROTECTED] wrote:
Python has an extremely good design because the BDFL doesn't just
listen to everyone and create a product that tries to please
everybody, no, he listens to those that have good ideas and tells the
stupid ideas to go away and he applies a subjective
On 2008-06-03, sturlamolden [EMAIL PROTECTED] wrote:
On Jun 2, 12:40 pm, Antoon Pardon [EMAIL PROTECTED] wrote:
I think you completed missed the point.
This is just a proof of concept thing. In a real example there would
of course no Set en Get methods but just methods that in the course
of
On Wed, 04 Jun 2008 15:55:38 +1000, Ben Finney wrote:
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] writes:
On Wed, 04 Jun 2008 13:50:42 +1000, Ben Finney wrote:
It seems you [alex23] have a different idea of what unit testing
is for from me.
For me it's about finding bugs where
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
On May 26, 7:32 am, Joe P. Cool [EMAIL PROTECTED] wrote:
I saw this don't need it pattern in discussions about the ternary
if..else expression and about except/finally on the same block
level.
Now Python has both.
if/else was added solely because people kept coming up with ways of
embedding a
On May 26, 2:49 pm, Russ P. [EMAIL PROTECTED] wrote:
I am also bothered a bit by the seeming inconsistency of the rules for
the single underscore. When used at file scope, they make the variable
or function invisible outside the module, but when used at class
scope, the underscored variables
NickC [EMAIL PROTECTED] writes:
if/else was added solely because people kept coming up with ways of
embedding a pseudo conditional inside expressions and writing buggy
code in the process. All it really saves you in practice is a bit of
vertical whitespace, so, no, you still don't need it -
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
On May 25, 8:01 pm, Fuzzyman [EMAIL PROTECTED] wrote:
Python was not really written with 'difficult' customers in mind ;-)
True. It's extremely suited to what we do though.Minor difficulties
like this are vastly outweighed by advantages. The difficulties are
real though.
It's interesting to
On Jun 4, 4:41 pm, Antoon Pardon [EMAIL PROTECTED] wrote:
Guido has been known to change his mind, which is an admirabele quality,
but it does show that at some point he rejected a good idea or accepted
a bad idea.
And sometimes the person that talked him into accepting the bad idea
in the
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] writes:
On Wed, 04 Jun 2008 15:55:38 +1000, Ben Finney 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
On Jun 4, 9:24 pm, Paul Rubin http://[EMAIL PROTECTED] wrote:
NickC [EMAIL PROTECTED] writes:
if/else was added solely because people kept coming up with ways of
embedding a pseudo conditional inside expressions and writing buggy
code in the process. All it really saves you in practice is a
On Jun 4, 9:56 pm, Ben Finney [EMAIL PROTECTED]
wrote:
Those unit tests should *not*, though, exercise anything but the
public API, otherwise they're breaking encapsulation. Their assertion
should continue to be just as true after a refactoring of the internal
components as before.
Python
On 2008-06-04, NickC [EMAIL PROTECTED] wrote:
On May 26, 7:32 am, Joe P. Cool [EMAIL PROTECTED] wrote:
I saw this don't need it pattern in discussions about the ternary
if..else expression and about except/finally on the same block
level.
Now Python has both.
if/else was added solely
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
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.
--
Antoon Pardon
Well how is that different from public accessor and mutators of
private variables?
--
On 2008-06-04, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
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.
--
Antoon Pardon
Well how is that different from
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
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
On Jun 4, 2:58 pm, Russ P. [EMAIL PROTECTED] wrote:
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,
Roy Smith [EMAIL PROTECTED] writes:
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.
Then what you're really testing is the interactions of the push the
Lie wrote:
On May 24, 9:14 pm, Fuzzyman [EMAIL PROTECTED] wrote:
For example, at Resolver Systems we expose the spreadsheet object
model to our users. It hasa public, documented, API - plus a host of
undocumented internally used methods.
We would really *much* rather hide these, because
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
Ben Finney wrote:
Roy Smith [EMAIL PROTECTED] writes:
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.
Then what you're really testing is the
Ethan Furman [EMAIL PROTECTED] writes:
I must be missing something in this discussion. Perhaps it's the
appropriate point of view. At any rate, it seems to me that any and
every function should be tested to ensure proper results.
I restrict that to every proper behaviour the system is
In article [EMAIL PROTECTED],
Ben Finney [EMAIL PROTECTED] wrote:
Then what you're really testing is the interactions of the push the
button function with its external interface: you're asserting that
the push the red button function actually uses the result from pick
a random city as its
On 2008-06-03, Carl Banks [EMAIL PROTECTED] wrote:
On Jun 2, 10:14 am, Antoon Pardon [EMAIL PROTECTED] wrote:
On 2008-06-02, Carl Banks [EMAIL PROTECTED] wrote:
Can't you look beyond the specific example? The GetX is just an example.
Any local function of __init__ has access to hidden and its
1 - 100 of 171 matches
Mail list logo
