Re: Python vs C for a mail server
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 dozen years or so... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 (more than C++, I guess), and isn't all that much younger than C++ (around 15 and 23 years old respectively). In my experience the overhead of explicitly deleting objects in C/C++ is not the big burden that some argue here is the biggest reason to use Python instead of C++. Should we be entirely surprised that from somebody from a engineering / numerical analysis background has that experience? Fortran 77 didn't even *have* a standard way to do dynamic memory allocation, did it? I certainly do think garbage collection is useful in that context, though... John -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 Python language. Yeah, despite being a fan of test-first, I don't write tests for tests either. That has been true when I've been testing numerical code written in both C and Python, for example. If I were writing any sort of test infrastructure code, however tiny, I would write tests for that code, regardless of the language. For those reasons, I don't see writing tests as compensating for shortcomings of Python. This discussion reminds me of statistics books that claimed that, just as a measurement without an error estimate was meaningless, so an error estimate without its own error estimate was also meaningless. By that logic, seems all measurement is meaningless :-) (please everybody note this is meant as a mildly amusing aside, not a point of argument!) It's also a pain to write unit tests, but it's much more rewarding than writing type declarations. Not only does it force you to think through the ramifications of changes, but you also document your intentions through your tests. I do not have time to write unit tests for the Python classes. I have plenty of unit tests to write in Python for the embedded C modules. When I run and hit a problem in Python I just debug it and fix it. That's a lot faster than writing unit tests. As somebody who has worked in both test-first and 'a smattering of tests' styles, I'm quite sure you're right: when you don't have lots of unit tests, writing them slows you down. The benefit to be had comes when making *changes* to code with *good* unit test coverage. We all know people whose 'pragmatism' sometimes operates on, um, a strictly local basis and neglects the impact on a wider scale. I think we usually fall into that trap when we fail to write unit tests. I'm open to the idea that the benefits depend heavily on the sort of code you're writing, though. John -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 write test - write code - run test cycle in TDD with Python is often faster than the plain edit - compile cycle in C++. More extensive tests take longer, but so does linking of C++ code... Magnus, I see a problem with your argument: On the one hand you say that Python's lack of type declarations can be compensated for by Test Driven Development. But then you say Python has a bigger advantage in situations where requirements are not well defined. Well, when requirements are in flux and being explored during development it is a waste of time to write tests to test against nebulous requirements. TDD and poor requirements don't mix very well. Not at all. Agile development methods such as XP, where TDD is fundamental, were developed with the purpose of making to easy to handle changes late in the project. Embrace change as Kent Beck put it. Unit tests aren't really used to verify that a whole program system fulfils all requirements. They're there to verify that a small piece of code works as the programmer intended. To be effective when the requirements change, unit tests need to be fairly isolated, so that one requirements change usually don't affect more than a few tests. For each change in requirements, most existing requirements hold, and hopefully, the vast majority of tests would still run correctly. With a large set of automated unit tests, you can confidently change your code to fulfill the new requirements without breaking any existing functionality without noticing. As for changing argument types: But this is exactly the sort of situation where I find myself getting into trouble in Python. I have to change some type and I forget everywhere I've passed it or returned it. Strange. I very rarely have trouble with this. What happens when you run your tests? Surely things break in the cases where the type change cause trouble, and you get tracebacks that tell you exactly what and where you need to change things. The only difference compared to the compiler, is that it won't force you to change things in places where things still work as intended even though a type was changed. 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 effort required to get started is probably bigger there though. (I don't really know, it was all set up for me at work.) In C++ if I make changes the compiler is going to keep complaining and pointing out type clashes I've introduced due to changing a variable's type. Granted, it is a pain to change type declarations. But visiting those places often makes me think thru the ramifications of changes. It's also a pain to write unit tests, but it's much more rewarding than writing type declarations. Not only does it force you to think through the ramifications of changes, but you also document your intentions through your tests. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 effort required to get started is probably bigger there though. (I don't really know, it was all set up for me at work.) Magnus, 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 Python language. It's also a pain to write unit tests, but it's much more rewarding than writing type declarations. Not only does it force you to think through the ramifications of changes, but you also document your intentions through your tests. I do not have time to write unit tests for the Python classes. I have plenty of unit tests to write in Python for the embedded C modules. When I run and hit a problem in Python I just debug it and fix it. That's a lot faster than writing unit tests. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 when you avoid the compile time type safety in C++. While you might get an exception in Python, which you can handle in your code, or at least get a traceback from, anything can happen in C++, from data corruption to core dumps. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 Python well, embrace it's dynamic nature, don't try to restrain it! It takes some time to let go of the static thinking if one is used to it, but try. Just as lots of programming guidelines (e.g. Parna's Principle and The Law of Demeter) tells us that we should try to know and depend as little as possible on the details in other pieces of code, the duck typing behaviour in Python extends this one step further, to types. Without proper tests, this might cause more problems than it solves, but there is no excuse for not having proper automated tests for software you develop in the 21st century!!! You *don't* write an unmaintainable comment about what return type to expect, you write unit tests that shows you how to use each API that you implement. You run these tests often, fix them as soon as they break, and you encourage their use as documentation which describes through examples how to use you APIs. (Sorry about the imperative tone. It's your life after all, but don't blame Python for not fitting your style of development.) You should do that for statically typed languages as well. Knowing that you got the correct type back gives you no assurance that you got the right value! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 with Python is often faster than the plain edit - compile cycle in C++. More extensive tests take longer, but so does linking of C++ code... There is obviously not one way of development which is optimal in all situations. I've done development for space equipment as well as business software. In my experience, software requirements in e.g. aerospace industry are much more stable. The people responsible for requirements and specifications are engineers, not accountants, and they understand systems development. In typical application development, I'd say that the effort required to get a finished, reasonably reliable product is much smaller with Python than with C++. You might need more tests, but the effort spent on that is easily outweighed by the time saved by coding in Python instead of C++, Java etc. If the requirements are very stable, there is less need for the kind of flexibility and agility that Python provides. One of the big advantages with the dynamic typing in Python is that you get less tight coupling. For instance, if you have some kind of layered approach in e.g. C++, and a number of parameters are passed from one layer to the next in several steps, changing the type of one parameter will cause changes everywhere in the communication chain. In Python on the other hand, it's typically only in the end-points that type changes will have an impact. In many development projects, the appropriate requirements aren't clear from the outset of the project. The problem in the project is not to implement a number of well defined protocols in an optimal way, but to provide a solution that will support the business in an efficient way. Initially, the problem domain experts and the software developers are probably far away from each other in their view of the system, and while the customer knows the business purpose of the system, it's not at all clear how this will be achieved. With tools and methods that are rigid and don't support a flexible and experimental approach, discovering problems with requirements or analysis in the middle of the project, might lead to costly and disruptive rewrites or that the project sticks with a clearly bad solution to avoid the risks that a rewrite leads to in terms of cost, time and reliability. Sure, big requirements changes late in a software project will hamper the development whatever tools you use, but how much these changes costs can probably vary tenfold depending on tools and methods. With Python and an agile approach, a late change is usually much cheaper, so it's not as unreasonable to make this late change that makes the product much better. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 to change every single calling function to be aware of this new db object. And not just how the callers store the returned object, but also how they use that object. That's a LOT of work, for really no gain. Part of the problem is that both standard Python and C++ lacks the concept of defining an interface. Whether we deal with C++ or Python, we need to understand what we can do with a return value, or what kind of interface a parameter we send to a function needs to provide. In Python, this is implicit. The compiler doesn't force us to do the right thing, and a programmer can make a mess by doing it wrong. 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. I don't have enough experience with languages that provide interfaces, such as Java, to understand how useful they are, but it's my impression that they are too cumbersome to use fully. As far as I understand, most Java APIs use types more than interfaces for parameters and return values. (I browsed the Java API docs at java.sun.com, and as far as I see, it seems the APIs always require parameters of distinct classes or types, and return values of particular types or classes.) I know that there have been attempts to provide interfaces in Python, and it seems Zope Interfaces are getting a decent following, but I don't think anyting like that will ever take the place that type declarations of all function and class declarations have in e.g. C++. It's too difficult to make interfaces so convenient and flexible that they could be used generally in Python without taking away a lot of power. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 think the real difference between Python and C++ code in this respect is rather how easy it is to adapt the code to a change in requirements. How many lines of code of C++ or Python needs to be changed when you get a particular change request. There are some cases where the Python programmer will simply smile and say, that already works (well, he should probably write a test case and run that first), where the C++ programmer gets to do a lot of changes to his code. Usually, the difference is probably smaller than that, but the Python coder is probably less nervous about change requests (provided that he has proper automated tests)... There is probably more logical duplication in the C++ code, with different code snippets handling different cases where one set of Python code works with several differnt types. Changes in the semantics of these functions lead to changes in one place for the Python coder, and several changes for the C++ coder, which means a risk that a fix is partially implemented, and works in some cases but fails in others. 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 not so much scaffolding all over the place obfuscating the true intention of the code. I'm sure this depends a lot on what people are used to. I had to provide source code for inspection for a job interview, and the reviewers (who write both C++ and Python) said that they felt that my code was more difficult to understand than the other code samples (which were in C++ or Java). (I still got a job though.) This might be because I'm a crappy programmer, or because the other people typically handed in some university project they had been fully in charge of and written for the purpose of examination, while my code had been changed over a few years based on the whim of a fairly non-technical customer, and only ever read by me. It might be because my code dealt with a more complex problem, or at least something that was difficult for the reviewers to grasp. It could also be because the reviewers were more used to C++. They said that they felt that the lack of .h-files made it difficult for them to get an overview of the code, but it didn't seem that they used anything like pydoc to get a picture of the API. In other words, your milage might vary, and the choice of programming language is just one among many factors that influence how easy it is to read code. Having said that, I agree: It's typically easier to get into someone else's Python code. Particularly when so-called C++ code is really C with lots of globals, no classes and 63 pages of functions (many of which are several pages long, the longest being 13 pages) which often modify the global variables. (Yes, I have such a nice thing on my table now. Happily, I don't have to maintain it. I'm writing a Python program that partially does the same thing, but I doubt this program will help me understand the problems involved, or help me find optimal solutions...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 code - run test cycle in TDD with Python is often faster than the plain edit - compile cycle in C++. More extensive tests take longer, but so does linking of C++ code... Magnus, I see a problem with your argument: On the one hand you say that Python's lack of type declarations can be compensated for by Test Driven Development. But then you say Python has a bigger advantage in situations where requirements are not well defined. Well, when requirements are in flux and being explored during development it is a waste of time to write tests to test against nebulous requirements. TDD and poor requirements don't mix very well. As for changing argument types: But this is exactly the sort of situation where I find myself getting into trouble in Python. I have to change some type and I forget everywhere I've passed it or returned it. In C++ if I make changes the compiler is going to keep complaining and pointing out type clashes I've introduced due to changing a variable's type. Granted, it is a pain to change type declarations. But visiting those places often makes me think thru the ramifications of changes. Also, I've been on projects where the whole purpose of my code has been to test equations and control laws (this was for space probes to places like Eros and Saturn btw). We were certainly doing test driven development in one sense. But the assumption the systems engineers wanted to make was that the algorithms were written correctly in code and that if the system didn't behave correctly then the problem was in the algorithms, not in the code. We therefore were not in a position to do test drive development on the code itself. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 a severe fashion in C++ is to break out of class hierarchies (noting that downcasting is achievable in a slightly safer fashion). Ideally, one would design class hierarchies in such a way that such break-outs are avoided, but this can involve a lot of argument/discussion about design/architecture that is mostly unnecessary with Python. I don't have enough experience with languages that provide interfaces, such as Java, to understand how useful they are, but it's my impression that they are too cumbersome to use fully. My experience is the opposite: if one follows the recommended practices with Java, the flavour of object-orientation employed is more interface-oriented than anything else. Ages ago, there was a trend towards describing class relationships using conformance rather than inheritance; that there's still an incentive to rely more on inheritance in Python-based systems has a lot to do with Python's arguably better support for inheritance than Java, that doing away with multiple inheritance in Java forced people to look at other ways to model their information, and that conformance is typically dynamic and implicit in Python anyway. As far as I understand, most Java APIs use types more than interfaces for parameters and return values. (I browsed the Java API docs at java.sun.com, and as far as I see, it seems the APIs always require parameters of distinct classes or types, and return values of particular types or classes.) I can't comment on most Java APIs, but if you look at established packages like java.io and java.util, both are heavy on interface usage. I know that there have been attempts to provide interfaces in Python, and it seems Zope Interfaces are getting a decent following, but I don't think anyting like that will ever take the place that type declarations of all function and class declarations have in e.g. C++. It's too difficult to make interfaces so convenient and flexible that they could be used generally in Python without taking away a lot of power. Generally, interfaces provide a fairly convenient means of expressing the capabilities of objects whilst providing information that can be useful, in conjunction with a suitably designed runtime environment, in the generation of fairly well-optimised code. In a sense, what you say about taking away a lot of power is highly appropriate: by imposing an interface system on Python, it's quite likely that one could gain performance and a certain measure of predictability whilst losing certain dynamic aspects of the language. I personally wonder whether it's worth speculatively imposing such prescriptive measures whose burden is on the programmer and where the programmer is likely to spend a lot of time trying to work around them. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 achieve. My own experience with Python and C++ is that C++ could be improved to gain it at least some of Python's advantages. After programming in Python for a while and then switching back to C++ my reaction is that C++ needs some features added to its syntax and to its RTL to make it easier to do some of the things that are much easier to do in Python. Also, a lot of C++'s flaws flow from the fact that it is old and grew in lots of increments. In my experience the overhead of explicitly deleting objects in C/C++ is not the big burden that some argue here is the biggest reason to use Python instead of C++. I find Python easier to use more for how it implements lists, dictionaries, standard libs for things like sockets, and other areas which require more work and less portability in C++. C++ needs a new standard toolbox and some new keywords to make loops and other things easier to do. Donn Cave wrote: 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 PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 wasn't really the concepts, but more about two actual languages, so in that respect my point was a little off base - it's only germane to the little religious war that usually comes along at this point. The endlessly rehashed arguments in that context should be about whether you can test everything, whether types convey semantics, etc. Let us forget about whether explicit typing is too much overhead, since it isn't required in principle. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 kind of disingenuous to me to make this argument, frankly. My impression when I compare Python with e.g. Java is this: Java is designed to make to difficult to do the wrong thing. Python is designed to make it easy to do the right thing. That seems to depend on which part of the community you are talking to. Some do argue that some features shouldn't be included in the language because the risk of bugs by those who don't understand how to use it properly, is too high. That even seems to be the way the BDFL feels about things. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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
add a little comment here to clarify -- and in that little comment,
adding the information about type, if at all relevant, is an obvious
task.
Yes, one can use such simple types that the types do not tell you that
much. They do tell you something though. The arg and return types are
not list structures for example. They aren't floats either.
However, C/C++ at least provide a way to make types tell you far more.
For example, one could declare enum types:
typedef enum MyArgType
{
// a bunch of enum const names here
} MyArgType;
typedef enum MyResultType
// another bunch of enum const names
} MyResultType;
Then your example above becomes
MyResultType zappolop(MyArgType frep) { ...
and that's a lot more insightful.
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. If I change what type I return and
forget to change the comment then the code isn't correctly documented
anymore. I've done recently and found out with a runtime error while
testing the Python. In C++ if I'd changed the return type the compiler
would have told me if I didn't use it that way somewhere else.
There are a lot of stages at which to reduce the chance of bugs. While
coding an editor can give you more help with code completion if you
have more static typing. At compile time the compiler can tell you
about errors if it knows the types you are using.
I use PyChecker and PyLint and while they are incredibly helpful (and
I'm grateful to their authors just as I am to Python's developers) they
do not tell me as much as Borland's C++ compiler does. I get more
runtime errors with my Python code than with my C++ code.
Still, I find Python useful and better than C++ in some situations.
But I wish it provided better options for allowing me to indicate types
so that more errors could get caught sooner and so that editor code
completion could be smarter.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 errors get caught sooner. They get caught before tests even get written. Plus, tests become just another layer that needs testing. They also become another layer that can get out of synch with the rest of the software. As for casting away type safety: Sure, you can make C/C++ type unsafe. But that's optional. You can use the type safety if you want to. Most peope use the compiler's type checking because it is more effort to cast away type checking than it is to use it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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. Hmm... with that analogy, I would have to say that most people who strongly advocate static typing and compiler tests are really relying solely on their perimeter guards. They seem to think that provides sufficient defense, and forget to finish the fortress walls. That is, they often don't do adequate tests. Those of us who have really strong fortress walls might sometimes be willing to forego the perimeter guard, perhaps unwisely, but at least we know immediately when we're under attack. Plus, tests become just another layer that needs testing. They also become another layer that can get out of synch with the rest of the software. Not if you are doing test-driven development, at least. In that case by definition if you're out of sync, it's the code which is failing the test because the test defines what the code should be doing. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 author must
obviously
add a little comment here to clarify -- and in that little comment,
adding the information about type, if at all relevant, is an obvious
task.
Yes, one can use such simple types that the types do not tell you that
much. They do tell you something though. The arg and return types are
not list structures for example. They aren't floats either.
However, C/C++ at least provide a way to make types tell you far more.
For example, one could declare enum types:
typedef enum MyArgType
{
// a bunch of enum const names here
} MyArgType;
typedef enum MyResultType
// another bunch of enum const names
} MyResultType;
Then your example above becomes
MyResultType zappolop(MyArgType frep) { ...
and that's a lot more insightful.
Except once a type starts to get a little bit complicated, you're not
going to be able to keep it in your head, and you'll have to go back
to the C++ definition of the type anyway when you want to know what it
does. Much like you'd have to go back to the Python source of a class.
(This is of course assuming that you put a comment in your Python code
saying that a certain kind of class is expected. I find it's obvious
about 80% of the time what's expected).
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. If I change what type I return and
forget to change the comment then the code isn't correctly documented
anymore. I've done recently and found out with a runtime error while
testing the Python. In C++ if I'd changed the return type the compiler
would have told me if I didn't use it that way somewhere else.
Yeah, but you can't *just* change the type you're returning, and expect
to be done. You'll also have to change the source code of the function
to actually return something of that type. And you'll have to change
all the places where the function is called, to make sure that the
caller is storing the result in an appropriately typed variable.
Often times in Python, the thing you're returning is useful because of
duck-typing, not because it's actually of a particular class. Maybe in
some piece of code, you're returning a file() object, and all the
callers really care about is the ability to do a read() and write() on
that object.
Maybe later in the lifecycle of your program, you no longer store
things in the filesystem directly, but in a database. You'd have to
change your function such that it no longer returns a file() object,
but some object that instead is connecting to a database. But you still
only need to call read() and write() on it.
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
to change every single calling function to be aware of this new db
object. And not just how the callers store the returned object, but
also how they use that object. That's a LOT of work, for really no
gain.
And that's the ENTIRE point (as I see it) of the Python typing system.
Usually you know what you want to do, and you shouldn't have to fight
to do it.
If you haven't heard the term duck typing before, Wikipedia has a
decent page on it, and a simple Google search will return many more
results.
There are a lot of stages at which to reduce the chance of bugs. While
coding an editor can give you more help with code completion if you
have more static typing. At compile time the compiler can tell you
about errors if it knows the types you are using.
Yeah, but it can only tell you about type errors, and those aren't
really critical. They're the kind of error that takes a second to fix
when found. Yet *how much* time is often spent fighting with a compiler
to make it accept the types you actually want to use?
I use PyChecker and PyLint and while they are incredibly helpful (and
I'm grateful to their authors just as I am to Python's developers) they
do not tell me as much as Borland's C++ compiler does. I get more
runtime errors with my Python code than with my C++ code.
That's to be expected, but the time needed to get to a runtime error is
so much less in Python (especially if you've got good unit/integration
tests). I recommend you bring IPython into your development tools, so
you can easily import small parts of your code and hand test them in
isolation.
Still, I find Python useful and better than C++ in some situations.
But I wish it provided better options
Re: Python vs C for a mail server
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 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. How does type safety tell you anything about the current usage of your program? Quite a bit; of course, it's doesn't cover everything and clearly testing the semantics is still needed, but a lot of what code is used in what way is described by the type system. And I admit that I'm used to use the type system as documentation of what's going on. And unit tests *might* not tell about the current usage, but integration tests certainly do. Of course tests will cover a lot what static typing does and more. I'm just claiming that they can support each other. I don't think I've ever seen anyone advocating calling a function like getattr(obj foo + bar)(). You can do some very powerful things with getattr, thanks to Python's dynamic nature, but I don't think anyone is recommending calling a function like that. A lot of people got me wrong on that, please see Paul's postings. I really didn't mean that literally. And is that fear based simply on feeling, or on actual experience. The former, that's why I did start this branch of the thread, though I'm already regretting it. 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 not so much scaffolding all over the place obfuscating the true intention of the code. That really depends on who's code you're looking at, as in any language. I can believe there are more C++ obfuscaters out there than ones for Python. I usually have little problems jumping into C++ code of other people but the principle reason for that will be that the people I'm working with have a very clean and expressive coding style. You need to look at doctest: http://docs.python.org/lib/module-doctest.html With doctest, tests are EXACTLY where the code is. I've used doctest with incredibly successful results, in industry. That's indeed a good point for Python. Reference counting by itself is not necessarily sufficient (because of circular references). That's why even Python, with its reference counting based system, has additional capabilities for finding circular references. Whenever I encountered the need for circular references it was because an object, that was in some sense owned by another, needed a pointer back to it's owner. That solved easily with non-owning C-style pointers or weak pointers. If you have an example where this is not sufficient, I'd be *very* keen on hearing it (it may be easy, I don't know). I believe that Alex's official job title at Google is Uber Technical Lead. I'm sure I'll quickly be corrected if that's wrong, but trust me (and everyone else who's spent significant time reading c.l.p.) that Alex Martelli knows what he's talking about. You seem to be thinking that I was ironic. That was certainly not my intention. I was just trying to minimise the amount of flames I'll be getting. A lot of your arguments are the very typical arguments that people levy against Python, when they're first around it. And that's fine, most people go through that. They are taught programming in C++ or Java, and that that *that* is the way you're supposed to program. Then they see that Python does things in different ways, and automatically assume that Python is doing it wrong. I'm sorry to hear this, and whilst I'm certainly lacking experience in Python, I'm not one of those people. All I can say is that if you spend time with Python (and more importantly, read quality, well-established Python code that's already out there), you'll see and understand the Python way of doing things. I will. Jens -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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
Re: Python vs C for a mail server
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 it impossible or at least very difficult to solve problems without doing X. 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. I really think one has to factor in probabilities rather than state comparisons between languages in simpler terms. I also think that the number of ways problem domains differ that affect language choice varry in a lot more ways than, say, whether they have garbage collection built in. Maybe in Google where the coding is primarily for servers the need or lack thereof for explicit control over memory allocation is by itself reason enough to say yes or no to C++. But in other companies solving very different sets of problems (e.g. embedded devices with no operating system or embedded devices with limited RAM or limited CPU or an OS with few languages available) a lot of other factors play in the equation. Alex Martelli wrote: The context is: can any other language be different in this respect? Only by not allowing *any* way to get symbols dynamically, and therefore by substantially reducing the real-world cases in which it's usable. C++ (with dlopen/dlsym and equivalent libraries on other platforms, with dynamic_cast, ...) and Java (with 'reflection' etc) do afford this functionality, albeit in more cumbersome ways than Python. 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 Python and not of C++... Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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
Re: Python vs C for a mail server
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, frankly. My impression when I compare Python with e.g. Java is this: Java is designed to make to difficult to do the wrong thing. Python is designed to make it easy to do the right thing. Designing the language so that potentially problematic constructs are obscure and difficult to do is not considered a virtue in the Python community. If something is difficult to use, people will make more mistakes trying to use it. The right design choices should be actively encouraged by making them easy and accessible, not by making the alternatives hard. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 quality and ease of use of their built-in and third party libraries. I use C++ only for my core data structure (namely a tuned version of a ternary search tree which I use to build full text indices). Those points are all valid. I'm using Python for that reason. And there is another point that there are good Python bindings for the the more important C libraries, but usually no decent C++ wrapper for it. Jens -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 their thinking and experience
indicated by those documents is interesting.
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.
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? This not only about type
safety, but simply name safety.
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)()
?
There is no systematic way to find this call.
In C++, just commend out the definition and the compiler will tell you.
I'm pretty sure I red a PEP about static type safety in Python at some
point. It was even thinking about generics I think.
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
That's true. If the programmer wants to obfuscate his intention, I'm sure
neither Python nor C++ can stop him. The question is how much more work is
to write comprehensible code in one language or the other. I'm a bit
afraid about Python on that matter.
Python provides ways to easy literal documentation. But I'd really like to
have a way of indicating what I'm talking about in a way that's ensured to
be in-sync with the code. Tests are not where the code is. I have
difficulties remembering the type of a lot of symbols, and looking at
testing code to fresh up usage is more difficult that just jumping to the
definition (which the development envirnment is likely to be able to).
[smart pointers and GC]
As you say, smart pointers are not full-blown garbage collection, which is
usually what you want, isn't it? I my (admittedly short) life as a
professional developer I have not yet come accross a situation where
reference counting was not sufficient to model the memory management.
As for the locking: Apart from locking your whatever you need to lock in
your user code, I don't think any special locking is necessary for the
memory management. Smart pointer can increment and decrement their ref
counts atomically as far as I know.
We use boost::shared_ptr in multi-threaded code just out of the box. We
also use a reference counted string implementation in multi threaded code.
At Google, we collectively have rather a lot of experience in these
issues, since we use three general-purpose languages: Python, Java, C++.
I have no doubt that goolge know what they're doing, and if you're working
there then you're likely to know what you're talking about.
I found it especially astonishing what you had to say against the use of
smart pointers.
Jens
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 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 doing? 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? This not only about type safety, but simply name safety. How does type safety tell you anything about the current usage of your program? All static types can tell you is what the input/output types should be, and in no way show any semantic relationship between actual output and the input. Tests can do that. And unit tests *might* not tell about the current usage, but integration tests certainly do. 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)() ? There is no systematic way to find this call. In C++, just commend out the definition and the compiler will tell you. I don't think I've ever seen anyone advocating calling a function like getattr(obj foo + bar)(). You can do some very powerful things with getattr, thanks to Python's dynamic nature, but I don't think anyone is recommending calling a function like that. That's true. If the programmer wants to obfuscate his intention, I'm sure neither Python nor C++ can stop him. The question is how much more work is to write comprehensible code in one language or the other. I'm a bit afraid about Python on that matter. And is that fear based simply on feeling, or on actual experience. 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 not so much scaffolding all over the place obfuscating the true intention of the code. Python provides ways to easy literal documentation. But I'd really like to have a way of indicating what I'm talking about in a way that's ensured to be in-sync with the code. Tests are not where the code is. I have difficulties remembering the type of a lot of symbols, and looking at testing code to fresh up usage is more difficult that just jumping to the definition (which the development envirnment is likely to be able to). You need to look at doctest: http://docs.python.org/lib/module-doctest.html With doctest, tests are EXACTLY where the code is. I've used doctest with incredibly successful results, in industry. [smart pointers and GC] As you say, smart pointers are not full-blown garbage collection, which is usually what you want, isn't it? I my (admittedly short) life as a professional developer I have not yet come accross a situation where reference counting was not sufficient to model the memory management. Reference counting by itself is not necessarily sufficient (because of circular references). That's why even Python, with its reference counting based system, has additional capabilities for finding circular references. At Google, we collectively have rather a lot of experience in these issues, since we use three general-purpose languages: Python, Java, C++. I have no doubt that goolge know what they're doing, and if you're working there then you're likely to know what you're talking about. I believe that Alex's official job title at Google is Uber Technical Lead. I'm sure I'll quickly be corrected if that's wrong, but trust me (and everyone else who's spent significant time reading c.l.p.) that Alex Martelli knows what he's talking about. A lot of your arguments are the very typical arguments that people levy against Python, when they're first around it. And that's fine, most people go through that. They are taught programming in C++ or Java, and that that *that* is the way you're supposed to program. Then they see that Python does things in different ways, and automatically assume that Python is doing it wrong. All I can say is that if you spend time with Python (and more importantly, read quality, well-established Python code that's already out there), you'll see and understand the Python way of doing things. Jay P. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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? This not only about type safety, but simply name safety. 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)() ? There is no systematic way to find this call. While this isn't really a test, as you are really asking about something to do with managing your code base, it is quite possible to write a test which *does* check whether foobar() is called, and even to pinpoint all places from which it is called, if that's really what you want to do. Believing you can't do that suggests you have no real experience with writing tests for code, so it might be best not to argue so strenuously against them. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 this, adding static typing as well still has all the
costs in terms of productivity, but much diminished benefits. So it's
not a question of can't, but of not worth the cost.
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? This not only about type
safety, but simply name safety.
So you are now arguing against any kind of introspection abilities? Do
dlopen and dlsym sap the power you attribute to C++, then?
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)()
?
Encourages? What a silly assertion. Python makes introspection
easier than Java's Reflection, C#'s similar capabilities, and C/C++'s
primitive dlopen/dlsym, but the existence of similar dynamic name
resolution abilities in each of these languages reflects similar
underlying real needs. The functionality is there for those cases in
which it's needed, but it's silly to use it when not needed.
There is no systematic way to find this call.
In C++, just commend out the definition and the compiler will tell you.
You're too optimistic re C++: given its complex rules, the compiler
might well find a different 'foobar' once you comment out that one.
But more: if that function is called via dlopen and dlsym, or similar
functionalities on Windows etc, what can the compiler tell you? It will
tell you nothing, and if you take that as meaning the function is not
called, you're in for a surprise.
So, in C++ like in any of the other languages offering handier
introspection facilities, Python included, you need integration tests
(harder than unit tests) or heuristics based on source analysis (which
won't catch the cases in which the namestrings are constructed
dynamically).
If you're arguing against introspection and dynamic libraries, then
you're not arguing against Python per se, but rather against the whole
grain of modern component-oriented development; since C++, as much as
Java, Python and C#, is most often used for such kind of development,
you should take the debate to a more general forum.
I'm pretty sure I red a PEP about static type safety in Python at some
point. It was even thinking about generics I think.
You're probably thinking of Guido's musings in his blog, never actually
formalized to the point of being a PEP. Of course, he soon realized
that there was nothing static about the typechecking functionality he
was (and is) thinking of introducing in Python 3000 -- it's entirely
dynamic, just like a Java cast or a C++ dynamic_cast. Just like
decorators are just syntax sugar over existing higher-order-function
possibilities, so the typing checks will be syntax sugar over either
existing or propoposed (my PEP246) dynamic adaptation ones.
E.g., you may (in a few years when Python3000 comes) write:
def f(x: Foo): ...
just like you may write (in fewer years if and when PEP246 is accepted):
def f(x):
x = adapt(x, Foo)
...
or perhaps (if PEP246 is rejected) the semantics will be
def f(x):
assert isinstance(x, Foo)
...
Syntax sugar matters: people will be vastly more likely to use
adaptation or typechecking if a nice syntax is provided, just like they
now use HOFs more freely thanks to decorator syntax. But it does not in
any way change the abilities of the language, there's nothing static
about it, and it doesn't really address any of the criticisms such as
yours -- although it may reduce the volume of complaints if it takes
good understanding of the language to realize the functionality is
indeed dynamic, but that's just like saying that Java's goofy:
zap = (Zapper) gup;
is better than C++'s more explicit:
zap = dynamic_castZapper(gup);
because the latter immediately ADMITS it's dynamic, while the former
LOOKS (confusingly;-) more static (even though its semantics isn't).
I prefer truth in advertising: call dynamic what's dynamic, let the
critics criticize (just like they criticize dynamic_cast), and ignore
them (except when you're looking for excuses not to work, just like I'm
doing now since I should be slaving over the 2nd edition of my Nutshell
book;-).
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
That's true. If the programmer wants to obfuscate his intention, I'm sure
Re: Python vs C for a mail server
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 not so much scaffolding all over the place obfuscating the true intention of the code. In the average, you're right. However, if you can rely on ALL the code in question being brilliantly well designed, written by programmers of unbelievably high quality, in full and strict adherence to rigorous coding-style guides (which absolutely forbid the use of LARGE slices of each language) and a reasonably thorough process (mandatory code reviews before anything is committed, mandatory testing, the works), the issue is substantially ameliorated. It does remain true that the amount of Python code needed to implement any given functionality X is smaller than the amount of C++ code needed for the same purpose, of course; the amount of effort to understand a codebase of uniformly high quality being roughly proportional to the size of that codebase, Python will still be advantageous. But by, oh, some small factor (maybe a factor of 2? surely not as high as 5), NOT orders of magnitude. If the design, the programmers, the coding-style, and-or the process are of lesser quality, then you're in trouble either way, and I will concede that the situation degrades faster for C++ -- not only does it offer people more ways to get themselves into trouble, but unless you can count on uniformly high quality the effort is not just linearly proportional to the size of the codebase, it grows much faster than that, so the lack of scaffolding and other factors making Python more expressive do matter more. Still, if I was back to working as a freelance consultant and got hired to fix a problem situation, I wouldn't _start_ by recommending a switch from Java or C++ to Python as the highest-urgency issue: I would first focus on people (both as individual and teams), process, design, and tack language (including style) and other technological issues (including choice of tools, frameworks, libraries, etc) as being, while undoubtedly important, of slightly lesser urgency. Don't get me wrong: using the most appropriate technologies does make a big difference; but it's too easy a temptation to focus on technological silver bullets and assume they can just fix things if ``softer'' but at least as crucial problems are left to keep festering in the background. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 its an extra ordinary need.I just wanted to know which language would be better for implementation and has faster development cycle.I have heard a lot about python and its ease of use.My point is it should be worth a 6 month project and speedy development since he is already proficient in C/C++ socket programming and taking the pain of learning python should be worth the effort. In that case, you'll come closer to having a working mail server in Python. I just hope that it's understood you won't have a mail server which is ready to be used on the Internet for any but very limited applications. -- Jim Segrave ([EMAIL PROTECTED]) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 qmail Dig a bit deeper, and exim might be a candidate for the list. I'm pretty sure O'Reilly has books for sendmail, postfix, and exim; don't know about qmail. O'Reilly does have an Exim book, but it is out of date. It covers the 3.x family, while 4.x has been out for quite a while now. The 4.x family is very different from 3.x, so the book isn't worth a whole lot these days. I'm on my second major mail system deployment built around Exim, and would recommend it to anybody needing a robust, flexible mail server. There is an exim 4 book out, but not via O'Reilly - I gather sales were insufficient to persuade O'Reilly to do an update. As we use Exim heavily, we have both the 3 and 4 books in our NOC, as well as sending almost all new staff to Phil Hazel's excellent courses in Cambridge. -- Jim Segrave ([EMAIL PROTECTED]) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 more predictable, but a search on the standard library for getattr produces a lot of evidence against your assertion. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 mechanism more predictable, but a search on the standard library for getattr produces a lot of evidence against your assertion. if you read Jay's assertion in context, your refutation strikes me as somewhat silly. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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:
obj.foobar()
There is no systematic way to find this call.
In C++, just commend out the definition and the compiler will tell you.
In such a case I normally just grep for foobar. I did so (and I'll do so)
in C/C++, Python, and any other language.
Any programming language allows you to do strange/stupid stuff. But none
of them encourages it. So I can't see your point in any way.
Greets,
Volker
--
Volker Grabsch
---(())---
\frac{\left|\vartheta_0\times\{\ell,\kappa\in\Re\}\right|}{\sqrt
[G]{-\Gamma(\alpha)\cdot\mathcal{B}^{\left[\oint\!c_\hbar\right]}}}
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 mechanism more predictable, but a search on the standard library for getattr produces a lot of evidence against your assertion. 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' argument, and without a default return value (as opposed to throwing a variable in there, or a string plus a variable like you did, or a default retval). 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? Jay P. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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? getattr is very nice, but Acyclic Visitor (aka Dynamic Visitor, essentially the same design pattern) can be implemented in C++, and indeed I believe it was first published by Robert Martin exactly for C++ (at PLOP3 in '97). Cfr http://www.objectmentor.com/resources/articles/visitor for an updated and wider treatment. Python is handier, but, with more effort, you can get similar dynamic effects in C++ (and with an intermediate amount of effort in Java), which is part of what amuses me when I see Java or C++ people making claims that Python's dynamic abilities must cause problems...;-). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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) [...] if you read Jay's assertion in context, your refutation strikes me as somewhat silly. 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 with hard-coded string literals), but where one wants to take some value (eg. a class name) and dispatch to some callable (eg. some visitor handler method) based on that dynamic information, it's a useful technique. Whether widespread usage of such a technique counts as advocacy is a matter I don't find particularly interesting to discuss. Or should I be looking for some other context here? Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 with hard-coded string literals), but where one wants to take some value (eg. a class name) and dispatch to some callable (eg. some visitor handler method) based on that dynamic information, it's a useful technique. Whether widespread usage of such a technique counts as advocacy is a matter I don't find particularly interesting to discuss. Or should I be looking for some other context here? The context is: can any other language be different in this respect? Only by not allowing *any* way to get symbols dynamically, and therefore by substantially reducing the real-world cases in which it's usable. C++ (with dlopen/dlsym and equivalent libraries on other platforms, with dynamic_cast, ...) and Java (with 'reflection' etc) do afford this functionality, albeit in more cumbersome ways than Python. 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 Python and not of C++... Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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' argument, and without a default return value (as opposed to throwing a variable in there, or a string plus a variable like you did, or a default retval). Whether you evaluate the attribute lookup and immediately call the value returned, or whether you instead hold on to that value and invoke it later, is fairly unimportant when considering the behaviour of the program, but such distinctions are important if you wish to acknowledge the extent to which dynamic behaviour permeates running Python programs, especially if you're interested in analysing their behaviour at compile time. 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? Exactly what I gave as an example. The original example was just badly formulated: two string literals glued together doesn't really capture the imagination. I doubt that many compiler writers and IDE makers seeking to improve their respective code generation and tooltip-popping experiences would make the handling of such contrived examples a priority - the possibilities presented by the general underlying mechanisms would be far more worrying. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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, foo + bar)() | | ? | | Encourages? What a silly assertion. Python makes introspection | easier than Java's Reflection, C#'s similar capabilities, and C/C++'s | primitive dlopen/dlsym, but the existence of similar dynamic name | resolution abilities in each of these languages reflects similar | underlying real needs. The functionality is there for those cases in | which it's needed, but it's silly to use it when not needed. Silly indeed, and why would such a thing ever be needed? Yet it does in fact occur in widely used Python software, in an application where it of course wasn't really needed, rather was sort of convenient. This is like the C enthusiast who tells you that any self-respecting programmer won't mind accounting for storage, or the Perl enthusiast who tells you that there's nothing about the language that encourages hard-to-read code. Give people a feature like this, and they will find a need for it, to the detriment of comprehensibility. I'm not saying that we should therefore use C++ !, but let's be realistic about the costs of Python's benefits. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 Python and not of C++... 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, frankly. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 appeared to assume that | it was a weakness of Python and not of C++... 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, frankly. I disagree with you, although my disagreement may be partly due to the fact that lately I've dealt mostly with C++ programmers who know *perfectly well* every subtle nuance of the language, just as much as I do it not even more -- Matt Austern and the like. Last time I was a C++ guru (about 7 years ago) that wasn't the case, but then, I wasn't Uber Technical Lead for Google then;-). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 using sockets(in c++) will improve your understanding of the protocol suite and improve your programming as well. Ravi Teja 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 concern about performance. Abhinav, if that is the case, using sockets is more or less the same from any language. Python as usual will be cleaner than C. You might want to look at Twisted Mail. Use SocketServer module in the standard library to implement the RFC. Other than that it is silly to try to write a Mail Server unless you have some extra ordinary need. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 concern about performance. Abhinav, if that is the case, using sockets is more or less the same from any language. Python as usual will be cleaner than C. You might want to look at Twisted Mail. Use SocketServer module in the standard library to implement the RFC. Other than that it is silly to try to write a Mail Server unless you have some extra ordinary need. Any lecturer assigning write a mail server as a class project is doing his/her students a true dis-service. Mail server RFC compliance is a nightmare to get right, performance issues and mail routeing are both material for at least a full year's university study. A student who tries to make an even vaguely RFC compliant mail server probably won't finish their project, as student who completes such a project might come away with the mistaken belief that they actually have done it correctly. The number of software products which use eail and do so incorrectly is astounding and depressing. There's a reason that the source for sendmail is about 120K lines, exim is nearly 270K lines. Doing it right is _hard_. -- Jim Segrave ([EMAIL PROTECTED]) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 bully students... obviously we cud not complete the project as most of the time was spent on learning the stuff(like TCP, multithreading..) . i don't know how things work out in the west, but i feel the faculty really care about their students in american colleges..in contrast to here (in inida, though things are little different in the IITs) Jim Segrave wrote: 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 concern about performance. Abhinav, if that is the case, using sockets is more or less the same from any language. Python as usual will be cleaner than C. You might want to look at Twisted Mail. Use SocketServer module in the standard library to implement the RFC. Other than that it is silly to try to write a Mail Server unless you have some extra ordinary need. Any lecturer assigning write a mail server as a class project is doing his/her students a true dis-service. Mail server RFC compliance is a nightmare to get right, performance issues and mail routeing are both material for at least a full year's university study. A student who tries to make an even vaguely RFC compliant mail server probably won't finish their project, as student who completes such a project might come away with the mistaken belief that they actually have done it correctly. The number of software products which use eail and do so incorrectly is astounding and depressing. There's a reason that the source for sendmail is about 120K lines, exim is nearly 270K lines. Doing it right is _hard_. -- Jim Segrave ([EMAIL PROTECTED]) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 would be better for implementation and has faster development cycle.I have heard a lot about python and its ease of use.My point is it should be worth a 6 month project and speedy development since he is already proficient in C/C++ socket programming and taking the pain of learning python should be worth the effort. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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++ code where (and if) high performance is required. Now, you should definitely check the requirements for the homework. If the assignment is about being able to decipher an RFC and implement it correctly with a nice software design, then I would definitely opt for Python. Having to squish memory management, string manipulation and character encoding bugs in C/C++ is not fun and not related to high-level design nor RFC support. 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 :). Regards, Nicolas -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 a religious war, it might also bring up some useful points. I'm a bit relucted to swallow the common view of Python being a so- productive language, especially compared to C++. I value C++ productiveness actually much higher than it's performance. To stick to the mailserver example, I'm pretty sure I'd do it in C++. I got very exited about Python when I first saw it, but I've encountered several problems that hindered productivity dramatically. One thing is the lack of static types. The problem is not only that the compiler can't tell you very basic things you're doing wrong but also that code isn't intrinsically documented: def send_mail(mail): ... What can I do with mail? In C++, you're looking up what type it is (presumably by pressing M-x in Emacs on the word before it) and have a look on it's type definition. In Python, it can be quite difficult to tell what you can do with it because the information of what will be passed in can be several layers up. Also there is not even symbol-safety: self.not_defined will never rise a compile-time error. And to address the memory management critisism about C++: Unless you have cyclic structures (you probably won't have in a mail server), just use smart pointers and you don't have to be concerned more about it than you'd have to be in Python. I aggree on C++ libraries being weak on unicode strings though, or even generally weak in the libraries (you have the C libraries, but they're not very type safe or elegant to use). I'm aware that C++ is a horrible monstrosity, an argument whiches weight depends on the OP's friends C++ experience. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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. Talk about dis-services ;-) Sybren -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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
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 their thinking and experience
indicated by those documents is interesting.
Tools such as pychecker, pylint, etc, are also considered by some to be
a useful backstop, but unit-tests are the real answer.
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
add a little comment here to clarify -- and in that little comment,
adding the information about type, if at all relevant, is an obvious
task.
At Google, we collectively have rather a lot of experience in these
issues, since we use three general-purpose languages: Python, Java, C++.
In this mix, the role of C++ is essentially that of allowing the
programmer to have complete control on memory allocation issues: the
only widespread modern language to do that, since all others, including
both Java and Python, have garbage-collection. In the internal style
guide for C++, we forbid the use of so-called ``smart'' pointers which
would basically amount to a hacked-up garbage collection system (which
can never be as solid and thorough as those built into the virtual
machines used in Java or Python -- a GC system that's thread-safe is a
nightmare to build and debug based only on those smart pointers, for
example, and if you start locking and mutexing all over the place for
that purpose you'll soon see performance plummet...): if you want
garbage collection you use a garbage-collected language -- the choice of
C++ for a component implies that you need complete control of memory
issues for that component, therefore choosing C++ and ``too smart for
their own good'' pointers would be mutually contradictory. Our style
guides for all languages also impose using unit-tests, code reviews, and
standard formats for internal documentation, from naming of variables,
functions and classes to structure and form of comments. As a result,
quality and reliability are remarkably consistent and uniform.
We could say that Python is Google's secret weapon, except it's not so
very secret, since, in order to attract and hire Python experts, we do
of course need to let it be known that Python's important to us;-). In
a sense, I guess, we are fortunate that our competitors still appear not
to be fully aware of this -- it gives us a better chance to hire Python
luminaries and maintain a productivity edge;-).
Alex
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 : 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 quality and ease of use of their built-in and third party libraries. I use C++ only for my core data structure (namely a tuned version of a ternary search tree which I use to build full text indices). Regards, Nicolas -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 choose the right algorithms and architecture. which language will be easier? Python is easier to read, and write, and debug, and you will have fewer hard-to-debug memory issues. And you'll have fewer security issues with Python since you don't have to worry about buffer and stack exploits. -- Grant Edwards grante Yow! There's enough money at here to buy 5000 cans of visi.comNoodle-Roni! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 for the list. I'm pretty sure O'Reilly has books for sendmail, postfix, and exim; don't know about qmail. O'Reilly does have an Exim book, but it is out of date. It covers the 3.x family, while 4.x has been out for quite a while now. The 4.x family is very different from 3.x, so the book isn't worth a whole lot these days. I'm on my second major mail system deployment built around Exim, and would recommend it to anybody needing a robust, flexible mail server. -dan -- Well sure the government lies, and the press lies, but in a democracy they aren't the same lies.-Alexis A. Gilliland -- http://mail.python.org/mailman/listinfo/python-list
Python vs C for a mail server
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 the performance issues?In what language are mail servers generally written? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 language.Should i go for C(socket API) or python for this project? If you aren't able to choose the language, what does it matter what we say? Somebody else will choose. What are the advantages of one over the other in implementing this server. C can be faster. which language will be easier? Python is easier to read, and write, and debug, and you will have fewer hard-to-debug memory issues. What are the performance issues? You will spend hundreds of man-hours re-inventing the wheel. In what language are mail servers generally written? Google is your friend. The first four mail servers listed are, in order: sendmail postfix Microsoft Exchange qmail Of the four, source code is available free of charge for three of them. Can you guess which is the odd man out? :-) -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
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 sockets is more or less the same from any language. Python as usual will be cleaner than C. You might want to look at Twisted Mail. Use SocketServer module in the standard library to implement the RFC. Other than that it is silly to try to write a Mail Server unless you have some extra ordinary need. -- http://mail.python.org/mailman/listinfo/python-list
