Op 2005-10-07, Diez B. Roggisch schreef [EMAIL PROTECTED]:
Well, that exactly is the point where we make the transition from this
is how things work to pure speculation.
Everything starts with pure speculation. I had no intention of
introducing the big type system here. I just think people who
Paul Rubin http://[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Alex Martelli) writes:
ap.py:4: No global (test) found
ap.py:5: Local variable (ego1d) not used
Helen:/tmp alex$
If you're so typo-prone and averse to unittests that you consider this
kind of issue to be a serious
Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]:
Suppose we have a typesystem which has the type ANY, which would mean
such an object could be any type. You could then have homogenous lists
in the sense that all elements should be of the same declared type and
at the same time mix
Antoon Pardon wrote:
Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]:
Suppose we have a typesystem which has the type ANY, which would mean
such an object could be any type. You could then have homogenous lists
in the sense that all elements should be of the same declared type and
at
Steve Holden [EMAIL PROTECTED] writes:
In other words, you want Python to be strongly-typed, but sometimes
you want to allow a reference to be to any object whatsoever. In which
case you can't possibly do any sensible type-checking on it, so this
new Python+ or whatever you want to call it
Paul Rubin wrote:
Brian Quinlan [EMAIL PROTECTED] writes:
Without a clear idea of the nature of the proposal, it is impossible
to assess it's costs and benefits. So could a proponent of optional
declarations please provide a more clear proposal?
There is no proposal on the table. There's
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
In other words, you want Python to be strongly-typed, but sometimes
you want to allow a reference to be to any object whatsoever. In which
case you can't possibly do any sensible type-checking on it, so this
new Python+ or whatever you
Brian Quinlan [EMAIL PROTECTED] writes:
There is no proposal on the table. There's a discussion of how this
stuff can work, and whether it's useful. As for how the compiler
deals with imported modules, see for example Common Lisp or Haskell or
ML--how do they do it?
Except that you
Why do you call this a JAVA Object or C void*? Why don't you call
it a PYTHON object. It is this kind of reaction that IMO tells most
opponents can't think outside the typesystems they have already
seen and project the problems with those type systems on what
would happen with python should
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
In other words, you want Python to be strongly-typed, but sometimes
you want to allow a reference to be to any object whatsoever. In which
case you can't possibly do any sensible type-checking on it, so this
new Python+ or whatever you
Paul Rubin wrote:
Let's see if I understand what you're saying:
C and Java: you get useful type checking except when you declare
a reference as type ANY. This is a shortcoming compared to:
Python: where you get no useful type checking at all.
That is not very convincing
Ben Sizer [EMAIL PROTECTED] wrote:
It's started to get very misleading - Python gives you plenty of
type-checking, as we all know, just not at compile-time.
There's more to it than just that. Python's type checking is not just not
done at compile time, it's done as late in run time as
Op 2005-10-07, Steve Holden schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]:
Suppose we have a typesystem which has the type ANY, which would mean
such an object could be any type. You could then have homogenous lists
in the sense that
On Fri, 07 Oct 2005 06:01:00 -0400, Roy Smith wrote:
There's more to it than just that. Python's type checking is not just not
done at compile time, it's done as late in run time as possible. One might
call it just-in-time type checking.
Well there you go then. Instead of pulling our hair
Roy Smith a écrit :
There's more to it than just that. Python's type checking is not just not
done at compile time, it's done as late in run time as possible. One might
call it just-in-time type checking.
It's more of a Nearly too late type checking I would say. Not that I
complain but it
Christophe wrote:
It's more of a Nearly too late type checking I would say. Not that I
complain but it would be great if there were also some automatic type
checking to catch a few errors as soon as possible.
use assert as the soonest possible point. implementing type gates is
trivial, if
Op 2005-10-07, Diez B. Roggisch schreef [EMAIL PROTECTED]:
Why do you call this a JAVA Object or C void*? Why don't you call
it a PYTHON object. It is this kind of reaction that IMO tells most
opponents can't think outside the typesystems they have already
seen and project the problems with
Fredrik Lundh a écrit :
Christophe wrote:
It's more of a Nearly too late type checking I would say. Not that I
complain but it would be great if there were also some automatic type
checking to catch a few errors as soon as possible.
use assert as the soonest possible point. implementing
Fredrik Lundh [EMAIL PROTECTED] writes:
use assert as the soonest possible point. implementing type gates is
trivial, if you think you need them.
What this is about (to me at least) is the edit-debug cycle. Let's
say I write some Python code, using assert to validate datatypes.
Maybe I've
Antoon Pardon wrote:
Then argue against my ideas, and not your makings of it.
If I just use 'ANY' and you fill that in with C void* like
implementation and argue against that, then you are arguing
against your own ghosts, but not against what I have in mind.
Well, you didn't tell us what
It is not about falling back on generic declarartion, it is about
how such object will be treated. Diez seems to think that
strongly-typed language can only deal with generic declarations
by using something that allows circumventing the type system.
No, I don't - now it's you who makes
Paul Rubin http://[EMAIL PROTECTED] wrote:
What this is about (to me at least) is the edit-debug cycle. Let's
say I write some Python code, using assert to validate datatypes.
Maybe I've made 4 errors. I then write a test function and run it.
Boom, the first assert fails. I fix the first
Now some of the Python-is-perfect crowd seems to suffer from a Blub
paradox (http://c2.com/cgi/wiki?BlubParadox). They see annoying,
static typed languages like C and Java, and they see pleasant,
dynamically typed languages like Python, and conclude that static
types = annoying, when in fact
Diez B. Roggisch [EMAIL PROTECTED] writes:
- FPs share their own set of problems - try writing a server. The
have inherent troubles with event-driven programs.
Erlang?
Still, FP is cool. But python too. And just attaching some
type-inference to python won't work.
Yeah, I've figured
Paul Rubin wrote:
Diez B. Roggisch [EMAIL PROTECTED] writes:
- FPs share their own set of problems - try writing a server. The
have inherent troubles with event-driven programs.
Erlang?
Guess what, worked with that, too :) And let me assure you - it does
have pretty much runtime type
Christophe wrote:
Fredrik Lundh a écrit :
Christophe wrote:
It's more of a Nearly too late type checking I would say. Not that I
complain but it would be great if there were also some automatic type
checking to catch a few errors as soon as possible.
use assert as the soonest possible
Op 2005-10-07, Diez B. Roggisch schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Then argue against my ideas, and not your makings of it.
If I just use 'ANY' and you fill that in with C void* like
implementation and argue against that, then you are arguing
against your own ghosts, but not
Diez B. Roggisch [EMAIL PROTECTED] writes:
Erlang?
Guess what, worked with that, too :) And let me assure you - it does
have pretty much runtime type error issues. It's interpreted.
Yes, it makes no attempt at being statically typed. It's like Python
that way, AFAIK.
Easy cases are
You just said let's
introduce something like any. I showed you existing implementations of
such a concept that have problems.
But as far as I can see that is a problem of the implementation
not necessarily of the concept.
Without any concept, sure there can't be problems with that
Christophe wrote:
I mean, why not ? Why does the compiler let me do that when you know
perfectly that that code is incorrect :
def f():
return a + 5
probably because the following set is rather small:
bugs caused by invalid operations involving only literals, that are not
Mike Meyer [EMAIL PROTECTED] writes:
When you want local variable in lisp you do :
(let ((a 3)) (+ a 1))
Excep that's not a decleration, that's a binding. That's identical to
the Python fragment:
a = 3
return a + 1
except for the creation of the new scope. Not a
How about Lisp? It seems to do some good there, without getting in
the way.
I don't know much about lisp. But the thing is that one of the most
important data structures in python (and basically the only one in
LISP), lists, are a big problem to type-checking if they aren't
homogenous. So I
Antoon Pardon [EMAIL PROTECTED] wrote:
...
egold = 0:
while egold 10:
if test():
ego1d = egold + 1
Oh come on. That is a completely contrived example,
No it is not. You may not have had any use for this
kind of code, but unfamiliary with certain types
of
[EMAIL PROTECTED] (Alex Martelli) writes:
ap.py:4: No global (test) found
ap.py:5: Local variable (ego1d) not used
Helen:/tmp alex$
If you're so typo-prone and averse to unittests that you consider this
kind of issue to be a serious problem, just use pychecker and get
informed about any
On 5 Oct 2005 09:27:04 GMT, Duncan Booth [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
It also is one possibility to implement writable closures.
One could for instace have a 'declare' have the effect that
if on a more inner scope such a declared variable is (re)bound it
will rebind the
Op 2005-10-06, Bengt Richter schreef [EMAIL PROTECTED]:
On 5 Oct 2005 09:27:04 GMT, Duncan Booth [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
It also is one possibility to implement writable closures.
One could for instace have a 'declare' have the effect that
if on a more inner scope
Op 2005-10-05, Brian Quinlan schreef [EMAIL PROTECTED]:
Paul Rubin wrote:
Brian Quinlan [EMAIL PROTECTED] writes:
Have those of you who think that the lack of required declarations in
Python is a huge weakness given any thought to the impact that adding
them would have on the rest of the
On Wed, 05 Oct 2005 11:10:58 GMT, Ron Adam [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
Op 2005-10-04, Ron Adam schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
And lo, one multi-billion dollar Mars lander starts braking either too
Op 2005-10-05, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
They also relieve a burden from the run-time, since all variables
are declared, the runtime doesn't has to check whether or not
a variable is accesible, it knows it is.
Not in a dynamic language.
Op 2005-10-05, Diez B. Roggisch schreef [EMAIL PROTECTED]:
This is naive. Testing doesn't guarantee anything. If this is what you
think about testing, then testing gives you a false impression of
security. Maybe we should drop testing.
Typechecking is done by a reduced lamda calculus (System
Antoon Pardon wrote:
from xml.dom import *
def do_add(x, y):
return '%s://%s' % (x, y)
def do_something(node):
if node.namespace == XML_NAMESPACE:
return do_add('http://', node.namespace)
elif node.namespace == ...
...
IMO your variable are already
Paul Rubin wrote:
Brian Quinlan [EMAIL PROTECTED] writes:
OK. The Python compiler would check that the name is declared but it
would not check that it is defined before use? So this would be
acceptable:
def foo():
local x
return x
Come on, you are asking silly questions. Any
Duncan Booth [EMAIL PROTECTED] writes:
The value XML_NAMESPACE was imported from xml.dom, but the xml package is
kind of weird. XML_NAMESPACE defined both in xml.dom and in the
_xmlplus.dom package. The _xmlplus package is conditionally imported by the
xml package, and completely replaces
Brian Quinlan [EMAIL PROTECTED] writes:
I'm not trying to be silly. I am trying to get a handle on the
semantics that you are proposing. So we now have two requirements for
the new declaration syntax (please let me know if I'm wrong):
o the variable must be declared
o the variable must be
Sure, But allow me this silly analogy.
Going out on a full test-drive will also reveal your tires are flat.
So if you one has to be dropped, a full test drive or a tire check
it would certainly be the tired check. But IMO the tire check
is still usefull.
But you could write it as test -
Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]:
Sure, But allow me this silly analogy.
Going out on a full test-drive will also reveal your tires are flat.
So if you one has to be dropped, a full test drive or a tire check
it would certainly be the tired check. But IMO the tire
Paul Rubin wrote:
Right now, the compiler DOES NOT examine the contents of the other
modules. All it does is generate an IMPORT_NAME instruction which is
evaluation during runtime.
In that case the other module gets compiled when the IMPORT_NAME
instruction is executed.
If
I can't help but feel that a lot of people have specific typechecking
systems in mind and then conclude that the limits of such a symtem
are inherent in typechecking itself.
I've been writing a type-checker for my diploma thesis for a functionnal
programmming language. And it _is_ limited.
Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]:
I can't help but feel that a lot of people have specific typechecking
systems in mind and then conclude that the limits of such a symtem
are inherent in typechecking itself.
I've been writing a type-checker for my diploma thesis for
Suppose we have a typesystem which has the type ANY, which would mean
such an object could be any type. You could then have homogenous lists
in the sense that all elements should be of the same declared type and
at the same time mix all kind of type in a particular list, just
as python does.
Mike Meyer a écrit :
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote:
Declarations also allow easier writable closures. Since the declaration
happens at a certain scope, the run time can
Pierre Barbier de Reuille [EMAIL PROTECTED] writes:
Mike Meyer a écrit :
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote:
Declarations also allow easier writable closures. Since the
Bengt Richter wrote:
On Wed, 05 Oct 2005 11:10:58 GMT, Ron Adam [EMAIL PROTECTED] wrote:
Looking at it from a different direction, how about adding a keyword to
say, from this point on, in this local name space, disallow new
names. Then you can do...
def few(x,y):
a = 'a'
b = 'b'
i
Brian Quinlan [EMAIL PROTECTED] writes:
Without a clear idea of the nature of the proposal, it is impossible
to assess it's costs and benefits. So could a proponent of optional
declarations please provide a more clear proposal?
There is no proposal on the table. There's a discussion of how
Ron Adam wrote:
Is there a way to conditionally decorate? For example if __debug__ is
True, but not if it's False? I think I've asked this question before. (?)
the decorator is a callable, so you can simply do, say
from somewhere import debugdecorator
if not __debug__:
Mike Meyer [EMAIL PROTECTED] writes:
I think we're using different definitions of statically typed
here. A language that is statically typed doesn't *need* type
inferencing - the types are all declared! Type determines the thypes
by inferenceing them from an examination of the program.
I
Paul Rubin http://[EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] writes:
I think we're using different definitions of statically typed
here. A language that is statically typed doesn't *need* type
inferencing - the types are all declared! Type determines the thypes
by inferenceing
Fredrik Lundh wrote:
Ron Adam wrote:
Is there a way to conditionally decorate? For example if __debug__ is
True, but not if it's False? I think I've asked this question before. (?)
the decorator is a callable, so you can simply do, say
from somewhere import debugdecorator
Dans l'article [EMAIL PROTECTED], Mike Meyer a écrit :
Pierre Barbier de Reuille [EMAIL PROTECTED] writes:
Mike Meyer a écrit :
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote:
Ron Adam wrote:
Fredrik Lundh wrote:
Ron Adam wrote:
Is there a way to conditionally decorate? For example if __debug__ is
True, but not if it's False? I think I've asked this question before. (?)
the decorator is a callable, so you can simply do, say
from somewhere import
Barbier de Reuille [EMAIL PROTECTED] writes:
Dans l'article [EMAIL PROTECTED], Mike Meyer a écrit :
Pierre Barbier de Reuille [EMAIL PROTECTED] writes:
Mike Meyer a écrit :
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
On Mon, 03 Oct 2005
On 6 Oct 2005 06:44:41 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
Op 2005-10-06, Bengt Richter schreef [EMAIL PROTECTED]:
On 5 Oct 2005 09:27:04 GMT, Duncan Booth [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
It also is one possibility to implement writable closures.
One could for instace
Op 2005-10-04, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote:
Declarations also allow easier writable closures. Since the declaration
happens at a
Paul Rubin wrote:
Brian Quinlan [EMAIL PROTECTED] writes:
Have those of you who think that the lack of required declarations in
Python is a huge weakness given any thought to the impact that adding
them would have on the rest of the language? I can't imagine how any
language with required
Op 2005-10-04, Ron Adam schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
And lo, one multi-billion dollar Mars lander starts braking either too
early or too late. Result: a new crater on Mars, named after the NASA
employee who thought the
[EMAIL PROTECTED] wrote:
Some people just don't get the simple fact that declarations are
essentially kind of unit test you get for free (almost), and the compiler
is a testing framework for them.
It seems you've missed the entire point of using a dynamically
typed language. It's not just
Duncan Booth [EMAIL PROTECTED] writes:
If you think variable declarations should be required,
I don't think they should be required. I think there should optional
declarations along with a compiler flag that checks for them if the
user asks for it, like Perl has.
then you presumably want that
Magnus Lycka [EMAIL PROTECTED] writes:
It seems you've missed the entire point of using a dynamically
typed language. It's not just about saving typing time and making
your methods take up fewer lines of code. It's about writing generic
code. Just look at C++ with all that mess with complex
Op 2005-10-05, Duncan Booth schreef [EMAIL PROTECTED]:
Paul Rubin wrote:
Brian Quinlan [EMAIL PROTECTED] writes:
Have those of you who think that the lack of required declarations in
Python is a huge weakness given any thought to the impact that adding
them would have on the rest of the
James A. Donald wrote:
What can one do to swiftly detect this type of bug?
Unit tests. In my experience the edit - test cycle in
Python is typically roughly as fast as the edit - compile
cycle in e.g. C++, and much faster than the full edit -
compile - link - test cycle in C++.
You do use
Antoon Pardon wrote:
It also is one possibility to implement writable closures.
One could for instace have a 'declare' have the effect that
if on a more inner scope such a declared variable is (re)bound it
will rebind the declared variable instead of binding a local name.
That is one
Brian Quinlan [EMAIL PROTECTED] writes:
Python already has a global declaration;
Which is evaluated at runtime, does not require that the actual global
variable be pre-existing, and does not create the global variable if
not actually assigned. I think that is pretty different than your
Paul Rubin wrote:
Brian Quinlan [EMAIL PROTECTED] writes:
Have those of you who think that the lack of required declarations in
Python is a huge weakness given any thought to the impact that adding
them would have on the rest of the language? I can't imagine how any
language with required
Brian Quinlan wrote:
Paul Rubin wrote:
Brian Quinlan [EMAIL PROTECTED] writes:
Have those of you who think that the lack of required declarations in
Python is a huge weakness given any thought to the impact that adding
them would have on the rest of the language? I can't imagine how any
Op 2005-10-05, Duncan Booth schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
It also is one possibility to implement writable closures.
One could for instace have a 'declare' have the effect that
if on a more inner scope such a declared variable is (re)bound it
will rebind the declared
Antoon Pardon wrote:
Op 2005-10-04, Ron Adam schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
And lo, one multi-billion dollar Mars lander starts braking either too
early or too late. Result: a new crater on Mars, named after the NASA
Antoon Pardon wrote:
As far as I understand people don't like global very much so I don't
expect that a second keyword with the same kind of behaviour has
any chance.
That's why the behaviour I suggest is different than the current behaviour
of global. Arguments against global (it is the only
Paul Rubin wrote:
Which is evaluated at runtime, does not require that the actual global
variable be pre-existing, and does not create the global variable if
not actually assigned. I think that is pretty different than your
proposal semantics.
Different how?
Aren't you looking for some of
Mike Meyer wrote:
(snip)
Antoon, at a guess I'd say that Python is the first time you've
encountered a dynamnic language. Being horrified at not having
variable declarations,
Mike, being horrified by the (perceived as...) lack of variable
declaration was the OP's reaction, not Antoon's.
--
Brian Quinlan [EMAIL PROTECTED] writes:
Aren't you looking for some of compile-time checking that ensures that
only declared variables are actually used? If so, how does global help?
You'd have to declare any variable global, or declare it local, or it
could be a function name (defined with
Paul Rubin wrote:
You'd have to declare any variable global, or declare it local, or it
could be a function name (defined with def) or a function arg (in the
function scope), or maybe you could also declare things like loop
indices. If it wasn't one of the above, the compiler would flag it.
Paul Rubin wrote:
So where are the complex templates and dangerous void pointers in ML?
You're right about that of course. There aren't any templates or
pointers in COBOL either as far as I know, and COBOL has been used
for lots of real world code (which ML hasn't).
I don't know what your point
Antoon Pardon [EMAIL PROTECTED] writes:
They also relieve a burden from the run-time, since all variables
are declared, the runtime doesn't has to check whether or not
a variable is accesible, it knows it is.
Not in a dynamic language. Python lets you delete variables at run
time, so the only
This is naive. Testing doesn't guarantee anything. If this is what you
think about testing, then testing gives you a false impression of
security. Maybe we should drop testing.
Typechecking is done by a reduced lamda calculus (System F, which is
ML-Style), whereas testing has the full power
Brian Quinlan [EMAIL PROTECTED] writes:
OK. The Python compiler would check that the name is declared but it
would not check that it is defined before use? So this would be
acceptable:
def foo():
local x
return x
Come on, you are asking silly questions. Any reasonable C
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote:
Op 2005-10-03, Duncan Booth schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
A language where variable have to be declared before use, would allow
to give all misspelled
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
On Mon, 03 Oct 2005 06:59:04 +, Antoon Pardon wrote:
Well I'm a bit getting sick of those references to standard idioms.
There are moments those standard idioms don't work, while the
gist of the OP's remark still stands like:
Mike Meyer wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Declared variables have considerable labour costs, and only marginal
gains. Since the steps you take to protect against other errors will also
protect against mistyping variables, declarations of variables is of
little practical
bruno modulix [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
James A. Donald wrote:
I am contemplating getting into Python, which is used by engineers I
admire - google and Bram Cohen, but was horrified
horrified ???
Ok, so I'll give you more reasons to be 'horrified':
- no
Op 2005-10-04, Steven D'Aprano schreef [EMAIL PROTECTED]:
Mike Meyer wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Declared variables have considerable labour costs, and only marginal
gains. Since the steps you take to protect against other errors will also
protect against mistyping
Antoon Pardon [EMAIL PROTECTED] writes:
Or you just code without declaring, intending to go
back and do it later, and invariably forget.
What's the problem, the compilor will allert you
to your forgetfullness and you can then correct
them all at once.
Thiat in fact happens to me all the
Paul Rubin wrote:
Antoon Pardon [EMAIL PROTECTED] writes:
Or you just code without declaring, intending to go
back and do it later, and invariably forget.
What's the problem, the compilor will allert you
to your forgetfullness and you can then correct
them all at once.
Thiat in fact
Op 2005-10-04, Steve Holden schreef [EMAIL PROTECTED]:
Paul Rubin wrote:
Antoon Pardon [EMAIL PROTECTED] writes:
Or you just code without declaring, intending to go
back and do it later, and invariably forget.
What's the problem, the compilor will allert you
to your forgetfullness and you
What can one do to swiftly detect this type of bug?
While I can only speak from my own experience I can't remember a
single instance where this type of bug caused any kind of serious
problem. IMHO these are very trivial errors, that get caught
immediately and I would not even qualify them as
Have those of you who think that the lack of required declarations in
Python is a huge weakness given any thought to the impact that adding
them would have on the rest of the language? I can't imagine how any
language with required declarations could even remotely resemble Python.
And if you
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote:
Declarations also allow easier writable closures. Since the declaration
happens at a certain scope, the run time can easily find the
Steven D'Aprano [EMAIL PROTECTED] writes:
My gut reaction is that it's a wash. The time taken to declare
variables in well-written code in a well-designed language - meaning
the declarations and use will be close together - isn't all that
great, but neither are the savings.
You've gone from
In article [EMAIL PROTECTED],
Steve Holden [EMAIL PROTECTED] wrote:
Paul Rubin wrote:
Antoon Pardon [EMAIL PROTECTED] writes:
Or you just code without declaring, intending to go
back and do it later, and invariably forget.
What's the problem, the compilor will allert you
to your
On Tue, 04 Oct 2005 10:18:24 -0700, Donn Cave [EMAIL PROTECTED] wrote:
[...]
In the functional language approach I'm familiar with, you
introduce a variable into a scope with a bind -
let a = expr in
... do something with a
and initialization is part of the package. Type is usually
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Bengt Richter) wrote:
On Tue, 04 Oct 2005 10:18:24 -0700, Donn Cave [EMAIL PROTECTED] wrote:
[...]
In the functional language approach I'm familiar with, you
introduce a variable into a scope with a bind -
let a = expr in
... do
1 - 100 of 134 matches
Mail list logo
