John J. Lee wrote:
I guess the same is true of Python in some respects: it's still
incrementally changing (more than C++, I guess), and isn't all that
much younger than C++ (around 15 and 23 years old respectively).
But C++ is almost entirely backwards compatible with C, which
adds another
Randall Parker [EMAIL PROTECTED] writes:
[...]
Also, a lot of C++'s flaws flow from the fact that it is old and grew
in lots of increments.
That was a deliberate decision on the part of C++'s designers!-)
I guess the same is true of Python in some respects: it's still
incrementally changing
Randall Parker [EMAIL PROTECTED] writes:
[...]
The code I'm writing in Python is a test executive to test embedded C
code. Then tests get written in Python that the test executive
processes. No, I'm not going to write yet another layer of tests in
order to compensate for shortcomings in the
Randall Parker wrote:
Magnus Lycka wrote:
Randall Parker wrote:
Also, compile time errors get caught sooner. They get caught before
tests even get written.
Not if you do Test Driven Tevelopment. Then you write
the tests before you compile your target code! It's
also my experience that the
Magnus Lycka wrote:
Or...don't you have automated tests? Ouch. If you (like me) feel a
little lazy to write a lot of test scripts, you can use a test tool
such as TextTest, that compares output between test runs, rather than
forcing you to write lots of scripts with plenty of assertions. The
Randall Parker wrote:
C++ provides ways to be type unsafe. Does that mean that C++ is type
unsafe period? Most code in C++ is going to be type safe. Some
programmers will never do dangerous casting. Others will do bad things
with casts.
Sure, but on the other hand, you are really on your own
Randall Parker wrote:
I return objects in Python and in C++. In C++ I can see what their
types are right on the m method signature. In Python I've got to write
a comment on the line above it.
Ouch! Don't do that! As you've noticed, it's not very maintainable.
First of all, if you want to use
Randall Parker wrote:
Also, compile time errors get caught sooner. They get caught before
tests even get written.
Not if you do Test Driven Tevelopment. Then you write
the tests before you compile your target code! It's
also my experience that the write test - write code
- run test cycle in TDD
Jay Parlar wrote:
Well guess what: The *only* code you'll have to change is inside the
function returning the object, none of the callers would have to change.
That's completely different from C++, where you'll have to change not
only the return type and the function, but you'll also have
Jens Theisen wrote:
Jay wrote:
How much time in your C/C++ code is spent casting and trying to
trick the compiler into doing something that it thinks you shouldn't be
doing?
Not much frankly. Though I have no doubt that there is a lot of code that
does, but more so in older C++ code.
I
Magnus Lycka wrote:
Randall Parker wrote:
Also, compile time errors get caught sooner. They get caught before
tests even get written.
Not if you do Test Driven Tevelopment. Then you write
the tests before you compile your target code! It's
also my experience that the write test - write
In article [EMAIL PROTECTED],
...
Granted, it is a pain to change type declarations.
I see it is time for the bi-monthly reminder that C++ is not
the ideal example of strong static typing, unless you just
want to make it look bad. Cf. Hindley-Milner type inference.
Donn Cave, [EMAIL
Magnus Lycka wrote:
In C++ it's the opposite. By demanding a particular type, we restrain
ourself to using a set of values which is much smaller than the logic
calls for, or we can throw away all type checks by e.g. casting to void
pointers.
The main reason for evading the type system in such
Donn,
More generally: One must keep in mind that advantages and disadvantages
of specific implementations of language concepts are not always
indications of flaws in those concepts. Real languages have real flaws
from bad design choices which cause them to fall short of what those
languages could
In article [EMAIL PROTECTED],
Randall Parker [EMAIL PROTECTED] wrote:
...
More generally: One must keep in mind that advantages and disadvantages
of specific implementations of language concepts are not always
indications of flaws in those concepts.
Sure. And of course, the nominal topic
Magnus Lycka [EMAIL PROTECTED] writes:
Sure, but on the other hand, you are really on your own when you
avoid the compile time type safety in C++.
But it's almost impossible to avoid. Does *p point to a valid object,
or to unallocated memory? C++ has no way to tell this at compile
time.
--
Op 2006-01-30, Magnus Lycka schreef [EMAIL PROTECTED]:
Donn Cave wrote:
If we give him credit for having some idea of what he's talking about,
then we could perhaps read his encourages as makes trivially easy.
These two languages are in such different levels with introspection
that it seems
Alex Martelli wrote:
The but without declaration it can't be self-documenting issue is a
red herring. Reading, e.g.:
int zappolop(int frep) { ...
gives me no _useful_ self-documenting information about the role and
meaning of frep, or zappolop's result. The code's author must obviously
Jay,
The point of doing compile time and test time checking is the same
reason militaries use layered defenses: More problems get caught. I've
written tons of software tests and architected a testing system for an
entire aircraft. I've also watched lots of errors get by tests.
Also, compile time
Randall Parker wrote:
The point of doing compile time and test time checking is the same
reason militaries use layered defenses: More problems get caught. I've
written tons of software tests and architected a testing system for an
entire aircraft. I've also watched lots of errors get by tests.
Randall Parker wrote:
Alex Martelli wrote:
The but without declaration it can't be self-documenting issue is a
red herring. Reading, e.g.:
int zappolop(int frep) { ...
gives me no _useful_ self-documenting information about the role and
meaning of frep, or zappolop's result. The code's
Jay wrote:
You can do both, but why? *Especially* in a language like C++, where
thanks to pointers and casting, there really isn't any type safety
anyway. How much time in your C/C++ code is spent casting and trying to
trick the compiler into doing something that it thinks you shouldn't be
Paul wrote:
Or should I be looking for some other context here?
Three people were looking at the wrong one, thanks for putting this right.
I really should not have given my point that briefly.
Jens
--
http://mail.python.org/mailman/listinfo/python-list
But languages that share some weakness typically do not share it
equally. Three languages can have some way to do X (which some might
find undesirable while others find it great) but two of the languages
might make it easy to solve problems without ever doing X while the
third language might make
Volker Grabsch wrote:
Any programming language allows you to do strange/stupid stuff. But none
of them encourages it.
One word: Intercal.
:-)
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
Donn Cave wrote:
If we give him credit for having some idea of what he's talking about,
then we could perhaps read his encourages as makes trivially easy.
These two languages are in such different levels with introspection
that it seems kind of disingenuous to me to make this argument,
Dan Lowe enlightened us with:
I'm on my second major mail system deployment built around Exim, and
would recommend it to anybody needing a robust, flexible mail
server.
Same here. I used Sendmail, QMail, Exim 3 and Exim 4, and out of
those, Exim 4 came out winner.
Sybren
--
The problem with
Nicolas wrote:
http://nicolas.lehuen.com/
My two latest problems with coding in C++ are due to the environments :
libraries using different string types and the whole problem with the
building system. I love the language, but I get a much better leverage
through Python and Java due to the
Alex wrote:
http://www.artima.com/weblogs/viewpost.jsp?thread=4639
http://www.mindview.net/WebLog/log-0025
Since Robert Martin and Bruce Eckel (the authors of the two documents
linked above) are both acknowledged gurus of statically typechecked
languages such as C++, the convergence of
Indeed, especially Eckels article shed some light about testing as an
alternative to static typing. I still can't quite understand why you
can't
do both. Clearly unit tests should be part of any software, not only
Python software.
You can do both, but why? *Especially* in a language like
Jens Theisen wrote:
Test failures, however, don't tell you anything about the current usage of
your program - just about the inteded usage at the point where the test
was writte. Clearly you can't test _anything_? And clearly you can never
be sure that all you collegues did so as well?
Jens Theisen [EMAIL PROTECTED] wrote:
...
Indeed, especially Eckels article shed some light about testing as an
alternative to static typing. I still can't quite understand why you can't
do both. Clearly unit tests should be part of any software, not only
Python software.
Clearly. Given
Jay Parlar [EMAIL PROTECTED] wrote:
...
Because in all of my own industry experience, it's been MUCH easier to
jump into someone else's Python code than someone else's C++ code (and
at my last job, I had to do a lot of both). I find Python to be much
more self-documenting, because there's
In article [EMAIL PROTECTED],
abhinav [EMAIL PROTECTED] wrote:
ya its supposed to be some stupid 6 month project which my friend has
to do.I am just helping him out.he may not be implementing a full
fledged rfc compliance mail server but may support some of the major
functionalities.so basically
In article [EMAIL PROTECTED],
Dan Lowe [EMAIL PROTECTED] wrote:
On Jan 28, 2006, at 8:39 PM, Dennis Lee Bieber wrote:
On Sat, 28 Jan 2006 18:03:56 +1100, Steven D'Aprano said:
Google is your friend. The first four mail servers listed are, in
order:
sendmail
postfix
Microsoft Exchange
Jay Parlar wrote:
I don't think I've ever seen anyone advocating calling a function like
getattr(obj foo + bar)().
From Lib/compiler/visitor.py:
meth = getattr(self.visitor, 'visit' + className, 0)
Later on:
meth(node, *args)
Of course, you can drop the visit prefix and make the mechanism
Paul Boddie wrote:
I don't think I've ever seen anyone advocating calling a function like
getattr(obj foo + bar)().
From Lib/compiler/visitor.py:
meth = getattr(self.visitor, 'visit' + className, 0)
Later on:
meth(node, *args)
Of course, you can drop the visit prefix and make the
Jens Theisen wrote:
What do you do when you want to no if a certain method or function is
actually used from somewhere, say foobar, it a language which allows
(and even encourages) that it could be called by:
getattr(obj, foo + bar)()
No. The recommended way to do it is:
Paul Boddie wrote:
I don't think I've ever seen anyone advocating calling a function like
getattr(obj foo + bar)().
From Lib/compiler/visitor.py:
meth = getattr(self.visitor, 'visit' + className, 0)
Later on:
meth(node, *args)
Of course, you can drop the visit prefix and make the
Jay Parlar [EMAIL PROTECTED] wrote:
...
From Lib/compiler/visitor.py:
meth = getattr(self.visitor, 'visit' + className, 0)
...
I even said you can do some very powerful things with getattr, by
which I meant something exactly like you did. What did you think I
meant by that?
Fredrik Lundh wrote:
Paul Boddie wrote:
[Quoting Jay Parlar...]
I don't think I've ever seen anyone advocating calling a function like
getattr(obj foo + bar)().
From Lib/compiler/visitor.py:
meth = getattr(self.visitor, 'visit' + className, 0)
Later on:
meth(node, *args)
Paul Boddie [EMAIL PROTECTED] wrote:
...
The context was whether you can know before running the program whether
the function you're attempting to call exists, along with where it is
defined. Obviously, it's a struggle to think of cases where one would
do this for the sake of it (especially
Jay Parlar wrote:
[...]
getattr(obj foo + bar)().
[...vs...]
meth = getattr(self.visitor, 'visit' + className, 0)
[...]
I don't think you understood my assertion, then. The example that the
original poster gave was using getattr() with a simple string (foo +
bar) for the 'name'
Quoth [EMAIL PROTECTED] (Alex Martelli):
| Jens Theisen [EMAIL PROTECTED] wrote:
...
| What do you do when you want to no if a certain method or function is
| actually used from somewhere, say foobar, it a language which allows
| (and even encourages) that it could be called by:
|
| getattr(obj,
Quoth [EMAIL PROTECTED] (Alex Martelli):
| ... Therefore,
| if the inability to verify that a function named 'foobar' is in fact
| never called anywhere is a weakness, it's a weakness shared by all of
| these languages. The originator of this thread appeared to assume that
| it was a weakness of
Donn Cave [EMAIL PROTECTED] wrote:
Quoth [EMAIL PROTECTED] (Alex Martelli):
| ... Therefore,
| if the inability to verify that a function named 'foobar' is in fact
| never called anywhere is a weakness, it's a weakness shared by all of
| these languages. The originator of this thread
but i am not able to choose the language.Should i go for C(socket API)
Ravi is right
(using sockets is more or less the same
from any language.)
..try JSP(java server pages), some guys in nit warangal implemented a
mail server
(foa LAN though)for their minor project.
my contention is that
In article [EMAIL PROTECTED],
Ravi Teja [EMAIL PROTECTED] wrote:
Why don't you use an existing mail server?
Probably because that was his homework assignment for a networking
class. Not uncommon to be told to implement a server from the scratch
from the RFC. Although that does not explain his
jim you are probably right.
i have had exp. with this. i had to create a server(multipurpose such
as file sharing, games (pretty simple tho like tic tac toe..) we were
in 6th sem with learning OS and comp. n/w for the first time.
it seems like these jack ass jerks (proffs/instuctors) like to
ya its supposed to be some stupid 6 month project which my friend has
to do.I am just helping him out.he may not be implementing a full
fledged rfc compliance mail server but may support some of the major
functionalities.so basically its an extra ordinary need.I just wanted
to know which language
If your friend is proficient in C/C++ then learning Python should not
be a pain. Quite the contrary, it should be an enlightnement. Being
good in C/C++ AND Python is a killer combination, as you can promptly
and efficiently code big chunks of your application in Python and
interface with C/C++
Nicolas wrote:
If it's just a way to throw a programming challenge at your friend's
face, then you should check whether it's okay to use Python rather than
C/C++, otherwise he could be charged of cheating by using a more
productive language :).
Though this comment of mine is likely to start
Jim Segrave enlightened us with:
Any lecturer assigning write a mail server as a class project is
doing his/her students a true dis-service.
At one time, I got an assignment Write a robust, user friendly SMTP
client. That was just after we learned how to user 'for' loops and
'if' statements.
Jens Theisen [EMAIL PROTECTED] wrote:
...
Please don't be offended, but if anyone could make a point of how Python's
disadvantages in these regards could be alleviated, I'd be very
interested.
http://www.artima.com/weblogs/viewpost.jsp?thread=4639
http://www.mindview.net/WebLog/log-0025
Jens Theisen wrote:
Please don't be offended, but if anyone could make a point of how Python's
disadvantages in these regards could be alleviated, I'd be very
interested.
Jens
Well, I write Java, C++ and Python code, and I have posted a few
thoughts about this on my blog :
On 2006-01-28, Steven D'Aprano [EMAIL PROTECTED] wrote:
I am a novice in python.I have to implement a full fledged mail server
Because that's just what the world needs, yet another mail server.
:)
C can be faster.
And can be is the key. It's easy to write slow programs in C
if you don't
On Jan 28, 2006, at 8:39 PM, Dennis Lee Bieber wrote:
On Sat, 28 Jan 2006 18:03:56 +1100, Steven D'Aprano said:
Google is your friend. The first four mail servers listed are, in
order:
sendmail
postfix
Microsoft Exchange
qmail
Dig a bit deeper, and exim might be a candidate
Hello guys,
I am a novice in python.I have to implement a full fledged mail server
.But i am not able to choose the language.Should i go for C(socket API)
or python for this project? What are the advantages of one over the
other in implementing this server.which language will be easier? What
are
On Fri, 27 Jan 2006 22:43:48 -0800, abhinav wrote:
Hello guys,
I am a novice in python.I have to implement a full fledged mail server
Because that's just what the world needs, yet another mail server.
Why don't you use an existing mail server?
.But i am not able to choose the
Why don't you use an existing mail server?
Probably because that was his homework assignment for a networking
class. Not uncommon to be told to implement a server from the scratch
from the RFC. Although that does not explain his concern about
performance.
Abhinav, if that is the case, using
60 matches
Mail list logo
