Russ P. a écrit :
On Jan 26, 1:07 am, Bruno Desthuilliers bruno.
42.desthuilli...@websiteburo.invalid wrote:
No. I can change the *team's* code. Please *read*. team's ownership,
ok ? Or do I have to spell it out loud ? TEAM'S OWNERSHIP. Uh. You get
the message, now ?
Team ownership doesn't
On Tuesday 27 January 2009 04:39:02 am Bruno Desthuilliers wrote:
Still not. But it's interesting to note that you consider everyone
disagreeing with you as basically the same person.
Hehe. At the beginning of this thread, I also thought that Russ P. and Paul
Robin were the same person. I have
Luis Zarrabeitia k@uh.cu wrote:
8
Hehe. At the beginning of this thread, I also thought that Russ P. and Paul
Robin were the same person. I have serious problems with names.
*nods in agreement, because the man's surname is Rubin, not Robin*
:-)
- Hendrik
--
On Jan 21, 2:11 am, Mark Wooding m...@distorted.org.uk wrote:
CLOS is much more complex and dynamic than Python's object system; but it
can be compiled very aggressively.
I agree that CLOS is complex and that it can be compiled very
aggressively, but I do not think that it is more dynamic
On Jan 26, 6:09 am, Steve Holden st...@holdenweb.com wrote:
Quite. Python is a language for consenting adults. It has perceived
deficiencies for certain software engineering environments. Can we drop
the subject now? This horse was flogged to death long ago, and it's
pointless and cruel to
On Tuesday 27 January 2009 02:13:50 pm Russ P. wrote:
I suggested that maybe -- maybe! -- the versatility of Python could be
enhanced with enforced data hiding. I was careful to say several times
that I don't know if that can even be done in Python (with all its
introspection and so forth).
On Jan 27, 11:40 am, Luis Zarrabeitia ky...@uh.cu wrote:
I think you still fail to see that what we are objecting is not that the
original writer can optionally use the enforced data hiding (which, as
someone pointed out before me, can be done with tools like pylint). The
objection is about
[No, my email address doesn't begin `m...@'. Fixed.]
Michele Simionato michele.simion...@gmail.com writes:
On Jan 21, 2:11 am, Mark Wooding m...@distorted.org.uk wrote:
CLOS is much more complex and dynamic than Python's object system;
but it can be compiled very aggressively.
I agree
On Jan 27, 12:13 pm, Russ P. russ.paie...@gmail.com wrote:
On Jan 26, 6:09 am, Steve Holden st...@holdenweb.com wrote:
Quite. Python is a language for consenting adults. It has perceived
deficiencies for certain software engineering environments. Can we drop
the subject now? This horse was
Paul Rubin wrote:
Scott David Daniels scott.dani...@acm.org writes:
But, the research on the language Self shows that even in the face
of a language with more dynamism than Smalltalk (or Python), performance
can be obtained using compiler technology
I'd be interested in seeing any
Russ P. russ.paie...@gmail.com writes:
If Python had a private keyword (or equivalent), for example, the
user would only need to delete it wherever necessary to gain the
desired access.
And you obviously weren't listening when we said that having to make
source code changes to upstream
On Tuesday 27 January 2009 02:56:51 pm Russ P. wrote:
On Jan 27, 11:40 am, Luis Zarrabeitia ky...@uh.cu wrote:
I think you still fail to see that what we are objecting is not that the
original writer can optionally use the enforced data hiding (which, as
someone pointed out before me, can
On Jan 27, 9:13 pm, Mark Wooding m...@distorted.org.uk wrote:
I'm referring to a number of features:
* Redefinition of classes, yes. Interactive development is very
frustrating without this. Thanks for that link, by the way!
* CHANGE-CLASS to change the class of instances. This is
Russ P. a écrit :
On Jan 23, 4:57 am, Bruno Desthuilliers bruno.
42.desthuilli...@websiteburo.invalid wrote:
Russ P. a écrit :
As I said before, if you have the source code you can always change
private attributes to public in a pinch if the language enforces
encapsulation.
And then have to
Russ P. a écrit :
On Jan 23, 6:36 pm, Luis Zarrabeitia ky...@uh.cu wrote:
Makes *no* sense? There's *no* good reason *at all* for the original
author to hide or protect internals?
My bad, sorry.
It makes sense... if the original author is an egotist who believes he must
control how I use that
Bruno Desthuilliers wrote:
Russ P. a écrit :
On Jan 23, 6:36 pm, Luis Zarrabeitia ky...@uh.cu wrote:
Makes *no* sense? There's *no* good reason *at all* for the original
author to hide or protect internals?
My bad, sorry.
It makes sense... if the original author is an egotist who believes
Steve Holden st...@holdenweb.com writes:
Quite. Python is a language for consenting adults.
Shouldn't such a language allow consenting adults to enter a BDSM
scene without being moralized at, if that's what they want to do? ;-)
--
http://mail.python.org/mailman/listinfo/python-list
2009/1/26 Paul Rubin http://phr.cx@nospam.invalid:
Steve Holden st...@holdenweb.com writes:
Quite. Python is a language for consenting adults.
Shouldn't such a language allow consenting adults to enter a BDSM
scene without being moralized at, if that's what they want to do? ;-)
The language
Paul Rubin wrote:
Steve Holden st...@holdenweb.com writes:
Quite. Python is a language for consenting adults.
Shouldn't such a language allow consenting adults to enter a BDSM
scene without being moralized at, if that's what they want to do? ;-)
Yes, but you know what moralizers are like
Russ P. a écrit :
(snip)
You are trying to dictate that the library implementer not be allowed
to use enforced access restriction. And, in the larger sense, you are
trying to dictate that access restrictions not be enforced in Python.
FWIW, it's actually *you* who are trying to dictate that
On Jan 26, 1:07 am, Bruno Desthuilliers bruno.
42.desthuilli...@websiteburo.invalid wrote:
No. I can change the *team's* code. Please *read*. team's ownership,
ok ? Or do I have to spell it out loud ? TEAM'S OWNERSHIP. Uh. You get
the message, now ?
Team ownership doesn't necessarily mean
Quoting Russ P. russ.paie...@gmail.com:
On Jan 24, 9:54 pm, Luis Zarrabeitia ky...@uh.cu wrote:
Quoting Russ P. russ.paie...@gmail.com:
It is. For starters, I'd lose the information of this attribute was
intended to
be internal and I'm accessing it anyway.
Not really. When you get a
Russ P. russ.paie...@gmail.com writes:
Calling a one-word change a fork is quite a stretch, I'd say.
I wouldn't. I've forked a project P if I've made a different version of
it which isn't going to be reflected upstream. Now I've got to maintain
my fork, merging in changes from upstream as
Russ P. russ.paie...@gmail.com writes:
Imagine a person who repairs computers. He is really annoyed that he
constantly has to remove the cover to get at the guts of the computer.
So he insists that computers cases should be made without covers.
Poor analogy. He gets fed up that the computers
On Jan 25, 10:04 am, Mark Wooding m...@distorted.org.uk wrote:
Russ P. russ.paie...@gmail.com writes:
Calling a one-word change a fork is quite a stretch, I'd say.
I wouldn't. I've forked a project P if I've made a different version of
it which isn't going to be reflected upstream. Now
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Fri, 23 Jan 2009 21:36:59 -0500, Luis Zarrabeitia wrote:
It makes sense... if the original author is an egotist who believes he
must control how I use that library.
Then I guess Guido must be such an egotist, because there's
On Jan 25, 10:04 am, Mark Wooding m...@distorted.org.uk wrote:
But what if I want an automatic check to verify that I am using it as
the author intended? Is that unreasonable?
You mean that you can't /tell/ whether you typed mumble._seekrit?
You're very strange. It's kind of hard to do by
On Sun, 25 Jan 2009 12:01:16 -0800, Russ P. wrote:
On Jan 25, 10:04 am, Mark Wooding m...@distorted.org.uk wrote:
But what if I want an automatic check to verify that I am using it as
the author intended? Is that unreasonable?
You mean that you can't /tell/ whether you typed
On Mon, 26 Jan 2009 00:59:48 +, Steven D'Aprano wrote:
How is this scenario different from an API change where public_method()
gets changed to method()?
Sorry, that's a poor example, since you were talking about attributes
rather than methods. Must stop posting before coffee *wink*
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
How is this scenario different from an API change where
self.some_attribute gets changed to self.attribute?
That would be a backward incompatible change to a published interface,
something that should not be done without a good
On Sun, 25 Jan 2009 17:15:47 -0800, Paul Rubin wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
How is this scenario different from an API change where
self.some_attribute gets changed to self.attribute?
That would be a backward incompatible change to a published
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
We're not talking specifically about Python standard library changes,
we're talking about any project which may have more entertaining *cough*
policies regarding API changes.
Oh, yes, I see what you mean. That's a problem even in
Russ P. russ.paie...@gmail.com writes:
On Jan 25, 10:04 am, Mark Wooding m...@distorted.org.uk wrote:
But what if you type mumble._seekrit in several places, then the
library implementer decides to give in to your nagging and makes it
public by changing it to mumble.seekrit.
There's a
On Jan 25, 5:31 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
It seems to me that Russ' latest objection to _private names is not
specific to _private names. The same problem:
You will get no warning at all. You will just be inadvertently
creating a new private attribute
Russ P. russ.paie...@gmail.com writes:
[snip stuff I don't disagree with]
That makes renaming and refactoring riskier in general in Python than
in statically typed languages with enforced access restrictions. More
care and attention to detail is needed to do it right in Python.
In fact, I
On Jan 25, 7:56 pm, Mark Wooding m...@distorted.org.uk wrote:
Russ P. russ.paie...@gmail.com writes:
[snip stuff I don't disagree with]
That makes renaming and refactoring riskier in general in Python than
in statically typed languages with enforced access restrictions. More
care and
Paul Rubin http://phr...@nospam.invalid wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
We're not talking specifically about Python standard library changes,
we're talking about any project which may have more entertaining *cough*
policies regarding API changes.
On Fri, 23 Jan 2009 21:36:59 -0500, Luis Zarrabeitia wrote:
Quoting Steven D'Aprano st...@remove-this-cybersource.com.au:
On Fri, 23 Jan 2009 13:07:55 -0500, Luis Zarrabeitia wrote:
It should be in _our_ power as the team of all participant coders on
_our_ project to decide if we should
Quoting Russ P. russ.paie...@gmail.com:
On Jan 23, 6:36 pm, Luis Zarrabeitia ky...@uh.cu wrote:
Makes *no* sense? There's *no* good reason *at all* for the original
author to hide or protect internals?
My bad, sorry.
It makes sense... if the original author is an egotist who
2009/1/24 Rhodri James rho...@wildebst.demon.co.uk:
My experience with medium-sized organisations (50-100 people) is that
either you talk to Fred directly, or it doesn't happen. In particular
the more people (especially PHBs) that get involved, the slower the
change will come and the less
Quoting Steven D'Aprano st...@remove-this-cybersource.com.au:
On Fri, 23 Jan 2009 21:36:59 -0500, Luis Zarrabeitia wrote:
Quoting Steven D'Aprano st...@remove-this-cybersource.com.au:
Makes *no* sense? There's *no* good reason *at all* for the original
author to hide or protect
On Jan 24, 4:17 pm, Luis Zarrabeitia ky...@uh.cu wrote:
Quoting Russ P. russ.paie...@gmail.com:
On Jan 23, 6:36 pm, Luis Zarrabeitia ky...@uh.cu wrote:
Makes *no* sense? There's *no* good reason *at all* for the original
author to hide or protect internals?
My bad, sorry.
It
On Jan 24, 5:09 pm, Luis Zarrabeitia ky...@uh.cu wrote:
I didn't say at all. Those were your words, not mine.
I said that it makes no sense that the power lies on _you_ instead of on _my
team_. And, when I said that, I recall we were talking about the python
language, not C.
Once again, if
On Sun, 25 Jan 2009 00:31:14 -, Tim Rowe digi...@gmail.com wrote:
2009/1/24 Rhodri James rho...@wildebst.demon.co.uk:
My experience with medium-sized organisations (50-100 people) is that
either you talk to Fred directly, or it doesn't happen. In particular
the more people (especially
Quoting Russ P. russ.paie...@gmail.com:
Once again, if you have the source code for the library (and the right
to modify it), how does the power lie with the library implementer
rather than you the user?
You say you don't want to fork the library. Let's stipulate for the
sake of argument
On Jan 24, 9:54 pm, Luis Zarrabeitia ky...@uh.cu wrote:
Quoting Russ P. russ.paie...@gmail.com:
Once again, if you have the source code for the library (and the right
to modify it), how does the power lie with the library implementer
rather than you the user?
You say you don't want to
Steven D'Aprano a écrit :
On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
But if you have free access to attributes, then
Russ P. a écrit :
On Jan 21, 4:04 am, Bruno Desthuilliers bruno.
42.desthuilli...@websiteburo.invalid wrote:
Russ P. a écrit :
(snip)
Your mistake for being a moron. But it seems to happen regularly,
doesn't it. How much more of my time are you going to waste, loser?
Calling people names is
On Jan 23, 1:54 am, Bruno Desthuilliers bruno.
42.desthuilli...@websiteburo.invalid wrote:
Steven D'Aprano a écrit :
On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Thu, 22 Jan 2009 15:12:31 +0100, Bruno
On Jan 22, 9:22 pm, Russ P. russ.paie...@gmail.com wrote:
code. You can play around with the internals all you want in your own
little world, but as when you are working with a team, you need to
adhere to the interfaces they define (if any).
The word as should not be there:
... but when you
On 2009-01-16, Luis Zarrabeitia ky...@uh.cu wrote:
Quoting Russ P. russ.paie...@gmail.com:
On Jan 15, 12:21 pm, Bruno Desthuilliers
bdesth.quelquech...@free.quelquepart.fr wrote:
Once again, the important point is that there's a *clear* distinction
between interface and implementation,
On Fri, 23 Jan 2009 10:54:53 +0100, Bruno Desthuilliers wrote:
In context, I had just mentioned that lists' internals were
inaccessible from Python code. I neglected to give an example at the
time, but a good example is the current length of the list. Consider
the experience of Microsoft and
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote:
Well, your claim /was/ just wrong. But if you want to play dumb: the
interface is what's documented as being the interface.
But you miss my point.
Evidently.
We're told
Russ P. a écrit :
(snip)
I am curious about something. Have you ever needed to access a
private attribute (i.e., one named with a leading underscore) in
Python code that you did not have the source code for? For that
matter, have you ever even used a library written in Python without
having
On Jan 23, 4:30 am, Mark Wooding m...@distorted.org.uk wrote:
Suppose that you write a Python library module and release it. I find
that it's /almost/ the right thing for some program of mine, but it
doesn't quite work properly unless I hack about like so... perfect! I'm
a happy bunny;
On Fri, 23 Jan 2009 13:57:52 +0100, Bruno Desthuilliers wrote:
As I said before, if you have the source code you can always change
private attributes to public in a pinch if the language enforces
encapsulation.
And then have to maintain a fork. No, thanks.
If you're messing with the
On Jan 23, 4:57 am, Bruno Desthuilliers bruno.
42.desthuilli...@websiteburo.invalid wrote:
Russ P. a écrit :
As I said before, if you have the source code you can always change
private attributes to public in a pinch if the language enforces
encapsulation.
And then have to maintain a
On Fri, 23 Jan 2009 05:42:38 -0800, Russ P. wrote:
My my my. If you don't trust your programmers, then indeed, don't use
Python. What can I say (and what do I care ?). But once again, relying
on the language's access restriction to manage *security* is, well,
kind of funny, you know ?
Are
Bruno Desthuilliers wrote:
Russ P. a écrit :
[...]
Mr. D'Aprano gave an excellent example of a large banking program.
Without enforced encapsulation, anyone on the development team has
access to the entire program and could potentially sneak in fraudulent
code much more easily than if
Hello
thats excellant !!
On 1/23/09, Russ P. russ.paie...@gmail.com wrote:
On Jan 23, 4:57 am, Bruno Desthuilliers bruno.
42.desthuilli...@websiteburo.invalid wrote:
Russ P. a écrit :
As I said before, if you have the source code you can always change
private attributes to public in
2009/1/22 Scott David Daniels scott.dani...@acm.org:
Having once been a more type-A, I labored for a couple of years trying
to build a restricted language that provably terminated for work on an
object-oriented database research.
I was careful to say that it was the /use/ of the language that
On Jan 23, 6:21 am, Steve Holden st...@holdenweb.com wrote:
I have to say that I thought the example was somewhat bogus. Any
development team that is even slightly concerned about the possibility
of logic bombs in the code will try to mitigate that possibility by the
use of code inspections.
On Friday 23 January 2009 06:31:50 am Antoon Pardon wrote:
On 2009-01-16, Luis Zarrabeitia ky...@uh.cu wrote:
Quoting Russ P. russ.paie...@gmail.com:
If you *shouldn't* mess with the implementation, then what is wrong
with enforcing that shouldn't in the language itself?
Because, as a
Russ P. russ.paie...@gmail.com writes:
OK, fine, you can change the code of another member of the team. Are
you going to check with him first, or just do it? The point is that
changing an interface requires agreement of the team members who use
that interface, whether on the calling or the
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
You've built something full of user serviceable parts. You've
insisted, publicly and loudly, that the ability to modify those parts
is absolutely essential, you've rejected every effort to lock down
those internals, and then when
Russ P. russ.paie...@gmail.com writes:
Was this library module released in source form?
If so, then why would you care that it has enforced access
restrictions? You can just take them out, then do whatever you would
have done had they not been there to start with. I don't see how that
is
Steve Holden st...@holdenweb.com writes:
Annotations *have* made it into 3.0, so it's possible that the might
become usable. Remember, they'll always be optional, so those who don't
want to use them won't lose anything at all.
There's a problem here. An interface has two sides. Access
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Fri, 23 Jan 2009 13:57:52 +0100, Bruno Desthuilliers wrote:
Why on earth couldn't I change the code of another member of my team if
that code needs changes ? The code is the whole team's ownership.
That's a model that works well
Mark Wooding m...@distorted.org.uk writes:
Now we come on to Fred. If Fred's across the room from me then we're
back to the water-cooler. If he's on a different continent, and I know
he'll be affected, I'll probably email him. If I've never heard of him
at all, well, he might just lose when
On Fri, 23 Jan 2009 20:09:48 +, Mark Wooding wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Fri, 23 Jan 2009 13:57:52 +0100, Bruno Desthuilliers wrote:
Why on earth couldn't I change the code of another member of my team
if that code needs changes ? The code is
On Fri, 23 Jan 2009 13:07:55 -0500, Luis Zarrabeitia wrote:
It should be in _our_ power as the team of all participant coders on
_our_ project to decide if we should mess with the internals or not.
What makes no sense is that it should be in the original author's power
to decide, if he is
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
I did? Where did I make that assumption?
I inferred it from the juxtaposition, apparently in error. Sorry.
What I said was that the model The code is the whole team's ownership
doesn't work well for large projects. *One* reason
On Jan 23, 7:01 pm, Mark Wooding m...@distorted.org.uk wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
I did? Where did I make that assumption?
I inferred it from the juxtaposition, apparently in error. Sorry.
What I said was that the model The code is the whole team's
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
Let's be specific here. The list implementation in CPython is an array
with a hidden field storing the current length. If this hidden field was
exposed to Python code, you could set it to a value much larger than the
actual size
Mark Wooding wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
I did? Where did I make that assumption?
I inferred it from the juxtaposition, apparently in error. Sorry.
What I said was that the model The code is the whole team's ownership
doesn't work well for large
On Fri, 23 Jan 2009 21:28:22 -, Paul Rubin
http://phr.cx@nospam.invalid wrote:
Mark Wooding m...@distorted.org.uk writes:
Now we come on to Fred. If Fred's across the room from me then we're
back to the water-cooler. If he's on a different continent, and I know
he'll be affected, I'll
Quoting Steven D'Aprano st...@remove-this-cybersource.com.au:
On Fri, 23 Jan 2009 13:07:55 -0500, Luis Zarrabeitia wrote:
It should be in _our_ power as the team of all participant coders on
_our_ project to decide if we should mess with the internals or not.
What makes no sense is
Rhodri James rho...@wildebst.demon.co.uk writes:
My experience with medium-sized organisations (50-100 people) is that
either you talk to Fred directly, or it doesn't happen. In particular
the more people (especially PHBs) that get involved, the slower the
change will come and the less like
On Sat, 24 Jan 2009 03:18:05 -, Paul Rubin
http://phr.cx@nospam.invalid wrote:
It is, to some extent, also
part of the PHB's job to filter the traffic and protect both Fred
and you from making too many interruptions for each other. This is
especially important if you're the type of
On Sat, 24 Jan 2009 01:41:35 +, Mark Wooding wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
...
As I see it, you have two coherent positions. On the one hand, you
could be like Mark Wooding, and say that Yes you want to risk buffer
overflows by messing with the
On Jan 23, 6:36 pm, Luis Zarrabeitia ky...@uh.cu wrote:
Makes *no* sense? There's *no* good reason *at all* for the original
author to hide or protect internals?
My bad, sorry.
It makes sense... if the original author is an egotist who believes he must
control how I use that library.
If
On Wed, 21 Jan 2009 01:02:37 -0800, Aaron Brady wrote:
class Parrot:
... _private = 'spam'
... p = Parrot()
p._private = 'ham' # allowed by default from protection import
lock
lock(p)._private
p._private = 'spam'
Traceback (most recent call last):
File stdin, line 1, in
On Wed, 21 Jan 2009 12:55:42 -0500, Luis Zarrabeitia wrote:
Btw, the correctness of a program (on a turing-complete language) cannot
be statically proven. Ask Turing about it.
The correctness of *all* *arbitrary* programs cannot be proven. That
doesn't mean that no programs can be proven.
Tim Rowe digi...@gmail.com writes:
Programs done in Ada are, by objective measures, more reliable than
those done in C and C++ (the very best released C++ programs are about
as good as the worst released Ada programs), although I've always
wondered how much of that is because of language
Steven D'Aprano a écrit :
On Wed, 21 Jan 2009 12:54:31 +0100, Bruno Desthuilliers wrote:
Russ P. a écrit :
(snip)
In any case, I have suggested that Python should perhaps get a new
keyword, private or priv.
And quite a few people - most of them using Python daily - answered they
didn't wan't
Mark Wooding wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
No it's not. It's *practical*. There are domains where *by law* code
needs to meet all sorts of strict standards to prove safety and
security, and Python *simply cannot meet those standards*.
Paul Rubin a écrit :
Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid writes:
In my limited experience with
Haskell (statically typed but very high level),
dynamic and static were not meant to concern typing here (or at
least not only typing).
I'm not sure what you mean by
Btw, the correctness of a program (on a turing-complete language) cannot be
statically proven. Ask Turing about it.
For the most safety critical of programmes, for which static proof is
required, restrictions are placed on the use of the language that
effectively mean that it is not
On Thu, 22 Jan 2009 10:33:26 +0100, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
On Wed, 21 Jan 2009 12:54:31 +0100, Bruno Desthuilliers wrote:
Russ P. a écrit :
(snip)
In any case, I have suggested that Python should perhaps get a new
keyword, private or priv.
And quite a few
Steven D'Aprano a écrit :
On Thu, 22 Jan 2009 10:33:26 +0100, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
On Wed, 21 Jan 2009 12:54:31 +0100, Bruno Desthuilliers wrote:
Russ P. a écrit :
(snip)
In any case, I have suggested that Python should perhaps get a new
keyword, private or
Paul Rubin http://phr...@nospam.invalid writes:
Also, the application area matters. There is a difference between
programming for one's own enjoyment or to do a personal task, and
writing programs whose reliability or lack of it can affect other
people's lives. I've never done any
On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
On Thu, 22 Jan 2009 10:33:26 +0100, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
On Wed, 21 Jan 2009 12:54:31 +0100, Bruno Desthuilliers wrote:
Russ P. a écrit :
(snip)
In any case, I have
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
But if you have free access to attributes, then *everything* is
interface.
Nope.
How could anyone fail to be convinced by an argument that
Tim Rowe wrote:
Btw, the correctness of a program (on a turing-complete language) cannot be
statically proven. Ask Turing about it.
For the most safety critical of programmes, for which static proof is
required, restrictions are placed on the use of the language that
effectively mean that it
Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid writes:
Paul Rubin a écrit :
I'd say that Python's FP characteristics are an important part of its
expressiveness.
Indeed - but they do not make Python a functional language[1]. Python is
based on objects, not on functions,
On Thursday 22 January 2009 08:32:51 am Steven D'Aprano wrote:
And now I have accidentally broken the spam() method, due to a name clash.
True, that's bad. I wish that were 'fixed'.
Besides, double-underscore names are a PITA to work with:
Isn't that example the point of having self.__private
Paul Rubin wrote:
Mark Wooding m...@distorted.org.uk writes:
Some people (let's call them `type A programmers') have decided that
they want to be assisted with writing correct programs...
Other people (`type B programmers') don't like having their (apparently?
possibly?) correct programs
On Thu, Jan 22, 2009 at 8:42 PM, Ricardo Aráoz ricar...@gmail.com wrote:
(...)
What I've seen engineers do when they need extra safety is to put in place
independently developed and operated redundant systems, at least three, and
the system will do whatever two of the independent systems agree
James Mills prolo...@shortcircuit.net.au writes:
Ricardo's point is very well put and Safety Critical systems
that specify requirements, tangible and quantifiable requirements
are what makes a system safe and gives assurance - not the language
or the platform os the os or the environment.
Scott David Daniels scott.dani...@acm.org writes:
Having once been a more type-A, I labored for a couple of years trying
to build a restricted language that provably terminated for work on an
object-oriented database research. I finally gave it up as a bad idea,
because, in practice, we don't
1 - 100 of 437 matches
Mail list logo
