quote: Original post by Anonymous Poster
I don''t know how Python''s indentation rules could harm anyone.

I used to rationalise in the same way, but I''ve been bitten a few too many times now. Initially, I remember thinking it was odd, and that it reminded me of Cobol indentation rules. Then I got used to it and rationalised that was that - they weren''t a problem anymore. Eventually, it occurred to me that I was getting problems with indentation, even after using Python for around two years. My conclusion is that it''s not really a case of getting used to it - it''s a genuinely annoying restriction, and it can cause bizarre problems when it bites.

quote:
But the other stuff could be added to it.

Possibly, and maybe it will. I''m skeptical that macros could be particularly good with the syntax of Python. I''m also skeptical of a language which keeps having things bolted-on as an after-thought, lest we end up nailing tentacles to a dog in order to create an octopus. And just to add to my general skepticism, I''m skeptical of an argument that we could add various things to Python to make it more like Lisp, when we can just use Lisp.

quote:
After all it''s still an evolving language. I think a bigger problem is it''s speed though, but I remember you saying that a JIT compiler for Python is on it''s way.

I think it''s available (probably in beta), but I haven''t played with it. Most of the stuff I''ve done with Python has been IO-bound, so I''ve not felt the need.

On a positive note, though, I do think Python is quite good for hacking together smallish utilities or GUIs. For C++ programmers, it''s definitely a step in the right direction to help break the static mindset.

quote: Original post by Flarelocke
As for function overloading, I think that''s absolutely the wrong approach to the problem posed by heterogeneous parameters.

Function overloading is just a way of getting the compiler to automate a type-switch, much like any form of type-based polymorphism. Polymorphism is an incredibly important concept to incorporate into our code, as it helps us model things more like the real-world. And remember that we''re not forced into using overloading if it is present. You''re right that it doesn''t fit into the Python world, but that''s down to the lack of type-declarations, which I also count as a deficiency. CLOS has an interesting approach to solving this problem, which is through generic functions. With a generic function, you specialise methods to act on particular types within a hierarchy, and you can do so for any number of parameters. Without declarations, you have no mechanism to specify which types to specialise on.

quote:
To put essentially the same function in two or more places is just a silly thing to do.

I think you''re making unwarranted assumptions about what overloading might be used for. If we assume that there are useful, non-silly things that we want to do with overloading, then it is clearly beneficial to have. It would be much harder to build a case that says "overloading is never useful" than "overloading is sometimes useful".

quote:
I just wish it were easier. The "pythonic" way of doing function overloading is to set multiple default arguments and operate differently based on the types.

Yes, which is exactly what a compiler will do for you if you have overloading. It''s akin to saying C++ shouldn''t have runtime despatch, because we can use C to build jump tables. It''s nearly always a good idea to put complexity into the compiler wherever possible.

quote:
The distaste for indentation is almost always simple prejudice (I was the same way at first).

I don''t think it is, particularly as I have been known to defend indentation in the past. Good layout of code is obviously desirable, but I don''t believe it should be forced on us. Another problem I didn''t mention before occurs with tools that generate Python source. You have to build logic that comprehends the nesting level to be able to generate correct indentation. Yikes!

I bet this is just me, but I do not find python code easier to read, even compared to C++, but definitly not compared to something like C# or Java. This can be because im just not used to it, and I dont really know python a hell of a lot, but its just seems so strange with var types missing in method signatures etc.. I just cant tell whats going on.

quote: I dont really know python a hell of a lot, but its just seems so strange with var types missing in method signatures etc.. I just cant tell whats going on.

I suppose you find it hard to understand C++ templates too.

[edited by - petewood on March 17, 2003 11:07:30 AM]

quote: Original post by FearedPixel
I bet this is just me, but I do not find python code easier to read, even compared to C++, but definitly not compared to something like C# or Java.

Do you have equivalent experience of each? Learning syntax is obviously something you must do with any language, and you will find it hard to understand programs written with a syntax you haven't learned well.

Even if Python's syntax is not qualitatively better, you can make the quantitative argument that, if you can write a program using less code, then there is less code to have to understand.

quote:
This can be because im just not used to it, and I dont really know python a hell of a lot

There's your answer.

quote:
but its just seems so strange with var types missing in method signatures etc.. I just cant tell whats going on.

Enforced declarations create extraneous befungement. I think you're simply experiencing problems unlearning what you already know.

[edited by - SabreMan on March 17, 2003 11:57:23 AM]

quote: Original post by SabreMan
Function overloading is just a way of getting the compiler to automate a type-switch, much like any form of type-based polymorphism. Polymorphism is an incredibly important concept to incorporate into our code, as it helps us model things more like the real-world. And remember that we''re not forced into using overloading if it is present. You''re right that it doesn''t fit into the Python world, but that''s down to the lack of type-declarations, which I also count as a deficiency. CLOS has an interesting approach to solving this problem, which is through generic functions. With a generic function, you specialise methods to act on particular types within a hierarchy, and you can do so for any number of parameters. Without declarations, you have no mechanism to specify which types to specialise on.

This is a good thing. You should not be able to determine whether my access-tracked float wrapper class is a float or not. You should never specify that you *need* a dict because I might want to give you a wrapper to a dict wherein a failed lookup then looks in some other dict (I''ve heard this called caching or parenting). The typing pythonistas want you to use is duck-typing. If it looks like a duck, walks like a duck, and quacks like a duck... Of course, I have no problem with determining this at the beginning of a function to avoid problems later. But the codification of the idea that a type is anything more than a bunch of operations that can apply to some object, some of which you may need, some you may not, is definately not a feature I want in any language I program.

quote:
I think you''re making unwarranted assumptions about what overloading might be used for. If we assume that there are useful, non-silly things that we want to do with overloading, then it is clearly beneficial to have.

I''m sorry, but I can''t think of anything more different than integer pow and float pow. Integer pow can use a very simple iterative or recursive product. Float pow requires something more complex. This is easily conceived, not as two separate implementations, but as conditional based on the existence of a fractional part.

quote:
It would be much harder to build a case that says "overloading is never useful" than "overloading is sometimes useful".

It is more likely that I would argue that overloading is never a more useful construct than overloading based on runtime type determination.

quote:
Yes, which is exactly what a compiler will do for you if you have overloading. It''s akin to saying C++ shouldn''t have runtime despatch, because we can use C to build jump tables. It''s nearly always a good idea to put complexity into the compiler wherever possible.

This is a philosophical difference, and a surprising one for a lisper. Lisp''s most interesting contribution is the aggregation of pretty much all features of a programming language into one construct (the function). One would think, then, that a lisper would sympathize with the point of view of maximizing the orthogonality of language features. Of course, if you''re talking about increasing the complexity by increasing the number of predefined functions or modules, I can see how a lisper would take that position.

quote:
I don''t think it is, particularly as I have been known to defend indentation in the past. Good layout of code is obviously desirable, but I don''t believe it should be forced on us. Another problem I didn''t mention before occurs with tools that generate Python source. You have to build logic that comprehends the nesting level to be able to generate correct indentation. Yikes!

I''ve come across a couple problems with indentation, but I''ve come across equally many from using delimiters, but the indentation problems can conceivably be corrected. Really, the one problem I had was with wanting the lines to wrap (you need to use a \ by the way). Certain editors, though, have some really useful line wrapping schemes (increasing the indentation beyond the previous line)

quote: I think it''s available (probably in beta), but I haven''t played with it. Most of the stuff I''ve done with Python has been IO-bound, so I''ve not felt the need.

It''s called Psyco. http://psyco.sourceforge.net/

It''s more than a JIT, it''s specializing JIT. It can create different compilations for different typed objects, and things like that.

quote: Original post by Flarelocke
This is a good thing.

Not all the time. When you're creating an ADT, for instance, you obviously need to know all about the type you are creating, and that includes specialising methods for that type. Python's single despatch model is simply a special-case of despatching off of the "self" parameter. CLOS's multimethods provide a generic despatch model, allowing you to despatch off any number of formal parameter types, but you need declarations to be able to specify which types are involved. It is often a good thing that you don't know the exact type at the callsite, which is the point of polymorphism, but you can't make a blanket statement that we should never know the type.

quote:
But the codification of the idea that a type is anything more than a bunch of operations that can apply to some object, some of which you may need, some you may not, is definately not a feature I want in any language I program.

Yes, I agree. I've been quite clear elsewhere that I do not like languages that force you to make explicit declarations all over the place, as it's extraneous nonsense.

quote:
It is more likely that I would argue that overloading is never a more useful construct than overloading based on runtime type determination.

In software design, you should try to keep away from words like "never" and "always". If we're forced to maintain a type-switch rather than have the compiler do the work, then that's clearly irrelevant nonsense. It also breaks down your argument that we should never know the type we are dealing with. Being able to switch on type this way allows the callsite to employ the most appropriate syntactic form for the problem. For example, something I sometimes want to do is pass a list or tuple to a function, and have it perform an action for each element. If there is only one element within that list, I like to offer the syntactic pleasantry of doing away with the formation of a single-element list, and to do that I have to perform a type-switch to avoid Python throwing a TypeError - the iteration construct demands an iterable type, while the language does not allow us to build our own constructs which also demand certain types [1]. That puts the programmer in a subordinate position to the language designer even for their own problem domain, even though the programmer is the one who knows what their problem demands.

quote:
This is a philosophical difference

It has hard tangible results which can be seen in the number of lines of code required to solve a problem that would benefit from the presence of single dynamic despatch. From the Lisp POV that you're arguing elsewhere, this would not be such a problem if you could provide your own mechanism and have it fit into the language. Languages which disallow access to the intermediate representation by providing an obfuscating layer of enforced syntax do not allow modification or enhancement of that enforced syntax. But that's an entirely different argument that I don't wish to pursue in this thread - it's already been discussed in the numerous Lisp threads.

quote:
Lisp's most interesting contribution is the aggregation of pretty much all features of a programming language into one construct (the function).

The above comment is nothing more than your personal opinion. It's not relevant to the issue of overloading and/or generic despatch in Python.

quote:
One would think, then, that a lisper would sympathize with the point of view of maximizing the orthogonality of language features.

You can't just cook up some imaginary stereotype and tell me my view isn't consistent with it. Concentrate on what's been said please, not on what might or might not be the opinion of a group of people you've never met. Declarations and generic despatch exist and are used in CL, which is all we need to know.

quote:
Of course, if you're talking about increasing the complexity by increasing the number of predefined functions or modules

I'd expect you to understand by now that is not what I'm talking about.

Edit:
[1] Or it may be sufficient to have bounded parametric polymorphism, where we don't have to explicitly mention the type, but we need to say what properties the type must have. For my example, we might say that the type must be iterable.

[edited by - SabreMan on March 18, 2003 6:17:41 AM]