Re: no variable or argument declarations are necessary.
Op 2005-10-07, Diez B. Roggisch schreef [EMAIL PROTECTED]: Well, that exactly is the point where we make the transition from this is how things work to pure speculation. Everything starts with pure speculation. I had no intention of introducing the big type system here. I just think people who oppose type systems, limit themselves too much to how things currently work and from there oppose anything that resembles a type system instead of thinking of what they would like a type system to do even if it is not implemtable now. Can't say that there won't be a solution someday - but certainly it requires much more, and from above nobody can say that this would solve _any_ problem. What you propose above is what JAVA does - plus more dynamicity. So it isn't exactly JAVA afterall. Well, given that even the non-dynamic, everything has to be annotated JAVA fails to deal with ANY (called Object there), So please explain how my system fails with the ANY. I can't see how a more dynamic environment will do _better_ in that respect. You first argued that a type system had to limit the coder and you gave the example of the homegeneous list. I suggested an ANY type and asked how a homegeneous list of ANY's would limit the coder. Your respons was that this was like a JAVA Object or C void* hack, that can be used to circumvent the type system and cause all kinds of problems, presumebly python was not vulnerable to. So I would either like you to explain how my idea can be used to circumvent the type system and cause problems, which don't concern python or explain how this system will limit the coder with respect what can be done in python. So unless you lay out some more detailed ideas how that works, this surely won't do much if any better than JAVA does today - and JAVA sucks _precisely_ because of the half-static-half-dynamic nature. It gives you both troubles - runtime errors like in python, together with compile-time limitations. I have no need to convince you. It was you who made this claim how a type system had to limit the coder. That you can't see how it could be done is not an argument. Surely if a typesystem *must* limit the user or else cause all kinds of problems as more general argument can be given that doesn't depend on the specific implementation. Let's face it: you don't know much about type-systems. I do know a bit more - but don't claim to possess the holy grail. And I don't say that more powerful analyzing isn't possible. However, all you do so far is fantasizing and fail to see why not. Well, that failure might be because of limited sight on your side - not necessarily on our, which you constantly claim. Well, I could accept that if you would have explained what the problem would be with my system instead of just saying you couldn't see how it would be more usefull than JAVA Objects. Visions are a nice thing - but actually, in the scientific domain not so much a vision, but proofs are what is needed. Well you made the claim that a type system had to limit the coder. Now prove your claim. Untill this is done I see no problem thinking about type systems that don't limit the coder. And if you consider it hostile that nobody buys your ideas because so far they aren't more than marketing/whishful thinking, I'm sorry that I can't help you. I don't consider it hostile that nobody buys my ideas. I considered the environment here hostile to type systems long before I brought my two cents to the discussions about this subject here. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin http://[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Alex Martelli) writes: ap.py:4: No global (test) found ap.py:5: Local variable (ego1d) not used Helen:/tmp alex$ If you're so typo-prone and averse to unittests that you consider this kind of issue to be a serious problem, just use pychecker and get informed about any such typo, just as above. That's very helpful, but why isn't it built into Python? Because some users will prefer to use a different approach to checking, for example, such as pylint (much more thorough in enforcing coding rules and checking for all sort of things) or nothing (much faster than pychecker, which in turn is faster than pylint). Just as for other programming tools, such as, say, an editor, I think it's wise to avoid excessive and premature standardization on one specific tool to the detriment of others. (IDLE is bundled with Python, but not _built into_ it -- indeed some would claim that the bundling was too much). Not all tools need evolve at the same speed as the core language, which currently follows a wise policy of major releases (2.3, 2.4, etc) about 18 to 24 months apart, and NO feature changes for point release (2.4.2 has exactly the same features as 2.4.1 -- it just fixes more bugs). Any tool which gets built into python (or, less strictly but still problematically, is separate but bundled with it) must get on exactly the same schedule and policy as Python itself, and that is definitely not something that's necessarily appropriate. If you're worried about the end-users which can't be bothered to download tools (and, for that matter, libraries) separately from the main language, the solution is sumo releases -- Enthought Python (from Enthought) being an extreme example, but Active Python (from ActiveState) comes with quite a few bundled add-ons, too. I believe that Linux has proven the validity of this general model: having the core (mostly the kernel, in Linux's case; the language and standard library, in Python's) evolve and get released as its own speed, and having _distributions_ bundling the core with different set of tools and add-ons get released on THEIR preferred schedules, independently. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]: Suppose we have a typesystem which has the type ANY, which would mean such an object could be any type. You could then have homogenous lists in the sense that all elements should be of the same declared type and at the same time mix all kind of type in a particular list, just as python does. The you have JAVA Object or C void*. Which cause all kinds of runtime troubles because they essentially circumvene the typechecking! Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. So how would this limit python. The limitation is that in static languages I must _know_ what type to cast such an ANY, before calling anything on it. Otherwise its useless. even though ususally the contents of a list share some common behaviour. And that exactly is the key point here: in a statically typed world, that common behaviour must have been extracted and made explicit. Would my suggestion be classified as a statically typed world? See above. Your answer tells more about you then about my suggestion. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon wrote: Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]: Suppose we have a typesystem which has the type ANY, which would mean such an object could be any type. You could then have homogenous lists in the sense that all elements should be of the same declared type and at the same time mix all kind of type in a particular list, just as python does. The you have JAVA Object or C void*. Which cause all kinds of runtime troubles because they essentially circumvene the typechecking! Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. [sigh]. No, it's just you being you. Diez' intention seemed fairly clear to me: he is pointing out that strongly-typed systems invariably fall back on generic declarations when they want to allow objects of any type (which, it seems to me, is what you were proposing as well). In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. So how would this limit python. The limitation is that in static languages I must _know_ what type to cast such an ANY, before calling anything on it. Otherwise its useless. even though ususally the contents of a list share some common behaviour. And that exactly is the key point here: in a statically typed world, that common behaviour must have been extracted and made explicit. Would my suggestion be classified as a statically typed world? See above. Your answer tells more about you then about my suggestion. Damn, I've been keeping away from this thread lest my exasperation lead me to inappropriate behaviour. Is there any statement that you *won't* argue about? leaving-the-(hopefully)-last-word-to-you-ly y'rs - steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Steve Holden [EMAIL PROTECTED] writes: In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. Let's see if I understand what you're saying: C and Java: you get useful type checking except when you declare a reference as type ANY. This is a shortcoming compared to: Python: where you get no useful type checking at all. That is not very convincing logic. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Brian Quinlan [EMAIL PROTECTED] writes: Without a clear idea of the nature of the proposal, it is impossible to assess it's costs and benefits. So could a proponent of optional declarations please provide a more clear proposal? There is no proposal on the table. There's a discussion of how this stuff can work, and whether it's useful. As for how the compiler deals with imported modules, see for example Common Lisp or Haskell or ML--how do they do it? Except that you are providing neither useful input on how it could work nor on whether it would be useful. All you are doing is telling people to do research on other languages (that resumably do things in a way more to your liking). In conclusion, this thread is unlikely to make any useful progress. Cheers, Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Steve Holden [EMAIL PROTECTED] writes: In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. Let's see if I understand what you're saying: C and Java: you get useful type checking except when you declare a reference as type ANY. This is a shortcoming compared to: Python: where you get no useful type checking at all. That is not very convincing logic. As we say in Yorkshire, There's none as thick as them that wants to be. Let's try to get this in context. Antoon: Suppose we have a typesystem which has the type ANY, which would mean such an object could be any type. You could then have homogenous lists in the sense that all elements should be of the same declared type and at the same time mix all kind of type in a particular list, just as python does. Diez: The you have JAVA Object or C void*. Which cause all kinds of runtime troubles because they essentially circumvene the typechecking! Antoon: Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. Me: Diez' intention seemed fairly clear to me: he is pointing out that strongly-typed systems invariably fall back on generic declarations when they want to allow objects of any type (which, it seems to me, is what you were proposing as well). You: C and Java: you get useful type checking except when you declare a reference as type ANY. This is a shortcoming compared to: Python: where you get no useful type checking at all. The points that have repeatedly been made are: 1. That even the strict typings required by languages like Java and C++ actually end up getting in the way when the pragmatic requirements of real-world problems have to be taken into account. 2. That the benefits of declarations are overstated by many of their proponents. 3. That Python as it is today allows the dynamic creation of names, which are therefore inherently not available for declaration. On existing evidence it's extremely unlikely that this post will end the thread, but I certainly wish *something* would. Unfortunately I seem to have become part of the problem in that respect :-) regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Brian Quinlan [EMAIL PROTECTED] writes: There is no proposal on the table. There's a discussion of how this stuff can work, and whether it's useful. As for how the compiler deals with imported modules, see for example Common Lisp or Haskell or ML--how do they do it? Except that you are providing neither useful input on how it could work nor on whether it would be useful. All you are doing is telling people to do research on other languages (that resumably do things in a way more to your liking). Nah. I just see the import statement as a solved problem. Do it the same way those other languages do. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. Well, because maybe I wanted you to give you an example of languages that are statically typed and have such an any construct - that, by the way, is not a piece of inguine imagination of yours, but has been thought of before, e.g. CORBA (and called there any, too)? It makes no sense putting python into that context - as it is _not_ statically typed. Which you should know, after discussing this very subject way too long. Would my suggestion be classified as a statically typed world? See above. Your answer tells more about you then about my suggestion. Your answer tells us something too: Just because you don't know anything about typechecking does not mean that you are in the position to make assumptions on how things could work if the people who know stuff wouldn't be so stupid. That's like saying cars can't fly because the stupid engineers lack my sense of imagination. Just blathering about the possibility of some super-duper-typechecker and countering criticism or being told about problems in that domain by making bold statements that this sure could work - provide us with an implementation. Or maybe - just maybe - you could sit back and think about the fact that lots of people who are way cleverer than you and me have been working on this subject, and so far haven't found a way. Which doesn't necessarily mean that there is no way - but certainly its hard, theory-laden work and won't emerge in a NG discussion by some snide remarks of either you or anybody else. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Steve Holden [EMAIL PROTECTED] writes: In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. Let's see if I understand what you're saying: C and Java: you get useful type checking except when you declare a reference as type ANY. This is a shortcoming compared to: Python: where you get no useful type checking at all. That is not very convincing logic. No, he said that this typechecking wouldn't make sense in the case of ANY being used. And the plethorea of ClassCastExceptions and Segfault proves the point :) Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Let's see if I understand what you're saying: C and Java: you get useful type checking except when you declare a reference as type ANY. This is a shortcoming compared to: Python: where you get no useful type checking at all. That is not very convincing logic. It's started to get very misleading - Python gives you plenty of type-checking, as we all know, just not at compile-time. Also comparing Python to C/Java as you have done is not very appropriate unless you want Python to have the same sort of compile times as C and Java do. I think you're doing a small disservice to respond to Steve when not acknowledging the context of the thread, where Diez was explaining that the system used in ML would not work in Python, then Antoon made a suggestion that would fix that particular problem but make others worse. I'm not convinced that the Java route - where you type out lengthy type declarations to get some compile-time typechecking which you usually end up having to bypass later anyway - is at all beneficial, at least not in the context of Python. I can't ever remember a time when I thought type checking really saved me from a bug there when using C/C++/Java, but I _can_ remember many times where I've had to consider which cast or conversion to use, or had to write another overloaded function to accommodate a similar-but-different type, or debug a complex template message, or add a superfluous base class or interface, all just to get the kind of genericity that Python gives for free. And it's no good saying that variable declarations will be optional, because as soon as these statically-typed variables enter the standard library, every Python programmer will have to take these considerations on board when writing their code, whether we want to use them or not. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Ben Sizer [EMAIL PROTECTED] wrote: It's started to get very misleading - Python gives you plenty of type-checking, as we all know, just not at compile-time. There's more to it than just that. Python's type checking is not just not done at compile time, it's done as late in run time as possible. One might call it just-in-time type checking. It's not hard to imagine a Python-like language which included (perhaps optional) variable declarations. A declaration would essentially be an assertion which was checked after each assignment to that name. So, you could write: int i = 5 i = 5.6 and the second statement would throw TypeError. This would give you C++/Java style type safety, but it still wouldn't be compile time. Perhaps a better way to describe it is that the checking isn't an is-a assertion, but an acts-like assertion (sort of like Java's interfaces). To take an example, in the function: def first3(y): if len(y) 3: return y return y[0:3] all I really need from the argument is that I can call len() on it and it can be sliced. An easy way to describe this would be to say that y must be a sequence, but that's not strictly accurate, since I can easily declare my own class which meets those requirements without being a subclass of sequence (even ignoring for the moment that 'sequence', while talked about in the documentation, doesn't actually exist as something you can subclass). -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-07, Steve Holden schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]: Suppose we have a typesystem which has the type ANY, which would mean such an object could be any type. You could then have homogenous lists in the sense that all elements should be of the same declared type and at the same time mix all kind of type in a particular list, just as python does. The you have JAVA Object or C void*. Which cause all kinds of runtime troubles because they essentially circumvene the typechecking! Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. [sigh]. No, it's just you being you. Diez' intention seemed fairly clear to me: he is pointing out that strongly-typed systems invariably fall back on generic declarations when they want to allow objects of any type (which, it seems to me, is what you were proposing as well). It is not about falling back on generic declarartion, it is about how such object will be treated. Diez seems to think that strongly-typed language can only deal with generic declarations by using something that allows circumventing the type system. In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. And you are wrong. The problem with the C void* construct (I'm not that familiar with java) is that all type information is lost. When you use such a parameter in a function you have no idea what you are working with. But that doesn't need to be if you have a typesystem with an ANY type. Such a type declaration would mean that object of any type could be used here. However that doesn't imply that the type information of the actual objects used, has to be lost. That type information may still be available and usefull for further type checking. That you and Diez can only think about C, C++ or java constructs when I mention an ANY type, is your limitation. It doesn't need to be the limitation of a specific type system. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
On Fri, 07 Oct 2005 06:01:00 -0400, Roy Smith wrote: There's more to it than just that. Python's type checking is not just not done at compile time, it's done as late in run time as possible. One might call it just-in-time type checking. Well there you go then. Instead of pulling our hair out that Python has no type checking (that's a bug in the language design, woe woe woe!!!) we can just say that Python does JIT type checking, which not only is a feature, but also satisfies the Pointy Haired Bosses who demand buzzwords they can't understand. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Roy Smith a écrit : There's more to it than just that. Python's type checking is not just not done at compile time, it's done as late in run time as possible. One might call it just-in-time type checking. It's more of a Nearly too late type checking I would say. Not that I complain but it would be great if there were also some automatic type checking to catch a few errors as soon as possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Christophe wrote: It's more of a Nearly too late type checking I would say. Not that I complain but it would be great if there were also some automatic type checking to catch a few errors as soon as possible. use assert as the soonest possible point. implementing type gates is trivial, if you think you need them. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-07, Diez B. Roggisch schreef [EMAIL PROTECTED]: Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. Well, because maybe I wanted you to give you an example of languages that are statically typed and have such an any construct But since I have no such type system in mind, such an example is useless. - that, by the way, is not a piece of inguine imagination of yours, but has been thought of before, e.g. CORBA (and called there any, too)? It makes no sense putting python into that context - as it is _not_ statically typed. Which you should know, after discussing this very subject way too long. The fact that something else uses the same name, for something doesn't mean it has to be implemented the same way. Would my suggestion be classified as a statically typed world? See above. Your answer tells more about you then about my suggestion. Your answer tells us something too: Just because you don't know anything about typechecking does not mean that you are in the position to make assumptions on how things could work if the people who know stuff wouldn't be so stupid. That's like saying cars can't fly because the stupid engineers lack my sense of imagination. Then argue against my ideas, and not your makings of it. If I just use 'ANY' and you fill that in with C void* like implementation and argue against that, then you are arguing against your own ghosts, but not against what I have in mind. It may very well turn out that my idea is useless, but I will only accept that when someone comes with arguments against my actual idea, and not with arguements against their projection of it. Just blathering about the possibility of some super-duper-typechecker and countering criticism or being told about problems in that domain by making bold statements that this sure could work - provide us with an implementation. You have not counterd my idea with criticism. You have decorated my idea with how you think it would be implemented (C void*) and argued against that. I don't need to give an implementation to notice, that you jumped to a particular implementation and basicly just countered that implementation, not the idea in general. Or maybe - just maybe - you could sit back and think about the fact that lots of people who are way cleverer than you and me have been working on this subject, and so far haven't found a way. Which doesn't necessarily mean that there is no way - but certainly its hard, theory-laden work and won't emerge in a NG discussion by some snide remarks of either you or anybody else. As far as I'm concerned that was just meant as a matter of fact remark, with no snide intentions. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Fredrik Lundh a écrit : Christophe wrote: It's more of a Nearly too late type checking I would say. Not that I complain but it would be great if there were also some automatic type checking to catch a few errors as soon as possible. use assert as the soonest possible point. implementing type gates is trivial, if you think you need them. Still, it would be great if there were also some automatic type checking in place. Using assert is hardly automatic and non intrusive. I mean, why not ? Why does the compiler let me do that when you know perfectly that that code is incorrect : def f(): return a + 5 Of course the system can't be perfect but it doesn't need to be. It doesn't need to constrain us in any way but if it can detect some errors early, then it is worth it. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Fredrik Lundh [EMAIL PROTECTED] writes: use assert as the soonest possible point. implementing type gates is trivial, if you think you need them. What this is about (to me at least) is the edit-debug cycle. Let's say I write some Python code, using assert to validate datatypes. Maybe I've made 4 errors. I then write a test function and run it. Boom, the first assert fails. I fix the first error, run again. Boom, the next assert fails. Fix the next error, run again, boom, fix, etc. Four edit-debug cycles. With static typing, I run the compiler, get 4 error messages, fix all 4, and can get on with the next phase of testing with three fewer edit cycles. That's a definite benefit of languages like Java. It's not imaginary. Unit tests on Python code don't make it go away. I have less Java experience than Python experience by now, but I still find that Java programs take me fewer iterations to get working than Python programs. The trouble is that Java has a thousand deficiencies that outweigh that particular benefit, so overall I like Python a lot better anyway. Now some of the Python-is-perfect crowd seems to suffer from a Blub paradox (http://c2.com/cgi/wiki?BlubParadox). They see annoying, static typed languages like C and Java, and they see pleasant, dynamically typed languages like Python, and conclude that static types = annoying, when in fact they can be orthogonal. So, can there be a language that's both statically typed, and pleasant? I haven't used one yet, but lately I've been reading about Haskell and want to give it a try. I keep finding statements like: To me, Haskell is what Python should have evolved to. As a long-time Python programmer, I have been very, very pleased with Haskell and am currently working on porting my code to it (and write new code in Haskell at every opportunity). (http://supybot.com/Members/jemfinch/haskell-sucks/document_view) or: Using Haskell to develop OpenAFP.hs led to programs that eat constant 2MB memory, scale linearly, and are generally 2OOM faster than my Perl library. Oh, and the code size is 1/10. (http://www.perl.com/pub/a/2005/03/03/pugs_interview.html - Autrijus also raves about how great the book Types and Programming Languages supposedly is--I'm trying to borrow a copy. Yeah, this is a Perl comparison, but I think of Perl as being roughly equivalent to Python except a lot uglier). or: Haskell is the least-broken programming language available today. C, C++, Perl, Python, Java, and all the other languages you've heard of are all much more broken, so debating their merits is pointless. :-) Unfortunately Real Life involves dealing with brokenness. (http://www106.pair.com/rhp/books.html) or: In conducting the independent design review at Intermetrics, there was a significant sense of disbelief. We quote from [CHJ93]: It is significant that Mr. Domanski, Mr. Banowetz and Dr. Brosgol were all surprised and suspicious when we told them that Haskell prototype P1 (see appendix B) is a complete tested executable program. We provided them with a copy of P1 without explaining that it was a program, and based on preconceptions from their past experience, they had studied P1 under the assumption that it was a mixture of requirements specification and top level design. They were convinced it was incomplete because it did not address issues such as data structure design and execution order. (http://haskell.org/papers/NSWC/jfp.ps - this was from a bake-off for a military application where the Haskell solution had 85 lines of code to Ada's 767, C++'s 1105, and Relational Lisp's 274). Obviously I'm in the usual rose-colored-glasses phase of finding out about something new and interesting, but I can't help thinking these guys are onto something. Quite a few of the Haskell Cafe mailing list members seem to have come to Haskell from Python. (Haskell tutorial: http://www.isi.edu/~hdaume/htut/ - I've read most of this and it looks pretty cool--definitely a steeper learning curve than Python but the result looks a lot more powerful). -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon wrote: Then argue against my ideas, and not your makings of it. If I just use 'ANY' and you fill that in with C void* like implementation and argue against that, then you are arguing against your own ghosts, but not against what I have in mind. Well, you didn't tell us what you had in mind. You just said let's introduce something like any. I showed you existing implementations of such a concept that have problems. You say thats not what _I_ have in mind, so your criticism doesn't apply. Guess what, I can't read your mind. But you did not tell me in what your idea is different from existing concepts. You have not counterd my idea with criticism. You have decorated my idea with how you think it would be implemented (C void*) and argued against that. I don't need to give an implementation to notice, that you jumped to a particular implementation and basicly just countered that implementation, not the idea in general. Again - where is your idea layed out in (more) detail, so that one can discuss them? That was all that I'm asking - which of course you carefully avoided... As far as I'm concerned that was just meant as a matter of fact remark, with no snide intentions. Where exactly come the facts? All I see is some vague there should be something better, by introducing ANY. But no details how typechecking then would work. I showed you that existing type systems can't properly cope with ANY so far and allow for much errors. Just saying but mine won't is a little bit thin, don't you think?l Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
It is not about falling back on generic declarartion, it is about how such object will be treated. Diez seems to think that strongly-typed language can only deal with generic declarations by using something that allows circumventing the type system. No, I don't - now it's you who makes assumptions about what I think. ML and other FPs show that genericity can be done without circumvening. Templates and generics in C++ partially do so. In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. And you are wrong. The problem with the C void* construct (I'm not that familiar with java) is that all type information is lost. When you use such a parameter in a function you have no idea what you are working with. You don't know JAVA - I do. And nobody said that it lost that type-information. It doesn't. Still, errors occur - namely ClassCastEcxeptions. That indicates that going back and forth via ANY doesn't necessarily lose any type information, but the capability of today's type-systems to keep that information across such a transition. This won't work: Object foo = A(); B bar = (B) foo; And please, pretty please don't argue with the simplicity of that example - think of a bazillion statements between these two, possibly done with run-time-instantiated classes that weren't known at compile-time. But that doesn't need to be if you have a typesystem with an ANY type. Such a type declaration would mean that object of any type could be used here. However that doesn't imply that the type information of the actual objects used, has to be lost. That type information may still be available and usefull for further type checking. JAVA has that. That you and Diez can only think about C, C++ or java constructs when I mention an ANY type, is your limitation. It doesn't need to be the limitation of a specific type system. Again: where are the specifics of this system? In your head? Tell us the gory detail, please. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin http://[EMAIL PROTECTED] wrote: What this is about (to me at least) is the edit-debug cycle. Let's say I write some Python code, using assert to validate datatypes. Maybe I've made 4 errors. I then write a test function and run it. Boom, the first assert fails. I fix the first error, run again. Boom, the next assert fails. Fix the next error, run again, boom, fix, etc. Four edit-debug cycles. With static typing, I run the compiler, get 4 error messages, fix all 4, and can get on with the next phase of testing with three fewer edit cycles. That's certainly the plan, but my experience is that it's not the whole story, for a few reasons. 1) I can often run 4 Python edit-debug cycles in the time it takes me to run a single C++ cycle, especially if there's a whole pile of build system gunk layered on top of the raw compile step. 2) When I get a bunch of compile errors, I know that many of them are just cascaded from a single problem. Thus, I tend to fix the first one and only take a quick look at all the others. If it's obvious what the problem is, I'll fix it, but as often as not, I'll just recompile and see what pops out the next time. 3) Many times, I'll spend more time making the compiler happy than the protection it affords me is worth. C++ is such a complex language, it's really hard to write a compiler which follows every detail of the spec, and the details are what kills you. We had a case the other day where a const_cast of a reference returned by a function worked just fine on Solaris, but failed on HPUX. We ended up with three guys digging through reference manuals trying to figure out how const_cast and references are supposed to interact. We ended up deciding what we were doing was legal, but we still had to devise a work-around so it compiled on all platforms. It's actually a little more complex than that, because we don't even write raw const_cast's, we use a CONST_CAST macro to work around older compilers that don't support modern casting, so we burned a little more time double-checking that our macro expansion wasn't at fault. We could have done a lot of Python edit-debug cycles in the time it took to sort that one out. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Now some of the Python-is-perfect crowd seems to suffer from a Blub paradox (http://c2.com/cgi/wiki?BlubParadox). They see annoying, static typed languages like C and Java, and they see pleasant, dynamically typed languages like Python, and conclude that static types = annoying, when in fact they can be orthogonal. So, can there be a language that's both statically typed, and pleasant? I haven't used one yet, but lately I've been reading about Haskell and want to give it a try. Nobody says that there can't be possibly better languages like python overall, or for specific tasks. However, this discussion is about introducing type-checking to python. And as someone who has done his fair share of FP programming let me assure you that - all declarations are fully type annotated. The inference only comes into play on _expressions_. The result in python would be that you'd have to write def foo(x:int):int : return 10 but then could use x = foo() which made the inference possible. But it _doesn't figure out that foo returns an int because there is one returned, and misses the :int in the declaration! Genericity is reached through solving somewhat more complicated type equations - but these still require declarations: def bar(l:list[whatever]):whatever : return head(l) x = bar([10]) can be resolved as [] will me a list-constructor that gets passed an int literal - wich in turn means that whatever as type-variable is bound to int, and thus x is an int, as that is the return type of bar. - FPs share their own set of problems - try writing a server. The have inherent troubles with event-driven programs. Then you need monads, and that makes things a little bit more ugly... Still, FP is cool. But python too. And just attaching some type-inference to python won't work. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Diez B. Roggisch [EMAIL PROTECTED] writes: - FPs share their own set of problems - try writing a server. The have inherent troubles with event-driven programs. Erlang? Still, FP is cool. But python too. And just attaching some type-inference to python won't work. Yeah, I've figured declarations in Python would be more like Common Lisp's, i.e. optional, enforced at compile time only when the compiler can easily figure it out, and at runtime otherwise. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Diez B. Roggisch [EMAIL PROTECTED] writes: - FPs share their own set of problems - try writing a server. The have inherent troubles with event-driven programs. Erlang? Guess what, worked with that, too :) And let me assure you - it does have pretty much runtime type error issues. It's interpreted. I'm not sure what the compiler/parser gets at loading a source file. And the Mnesia distributed database lets you easily query the wrong values... It's interesting, and it's concurrent programming paradigms are great. But it's far from being perfect, and needs thourough testing before deploying new code. Still, FP is cool. But python too. And just attaching some type-inference to python won't work. Yeah, I've figured declarations in Python would be more like Common Lisp's, i.e. optional, enforced at compile time only when the compiler can easily figure it out, and at runtime otherwise. Easy cases are easy... The thing is: I'm all for typechecking as long as it doesn't burden me. In FP it doesn't, as the expressional power is way better. But in JAVA, it does. And just doing wishful-thinking about that Python should do better that won't help... :) Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Christophe wrote: Fredrik Lundh a écrit : Christophe wrote: It's more of a Nearly too late type checking I would say. Not that I complain but it would be great if there were also some automatic type checking to catch a few errors as soon as possible. use assert as the soonest possible point. implementing type gates is trivial, if you think you need them. Still, it would be great if there were also some automatic type checking in place. Using assert is hardly automatic and non intrusive. I mean, why not ? Why does the compiler let me do that when you know perfectly that that code is incorrect : def f(): return a + 5 Of course the system can't be perfect but it doesn't need to be. It doesn't need to constrain us in any way but if it can detect some errors early, then it is worth it. While this is a perfectly acceptable feature request, we should remember that Python is developed and maintained by a volunteer team. Do we *really* want them spending their time adding features like this? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-07, Diez B. Roggisch schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Then argue against my ideas, and not your makings of it. If I just use 'ANY' and you fill that in with C void* like implementation and argue against that, then you are arguing against your own ghosts, but not against what I have in mind. Well, you didn't tell us what you had in mind. Indeed I hadn't. It wasn't needed for the question I posed then. You just said let's introduce something like any. I showed you existing implementations of such a concept that have problems. But as far as I can see that is a problem of the implementation not necessarily of the concept. You say thats not what _I_ have in mind, so your criticism doesn't apply. Guess what, I can't read your mind. But you did not tell me in what your idea is different from existing concepts. Indeed you can't read my mind, but what pops up in your mind shows your preconceptions. You could have just answered the question as it was posed, instead of filling in the details yourself, maybe remarking that you didn't see how it would work with current type systems you know off. You have not counterd my idea with criticism. You have decorated my idea with how you think it would be implemented (C void*) and argued against that. I don't need to give an implementation to notice, that you jumped to a particular implementation and basicly just countered that implementation, not the idea in general. Again - where is your idea layed out in (more) detail, so that one can discuss them? That was all that I'm asking - which of course you carefully avoided... Sure I'm reluctant to give details. I consider this a hostile environment, for this kind of proposals. I'm sure people will be able to come up with all kind of problems my idea won't solve and will see this as a reason to think the idea is useless. Since I have no intention to As far as I'm concerned that was just meant as a matter of fact remark, with no snide intentions. Where exactly come the facts? About how you filled in the details yourself when all I mentioned was a type system with an ANY type. All I see is some vague there should be something better, by introducing ANY. But no details how typechecking then would work. I showed you that existing type systems can't properly cope with ANY so far and allow for much errors. Just saying but mine won't is a little bit thin, don't you think?l The main idea is that type information would be available at two places. 1) The names, which carry the declared type. 2) The objects which carry the type/class they belong too. When an object is bound to a name, a check is made that the type of the object is compatible with the declared type of the name. A name with type ANY, would be just like any python variable or instance now. Python could implement this by instead of storing its variables in dictionaries as (name, value) tuples, by storing them as (name, declaration, value) tuples and making the necesarry checks at (re)bind time. Variables that are not declared would get the ANY declaration so that current scripts would just remain working as they do now. But as the compiler got more sophisticated some of these checks might be doable at compile time instead of at run time. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Diez B. Roggisch [EMAIL PROTECTED] writes: Erlang? Guess what, worked with that, too :) And let me assure you - it does have pretty much runtime type error issues. It's interpreted. Yes, it makes no attempt at being statically typed. It's like Python that way, AFAIK. Easy cases are easy... The thing is: I'm all for typechecking as long as it doesn't burden me. In FP it doesn't, as the expressional power is way better. But in JAVA, it does. And just doing wishful-thinking about that Python should do better that won't help... :) How about Lisp? It seems to do some good there, without getting in the way. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
You just said let's introduce something like any. I showed you existing implementations of such a concept that have problems. But as far as I can see that is a problem of the implementation not necessarily of the concept. Without any concept, sure there can't be problems with that concept. You say thats not what _I_ have in mind, so your criticism doesn't apply. Guess what, I can't read your mind. But you did not tell me in what your idea is different from existing concepts. Indeed you can't read my mind, but what pops up in your mind shows your preconceptions. You could have just answered the question as it was posed, instead of filling in the details yourself, maybe remarking that you didn't see how it would work with current type systems you know off. How can one answer a question without what he knows? Sure I fill in the context. If I wouldn't know that this whole NG is about python, I wouldn't know how to answer most of the questions that arise here. Which is a general thing about communication. But I certainly have had more contact with type systems than you had - so my filling-out was by no means unreasonable - as you imply. Without further details, one can only guess. And debuking guesswork by saying but _that_ wasn't what I meant as you permanently do is easy - but doesn't make _your_ point valid. Sure I'm reluctant to give details. I consider this a hostile environment, for this kind of proposals. I'm sure people will be able to come up with all kind of problems my idea won't solve and will see this as a reason to think the idea is useless. Why hostile? Because people will possibly destroy your wishful thinking by providing counter examples - if they exist? I doubt that a serious proposal would get suppressed here - as the static compilers that have shown up recently prove, as they have been greeted and met with reasonable criticism where it was in order. You didn't come up with an Idea so far, as I'm concerned. Just some random thoughts. But then again, here we go: The main idea is that type information would be available at two places. 1) The names, which carry the declared type. JAVA. 2) The objects which carry the type/class they belong too. That already is the case. When an object is bound to a name, a check is made that the type of the object is compatible with the declared type of the name. JAVA exactly does that. A name with type ANY, would be just like any python variable or instance now. Python could implement this by instead of storing its variables in dictionaries as (name, value) tuples, by storing them as (name, declaration, value) tuples and making the necesarry checks at (re)bind time. Variables that are not declared would get the ANY declaration so that current scripts would just remain working as they do now. So far, this is exactly what java does - plus a more dynamic approach to method/function invocation on ANY. So it seems my assumptions about what you had in mind weren't so false after all, eh? But as the compiler got more sophisticated some of these checks might be doable at compile time instead of at run time. Well, that exactly is the point where we make the transition from this is how things work to pure speculation. Can't say that there won't be a solution someday - but certainly it requires much more, and from above nobody can say that this would solve _any_ problem. What you propose above is what JAVA does - plus more dynamicity. Well, given that even the non-dynamic, everything has to be annotated JAVA fails to deal with ANY (called Object there), I can't see how a more dynamic environment will do _better_ in that respect. So unless you lay out some more detailed ideas how that works, this surely won't do much if any better than JAVA does today - and JAVA sucks _precisely_ because of the half-static-half-dynamic nature. It gives you both troubles - runtime errors like in python, together with compile-time limitations. Let's face it: you don't know much about type-systems. I do know a bit more - but don't claim to possess the holy grail. And I don't say that more powerful analyzing isn't possible. However, all you do so far is fantasizing and fail to see why not. Well, that failure might be because of limited sight on your side - not necessarily on our, which you constantly claim. Visions are a nice thing - but actually, in the scientific domain not so much a vision, but proofs are what is needed. And if you consider it hostile that nobody buys your ideas because so far they aren't more than marketing/whishful thinking, I'm sorry that I can't help you. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Christophe wrote: I mean, why not ? Why does the compiler let me do that when you know perfectly that that code is incorrect : def f(): return a + 5 probably because the following set is rather small: bugs caused by invalid operations involving only literals, that are not discovered during initial testing /F -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Mike Meyer [EMAIL PROTECTED] writes: When you want local variable in lisp you do : (let ((a 3)) (+ a 1)) Excep that's not a decleration, that's a binding. That's identical to the Python fragment: a = 3 return a + 1 except for the creation of the new scope. Not a variable decleration in site. Really not though, the scope is what makes it a declaration. In Python you can say: for i in 1,2: if i == 2: print x # x is unbound the first time through the loop x = 9# but bound the second time and the print doesn't raise an error. Further, 'x' is still in scope even after the loop exits. Scheme lets you say something like (define (counter) (let ((k 0)) (define (f) (set! k (+ 1 k)) k) f)) Yeah, I know you'd write it a bit more concisely in Scheme, but I wanted to make it look like the Python equivalent: def counter(): k = 0 def f(): k += 1 return k return f The trouble is, in f, k is neither local nor global, so Python throws up its hands and raises an error. There's no way to tell it where to find k. This could be solved with a declaration, if Python understood it. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
How about Lisp? It seems to do some good there, without getting in the way. I don't know much about lisp. But the thing is that one of the most important data structures in python (and basically the only one in LISP), lists, are a big problem to type-checking if they aren't homogenous. So I guess one can write a compiler that generates specialized code for lists of a certain homogenous kind, like lists of int, float and maybe string - and as long as you ensure that code is called with such a list, you're ok. But I think that is what psyco does, too (no idea how these two compare) Basically, all type-inferencing boils down to collecting constraints on variable values. Like in this expression z = x + y It will be internall represented by this: z:C = x:A + y:B which introduces type-variables A,Band C. That tells us that all operations __plus__ and their respective types could be meant, thus A B C are constrained by these types. Which, in an overloading-allowing language, can get pretty much. The trick is to find a solution for the variables that satisfy all the constraints. And a solution are actual types, not ad-hoc sets of types - otherwise, you can't create any specialized code, and the compiler will puke on you. Saying z += 10 now creates a constraint that binds C to int, and subsequently A and B. Now the problem is someting like this: if x is None: x = 10 else: x = x * 10 Lets assume A as type-var for x. Then we have the two contstraints A - int and A - None. Now - is there a type that satisfies both constraints? No. And even worse, A shall be int by x = 10 - but that collides with A-None. So the only thing you can do is resort to A=ANY - and interpret that code above :) Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon [EMAIL PROTECTED] wrote: ... egold = 0: while egold 10: if test(): ego1d = egold + 1 Oh come on. That is a completely contrived example, No it is not. You may not have had any use for this kind of code, but unfamiliary with certain types of problems, doesn't make something contrived. It's so contrived it will raise a SyntaxError due to the spurious extra colon on the first line;-). Or, consider, once the stray extra colon is fixed: Helen:/tmp alex$ cat ap.py def ap(): egold = 0 while egold 10: if test(): ego1d = egold + 1 Helen:/tmp alex$ pychecker ap.py Processing ap... Warnings... ap.py:4: No global (test) found ap.py:5: Local variable (ego1d) not used Helen:/tmp alex$ If you're so typo-prone and averse to unittests that you consider this kind of issue to be a serious problem, just use pychecker and get informed about any such typo, just as above. Incessant whining about the non-existent advantages of declarations, rather than the simple use of tools that can diagnose such spelling mistakes without any need for declarations, would qualify you as a troll even if you didn't have a long history of trolling this group... Names do get misspelled and sometimes that misspelling is hard to spot. It's totally trivial, of course, as shown above, and there is no need to pervert and distort the language for the purpose, as you, troll, have kept whining about for years. I'm partial to pychecker -- that's what we use at Google, and we also, incidentally, recently had the good fortune to hire Neal Norwitz, pychecker's author; but there are several other free tools that perform similar tasks, albeit with very different philosophy, such as Logilab's pylint...: Helen:/tmp alex$ pylint ap.py No config file found, using default configuration * Module ap W: 2: Bad indentation. Found 3 spaces, expected 4 W: 3: Bad indentation. Found 3 spaces, expected 4 W: 4: Bad indentation. Found 5 spaces, expected 8 W: 5: Bad indentation. Found 7 spaces, expected 12 C: 0: Too short name ap W: 0: Missing docstring W: 0: Missing required attribute __revision__ C: 1:ap: Too short name ap W: 1:ap: Missing docstring E: 4:ap: Undefined variable 'test' W: 5:ap: Unused variable 'ego1d' [rest of long critique of ap.py snipped] Again, unused variables (typos...) get easily diagnosed without any need for declarations. (Similar tools, of course, apply to languages requiring declaration, to diagnose a variable that's declared but unused, which is a very bad code smell typical of such languages). Of course, pylint is about enforcing all sort of code rules, such as, by default, indentation by multiples of 4 spaces, name length, docstrings, and so on; while pychecker is much simpler and more narrowly aimed at diagnosing likely mistakes and serious code smells. But, with either tool or any of many others, there is no need at all for declarations in order to catch typos (of course, unittests are still a VERY good idea -- catching all typos and even coding rules violations is NO guarantee that your code is any good, testing is A MUST). It would give the programmer a false sense of security since they 'know' all their misspellings are caught by the compiler. It would not be a substitute for run-time testing. I don't think anyone with a little bit of experience will be so naive. Heh, right. After all, _I_, for example, cannot have even a little bit of experience -- after all, I've been programming for just 30 years (starting with my freshman year in university), and anyway all I have to show for that is a couple of best-selling books, and a stellar career culminating (so far) with my present job as Uber Technical Lead for Google, Inc, right here in Silicon Valley... no doubt Google's reaching over the Atlantic to come hire me from Italy, and the US government's decision to grant me a visa under the O-1 category (for Aliens with Outstanding Skills), were mere oversights on their part that, obviously, I cannot have even a little bit of experience, given that I (like great authors such as Bruce Eckel and Robert Martin) entirely agree with the opinion you deem so naive... that any automatic catching of misspellings can never be a substitute for unit-testing! Ah well -- my good old iBook's settings had killfiles for newsreaders, with not many entries, but yours, Antoon, quite prominent and permanent; unfortunately, that beautiful little iBook was stolen (http://www.papd.org/press_releases/8_17_05_fix_macs_211.html), so I got myself a brand new one (I would deem it incorrect to use for personal purposes the nice 15 Powerbook that Google assigned me), and it takes some time to reconstruct all the settings. But, I gotta get started sometime -- so, welcome, o troll, as the very first entry in my brand-new killfile. In other words: *PLONK*, troll!-) Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
[EMAIL PROTECTED] (Alex Martelli) writes: ap.py:4: No global (test) found ap.py:5: Local variable (ego1d) not used Helen:/tmp alex$ If you're so typo-prone and averse to unittests that you consider this kind of issue to be a serious problem, just use pychecker and get informed about any such typo, just as above. That's very helpful, but why isn't it built into Python? -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
On 5 Oct 2005 09:27:04 GMT, Duncan Booth [EMAIL PROTECTED] wrote: Antoon Pardon wrote: It also is one possibility to implement writable closures. One could for instace have a 'declare' have the effect that if on a more inner scope such a declared variable is (re)bound it will rebind the declared variable instead of binding a local name. That is one possibility, but I think that it would be better to use a keyword at the point of the assigment to indicate assignment to an outer scope. This fits with the way 'global' works: you declare at (or near) the assignment that it is going to a global variable, not in some far away part of the code, so the global nature of the assignment is clearly visible. The 'global' keyword itself would be much improved if it appeared on the same line as the assignment rather than as a separate declaration. e.g. something like: var1 = 0 def f(): var2 = 0 def g(): outer var2 = 1 # Assign to outer variable global var1 = 1 # Assign to global IMO you don't really need all that cruft most of the time. E.g., what if ':=' meant 'assign to variable wherever it is (and it must exist), searching according to normal variable resolution order (fresh coinage, vro for short ;-), starting with local, then lexically enclosing and so forth out to module global (but not to builtins).' If you wanted to assign/rebind past a local var shadowing an enclosing variable var, you'd have to use e.g. vro(1).var = expr instead of var := expr. Sort of analogous to type(self).mro()[1].method(self, ...) Hm, vro(1).__dict__['var'] = expr could conceivably force binding at the vro(1) scope specifically, and not search outwards. But for that there would be optimization issues I think, since allowing an arbitrary binding would force a real dict creation on the fly to hold the the new name slot. BTW, if/when we can push a new namespace on top of the vro stack with a 'with namespace: ...' or such, vro(0) would still be at the top, and vro(1) will be the local before the with, and := can still be sugar for find-and-rebind. Using := and not finding something to rebind would be a NameError. Ditto for vro(n).nonexistent_name_at_level_n_or_outwards. vro(-1) could refer global module scope and vro(-2) go inwards towards local scope at vro(0). So vro(-1).gvar=expr would give you the effect of globals()['gvar']=expr with a pre-existence check. The pre-existence requirement would effectively be a kind of declaration requirement for the var := expr usage, and an initialization to a particular type could enhance inference. Especially if you could have a decorator for statements in general, not just def's, and you could then have a sticky-types decoration that would say certain bindings may be inferred to stick to their initial binding's object's type. Rambling uncontrollably ;-) My .02USD ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-06, Bengt Richter schreef [EMAIL PROTECTED]: On 5 Oct 2005 09:27:04 GMT, Duncan Booth [EMAIL PROTECTED] wrote: Antoon Pardon wrote: It also is one possibility to implement writable closures. One could for instace have a 'declare' have the effect that if on a more inner scope such a declared variable is (re)bound it will rebind the declared variable instead of binding a local name. That is one possibility, but I think that it would be better to use a keyword at the point of the assigment to indicate assignment to an outer scope. This fits with the way 'global' works: you declare at (or near) the assignment that it is going to a global variable, not in some far away part of the code, so the global nature of the assignment is clearly visible. The 'global' keyword itself would be much improved if it appeared on the same line as the assignment rather than as a separate declaration. e.g. something like: var1 = 0 def f(): var2 = 0 def g(): outer var2 = 1 # Assign to outer variable global var1 = 1 # Assign to global IMO you don't really need all that cruft most of the time. E.g., what if ':=' meant 'assign to variable wherever it is (and it must exist), searching according to normal variable resolution order (fresh coinage, vro for short ;-), starting with local, then lexically enclosing and so forth out to module global (but not to builtins).' Just some ideas about this 1) Would it be usefull to make ':=' an expression instead if a statement? I think the most important reason that the assignment is a statement and not an expression would apply less here because '==' is less easy to turn into ':=' by mistake than into = Even if people though that kind of bug was still too easy 2) What if we reversed the operation. Instead of var := expression, we write expression =: var. IMO this would make it almost impossible to write an assignment by mistake in a conditional when you meant to test for equality. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-05, Brian Quinlan schreef [EMAIL PROTECTED]:
Paul Rubin wrote:
Brian Quinlan [EMAIL PROTECTED] writes:
Have those of you who think that the lack of required declarations in
Python is a huge weakness given any thought to the impact that adding
them would have on the rest of the language? I can't imagine how any
language with required declarations could even remotely resemble
Python.
Python already has a global declaration;
Which is evaluated at runtime, does not require that the actual global
variable be pre-existing, and does not create the global variable if not
actually assigned. I think that is pretty different than your proposal
semantics.
how does it de-Pythonize the language if there's also a local
declaration and an option to flag any variable that's not declared as
one or the other?
Your making this feature optional contradicts the subject of this
thread i.e. declarations being necessary. But, continuing with your
declaration thought experiment, how are you planning on actually adding
optional useful type declarations to Python e.g. could you please
rewrite this (trivial) snippet using your proposed syntax/semantics?
from xml.dom import *
def do_add(x, y):
return '%s://%s' % (x, y)
def do_something(node):
if node.namespace == XML_NAMESPACE:
return do_add('http://', node.namespace)
elif node.namespace == ...
...
IMO your variable are already mostly declared. The x and y in
the do_add is kind of a declarartion for the parameters x and
y.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
On Wed, 05 Oct 2005 11:10:58 GMT, Ron Adam [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
Op 2005-10-04, Ron Adam schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
And lo, one multi-billion dollar Mars lander starts braking either too
early or too late. Result: a new crater on Mars, named after the NASA
employee who thought the compiler would catch errors.
Using (unit)tests will not guarantee that your programs is error free.
So if sooner or later a (unit)tested program causes a problem, will you
then argue that we should abondon tests, because tests won't catch
all errors.
Maybe you need to specify what kind of errors you want to catch.
Different types of errors require different approaches.
I want to catch all errors of course.
Yes, of course, and so do other programmers. What I mean is to try and
break it down into specific instances and then see what the best
approach is for each one is.
When I first started leaning Python I looked for these features as well,
but after a while my programming style changed and I don't depend on
types and names to check my data near as much now. But instead write
better organized code and data structures with more explicit value
checks where I need them.
My concern now is having reusable code and modules I can depend on. And
also separating my data and data management operations from the user
interface. Having functions and names that don't care what type the
objects are, makes doing this separation easier.
Another situation where typeless names are useful is routines that
explicitly check the type, then depending on the type does different
things. For example if you have a list with a lot of different type
objects stored in it, you can sort the contents into sublists by type.
Looking at it from a different direction, how about adding a keyword to
say, from this point on, in this local name space, disallow new
names. Then you can do...
def few(x,y):
a = 'a'
b = 'b'
i = j = k = l = None
no_new_names
# raise an error after here if a new name is used.
...
for I in range(10): -- error
...
This is more suitable to Pythons style than declaring types or variables
I think. Add to this explicit name-object locking to implement
constants and I think you would have most of the features you want.
You can do that now with a decorator, if you are willing to assign something
to no_new_names (so it won't give you a name error if it doesn't exist). E.g.,
def nnn(f):
... names = f.func_code.co_names
... assert 'no_new_names' not in names or names[-1]=='no_new_names', 'Bad
name:%r'%names[-1]
... return f
...
@nnn
... def few(x,y):
... a = 'a'
... b = 'b'
... i = j = k = l = None
... no_new_names=None
... for i in range(10): print i,
...
Traceback (most recent call last):
File stdin, line 1, in ?
File stdin, line 3, in nnn
AssertionError: Bad name:'range'
@nnn
... def few(x,y):
... a = 'a'
... b = 'b'
... i = j = k = l = None
... no_new_names=None
... return a,b,i,j,k,l
...
few(123,456)
('a', 'b', None, None, None, None)
No guarantees, since this depends on the unguaranteed order of
f.func_code.co_names ;-)
so...
no_new_names # limit any new names
lock_name name # lock a name to it's current object
That last one you could probably do with a decorator that imports dis and
checks the disassembly (or does the equivalent check of the byte code) of f
for STORE_FASTs directed to particular names after the lock_name name
declaration,
which you would have to spell as a legal dummy statement like
lock_name = 'name'
or perhaps better, indicating a locked assignment e.g. to x by
x = lock_name = expr # lock_name is dummy target to notice in disassembly,
to lock x from there on
Since names are stored in dictionaries, a dictionary attribute to
disallow/allow new keys, and a way to set individual elements in a
dictionary to read only would be needed. Once you can do that and it
proves useful, then maybe you can propose it as a language feature.
I would want to explore how to compose functionality with existing elements
before introducing either new elements or new syntax. E.g., the dictionaries
used for instance attribute names and values already exist, and you can already
build all kinds of restrictions on the use of attribute names via properties
and descriptors of other kinds and via __getattribute__ etc.
These might also be checked for in the compile stage and would probably
be better as it wouldn't cause any slow down in the code or need a new
dictionary type.
Although note that the nnn decorator above does its checking at run time,
when the decorator is executed just after the _def_ is anonymously _executed_
to create the function nnn gets handed to check or modify before what it
returns is bound to the def function name. ;-)
An
Re: no variable or argument declarations are necessary.
Op 2005-10-05, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: They also relieve a burden from the run-time, since all variables are declared, the runtime doesn't has to check whether or not a variable is accesible, it knows it is. Not in a dynamic language. Python lets you delete variables at run time, so the only way to know if a variable exists at a specific point during the execution of an arbitrary program is to execute the program to that point. It is not perfect, that doesn't mean it can't help. How much code deletes variables. It's not perfect means it may not help. Depends on the cost of being wrong - which means we need to see how things would be different if the code was assuming that a variable existed, and then turned out to be wrong. Actually, I'd be interested in knowing how you would improve the current CPython implementation with knowledge about whether or not a variable existed. The current implementation just does a dictionary lookup on the name. The lookup fails if the variable doesn't exist. So checking on the existence of the variable is a byproduct of finding the value of the variable. So even if it was perfect, it wouldn't help. Yes it would. A function with a declare statement could work as the __slots__ attribute in a class. AFAIU each variable would then internally be associated with a number and the dictionary would be replace by a list. Finding the value of the variable would just be indexing this table. And if you provide type information with the declaration, more efficient code can be produced. Only in a few cases. Type inferencing is a well-understood technology, and will produce code as efficient as a statically type language in most cases. I thought it was more than in a few. Without some type information from the coder, I don't see how you can infer type from library code. There's nothing special about library code. It can be anaylyzed just like any other code. Not necessarily, library code may not come with source, so there is little to be analyzed then. Except declarations don't add functionality to the language. They effect the programing process. It would be one way to get writable closures in the language. That is added functionality. Except just adding declerations doesn't give you that. You have to change the language so that undeclared variables are looked for up the scope. They already are. The only exception being when the variable is (re)bound. This can give you 'surprising' results like the following. a = [] b = [] def f(): a[:] = range(10) b = range(10) f() print a print b which will gibe the following result. [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [] And we have conflicting claims about whether that's a good effect or not, all apparently based on nothing solider than personal experience. Which means the arguments are just personal preferences. Whether the good effect is good enough is certainly open for debate. But the opponents seem to argue that since it is no absolute guarantee, it is next to useless. Well I can't agree with that kind of argument and will argue against it. You're not reading the opponents arguments carefully enough. The argument is that the benefit from type declerations is overstated, and in reality doesn't outweigh the cost of declerations. That may be there intend, but often enough I see arguments that boil down to the fact that declarations won't solve a particular problem completely as if that settles it. Dynamic languages tend to express a much wider range of programming paradigms than languages that are designed to be statically compiled. Some of these paradigms do away with - or relegate to the level of ugly performance hack - features that someone only experienced with something like Pascal would consider essential. Assignment statements are a good example of that. I think we should get rid of thinking about a language as static or dynamic. It is not the language which should determine a static or dynamic approach, it is the problem you are trying to solve. And if the coder thinks that a static approach is best for his problem, why shouldn't he solve it that way. Except that languages *are* static or dynamic. Not in the way a lot of people seem to think here. Adding declarations doesn't need to take away any dynamism from the language. They have different features, and different behaviors. Rather than tilting at the windmill of making a dynamic language suitable for static approaches, it's better to simply use the appropriate tool for the job. Especially if those changes make the tool *less* suitable for a dynamic approach. They don't. That seems to be the big fear after a lot of resistance but IMO it is unfounded. If I write a module that only makes sense with floating point numbers, declaring those variables as floats and allowing the compiler to generate code optimised for floating point numbers, will in no way
Re: no variable or argument declarations are necessary.
Op 2005-10-05, Diez B. Roggisch schreef [EMAIL PROTECTED]: This is naive. Testing doesn't guarantee anything. If this is what you think about testing, then testing gives you a false impression of security. Maybe we should drop testing. Typechecking is done by a reduced lamda calculus (System F, which is ML-Style), whereas testing has the full power of a turing complete language. So _if_ one has to be dropped, it would certainly be typechecking. Sure, But allow me this silly analogy. Going out on a full test-drive will also reveal your tires are flat. So if you one has to be dropped, a full test drive or a tire check it would certainly be the tired check. But IMO the tire check is still usefull. Additionally, testing gives you the added benefit of actually using your decelared APIs - which serves documentation purposes as well as securing your design decisions, as you might discover bad design while actually writing testcases. Hey, I'm all for testing. I never suggested testing should be dropped for declarations Besides that, the false warm feeling of security a successful compilation run has given many developers made them check untested and actually broken code into the VCS. I've seen that _very_ often! And the _only_ thinng that prevents us from doing so is to enforce tests. I wonder how experienced are these programmers? I know I had this feeling when I started at the univeristy, but before I left I already wrote my programs in rather small pieces that were tested before moving on. But these are more naturally done in python (or similar languages) as every programmer knows unless the program run sucsessfully, I can't say anything about it than in a statically typed language where the programmer argues hey, it compiled, it should work! Again I do have to wonder about how experienced these programmers are. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon wrote:
from xml.dom import *
def do_add(x, y):
return '%s://%s' % (x, y)
def do_something(node):
if node.namespace == XML_NAMESPACE:
return do_add('http://', node.namespace)
elif node.namespace == ...
...
IMO your variable are already mostly declared. The x and y in
the do_add is kind of a declarartion for the parameters x and
y.
I think you missed his point, though I'm not surprised since unless you
are familiar with the internals of the xml package it isn't obvious just
how complex this situation is.
The value XML_NAMESPACE was imported from xml.dom, but the xml package is
kind of weird. XML_NAMESPACE defined both in xml.dom and in the
_xmlplus.dom package. The _xmlplus package is conditionally imported by the
xml package, and completely replaces it, but only if _xmlplus is present
and at least version 0.8.4 (older versions are ignored).
This is precisely the kind of flexibility which gives Python a lot of its
power, but it means that you cannot tell without running the code which
package actually provides xml.dom.
Of course, I would expect that if you enforced strict variable declarations
you would also disallow 'from x import *', but you still cannot tell until
runtime whether an particular module will supply a particular variable, not
what type it is.
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Brian Quinlan [EMAIL PROTECTED] writes: OK. The Python compiler would check that the name is declared but it would not check that it is defined before use? So this would be acceptable: def foo(): local x return x Come on, you are asking silly questions. Any reasonable C compiler would flag something like that and Python (with the flag set) should do the same. If you want to ask substantive questions, that's fine, but stop wasting our time with silly stuff. I'm not trying to be silly. I am trying to get a handle on the semantics that you are proposing. So we now have two requirements for the new declaration syntax (please let me know if I'm wrong): o the variable must be declared o the variable must be assigned I would assume that you would make it so that assignment and delaration happen as part of the same statement? If type checking is implemented then the stdlib should be updated to add declarations for public symbols. If not, the compiler would flag the undeclared symbol. You could always declare it to be of type 'object'. Fair enough. try: unicode except NameError: XML_NAMESPACEstr = ... else: XML_NAMESPACEunicode = u... This wouldn't be allowed. OK, that sucks. 2. the compiler does not have access to the names in other modules anyway You're being silly again. The compiler would examine the other module when it processes the import statement, just like it does now. Right now, the compiler DOES NOT examine the contents of the other modules. All it does is generate an IMPORT_NAME instruction which is evaluation during runtime. So are you proposing that the compiler now scan other modules during compilation? How would you find the class definition for the Node object at compile-time? By processing the xml.dom module when it's imported. Import happens at runtime (see above). But you seem to want compile-time type checking. Cheers, Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Duncan Booth [EMAIL PROTECTED] writes: The value XML_NAMESPACE was imported from xml.dom, but the xml package is kind of weird. XML_NAMESPACE defined both in xml.dom and in the _xmlplus.dom package. The _xmlplus package is conditionally imported by the xml package, and completely replaces it, but only if _xmlplus is present and at least version 0.8.4 (older versions are ignored). This is precisely the kind of flexibility which gives Python a lot of its power, but it means that you cannot tell without running the code which package actually provides xml.dom. This sounds like the socket module, which is a total mess. Library code should not be written like that. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Brian Quinlan [EMAIL PROTECTED] writes: I'm not trying to be silly. I am trying to get a handle on the semantics that you are proposing. So we now have two requirements for the new declaration syntax (please let me know if I'm wrong): o the variable must be declared o the variable must be assigned These would both be errors that the compiler could and should check for, if declaration checking is enabled. However, they would not be syntax errors. I would assume that you would make it so that assignment and delaration happen as part of the same statement? Sure, why not. Right now, the compiler DOES NOT examine the contents of the other modules. All it does is generate an IMPORT_NAME instruction which is evaluation during runtime. In that case the other module gets compiled when the IMPORT_NAME instruction is executed. That says that compile time and runtime are really the same thing in the current system. So are you proposing that the compiler now scan other modules during compilation? Yeah, maybe some optimization is possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Sure, But allow me this silly analogy. Going out on a full test-drive will also reveal your tires are flat. So if you one has to be dropped, a full test drive or a tire check it would certainly be the tired check. But IMO the tire check is still usefull. But you could write it as test - including not only a look (which resembles the limited capabilities of typechecking), but testing the air pressure, looking at the tyre type and see that it won't match the rainy conditions... Hey, I'm all for testing. I never suggested testing should be dropped for declarations The testing is IMHO more valuable than typechecking. The latter one actually _limits_ me. See e.g. the java IO-Api for a very bloated way of what comes very naturally with python. Duck-typing at it's best. The only reason I see typechecking is good for is optimization. But that is not the problem with JAVA/.NET anyway. And could possibly be done with psyco. I wonder how experienced are these programmers? I know I had this feeling when I started at the univeristy, but before I left I already wrote my programs in rather small pieces that were tested before moving on. snip Again I do have to wonder about how experienced these programmers are. Well - surely they aren't. But that is beyond your control - you can't just stomp into a company and declare your own superiority and force others your way. I was astonished to hear that even MS just recently adopted test-driven development for their upcoming windows vista. And they are commonly seen as sort of whiz-kid hiring hi-class company, certified CMM Levelo 6 and so on The discussion is somewhat moot - typechecking is not nonsense. But matter of factly, _no_ programm runs without testing. And developing a good testing culture is cruicial. Where OTH a lot of large and successful projects exist (namely the python ones, amongst others..) that show that testing alone without typechecking seems to be good enough. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]: Sure, But allow me this silly analogy. Going out on a full test-drive will also reveal your tires are flat. So if you one has to be dropped, a full test drive or a tire check it would certainly be the tired check. But IMO the tire check is still usefull. But you could write it as test - including not only a look (which resembles the limited capabilities of typechecking), but testing the air pressure, looking at the tyre type and see that it won't match the rainy conditions... Hey, I'm all for testing. I never suggested testing should be dropped for declarations The testing is IMHO more valuable than typechecking. The latter one actually _limits_ me. See e.g. the java IO-Api for a very bloated way of what comes very naturally with python. Duck-typing at it's best. But typechecking doesn't has to be java like. I can't help but feel that a lot of people have specific typechecking systems in mind and then conclude that the limits of such a symtem are inherent in typechecking itself. IMO a good type system doesn't need to limit python in any way. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Right now, the compiler DOES NOT examine the contents of the other modules. All it does is generate an IMPORT_NAME instruction which is evaluation during runtime. In that case the other module gets compiled when the IMPORT_NAME instruction is executed. If compilation is required to complete the import (i.e. the module has not already been imported and the module does not already have a compiled byte-code file) then that is the same. That says that compile time and runtime are really the same thing in the current system. I would say that they are separate systems but that the compilation system is available to the runtime (but not vise-versa). In any case, the important thing is that the operation of these systems has an impact on the optional declaration proposal being discussed. The thing that I'm trying to understand is how the proponents of such a system would change Python to accomodate it. No one has been able to articulate that with any decree of specifity (Just do what Perl does). Also, these (poorly-defined) proposals have revealed a lack of understanding of Python's existing workings (The compiler would examine the other module when it processes the import statement, just like it does now.). Without a clear idea of the nature of the proposal, it is impossible to assess it's costs and benefits. So could a proponent of optional declarations please provide a more clear proposal? Cheers, Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
I can't help but feel that a lot of people have specific typechecking systems in mind and then conclude that the limits of such a symtem are inherent in typechecking itself. I've been writing a type-checker for my diploma thesis for a functionnal programmming language. And it _is_ limited. The very subject of my work was to explore extended type-checking methods (so called multi-level-specifications),, which can be shwon to be NP-hard problems. Which naturally limits the domains they can be used to. IMO a good type system doesn't need to limit python in any way. It has to. certainly. Take alone the list implementation - while typesystems as ML allow for generics (with much less typing overhead than JAVA), the list is always homogenous. Which python's aren't - and that a great thing(tm), even though ususally the contents of a list share some common behaviour. And that exactly is the key point here: in a statically typed world, that common behaviour must have been extracted and made explicit. Which is the cause for that notorious java io API. And, to extend the argument to ML-type type-checking, there you need a disjoint union of the possible types - _beforehand_, and the code dealing with it has to be aware of it. In python OTH, I just pass objects I like into the list - if they behave, fine. DIez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]: I can't help but feel that a lot of people have specific typechecking systems in mind and then conclude that the limits of such a symtem are inherent in typechecking itself. I've been writing a type-checker for my diploma thesis for a functionnal programmming language. And it _is_ limited. The very subject of my work was to explore extended type-checking methods (so called multi-level-specifications),, which can be shwon to be NP-hard problems. Which naturally limits the domains they can be used to. IMO a good type system doesn't need to limit python in any way. It has to. certainly. Take alone the list implementation - while typesystems as ML allow for generics (with much less typing overhead than JAVA), the list is always homogenous. Which python's aren't - and that a great thing(tm), Suppose we have a typesystem which has the type ANY, which would mean such an object could be any type. You could then have homogenous lists in the sense that all elements should be of the same declared type and at the same time mix all kind of type in a particular list, just as python does. So how would this limit python. even though ususally the contents of a list share some common behaviour. And that exactly is the key point here: in a statically typed world, that common behaviour must have been extracted and made explicit. Would my suggestion be classified as a statically typed world? Which is the cause for that notorious java io API. And, to extend the argument to ML-type type-checking, there you need a disjoint union of the possible types - _beforehand_, and the code dealing with it has to be aware of it. In python OTH, I just pass objects I like into the list - if they behave, fine. But now we are no longer talking about how typechecking would limit the language but about convenience for the user. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Suppose we have a typesystem which has the type ANY, which would mean such an object could be any type. You could then have homogenous lists in the sense that all elements should be of the same declared type and at the same time mix all kind of type in a particular list, just as python does. The you have JAVA Object or C void*. Which cause all kinds of runtime troubles because they essentially circumvene the typechecking! So how would this limit python. The limitation is that in static languages I must _know_ what type to cast such an ANY, before calling anything on it. Otherwise its useless. even though ususally the contents of a list share some common behaviour. And that exactly is the key point here: in a statically typed world, that common behaviour must have been extracted and made explicit. Would my suggestion be classified as a statically typed world? See above. Which is the cause for that notorious java io API. And, to extend the argument to ML-type type-checking, there you need a disjoint union of the possible types - _beforehand_, and the code dealing with it has to be aware of it. In python OTH, I just pass objects I like into the list - if they behave, fine. But now we are no longer talking about how typechecking would limit the language but about convenience for the user. That's dialectics. Limits in the language limit the user and make things inconvenient. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Mike Meyer a écrit : Antoon Pardon [EMAIL PROTECTED] writes: Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]: On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote: Declarations also allow easier writable closures. Since the declaration happens at a certain scope, the run time can easily find the correct scope when a variable is rebound. If it happens at runtime, then you can do it without declarations: they're gone by then. Come to think of it, most functional languages - which are the languages that make the heaviest use of closures - don't require variable declarations. Well, can you give a single example of such language ? Because all the functionnal language I know but one do need variable declaration : lisp, scheme, ocaml, haskell do need variable declaration ! Erlang do not ... [...] Only in a few cases. Type inferencing is a well-understood technology, and will produce code as efficient as a statically type language in most cases. Type inferencing only works for statically typed languages AFAIK ! In a dynamically typed languages, typing a variable is simply impossible as any function may return a value of any type ! I think language matters shouldn't be setlled by personal preferences. I have to agree with that. For whether or not a feature should be included, there should either be a solid reason dealing with the functionality of the language - meaning you should have a set of use cases showing what a feature enables in the language that couldn't be done at all, or could only be done clumsily, without the feature. Wrong argument ... with that kind of things, you would just stick with plain Turing machine ... every single computation can be done with it ! Except declarations don't add functionality to the language. They effect the programing process. And we have conflicting claims about whether that's a good effect or not, all apparently based on nothing solider than personal experience. Which means the arguments are just personal preferences. Well, so why not *allow* for variable declaration ? Languages like Perl does that successfully ... you don't like : you don't do ! you like : you do ! A simple option at the beginning of the file tell the compilor if variable declaration is mandatory or not ! Until someone does the research to provide hard evidence one way or another, that's all we've got to work with. Which means that languages should exist both with and with those features, and if one sides experiences generalize to the population at large, they alternative languages will die out. Which hasn't happened yet. But we should decide what language features are usefull and which are not by what some individual can or can't live without. Um - that's just personal preference (though I may have misparsed your sentence). What one person can't live without, another may not be able to live with. All that means is that they aren't likely to be happy with the same programming language. Which is fine - just as no programming language can do everything, no programming language can please everyone. Antoon, at a guess I'd say that Python is the first time you've encountered a dynamnic language. Being horrified at not having variable declarations, which is a standard feature of such languages dating back to the 1950s, is one such indication. Dynamic language and variable declaration are non-related issues ! You can have statically-typed language without variable declaration (i.e. BASIC) and dynamically-typed language with (i.e. Lisp) ! Please, when you says something about languages, at least give 1 name of language asserting what you're saying ! Dynamic languages tend to express a much wider range of programming paradigms than languages that are designed to be statically compiled. Some of these paradigms do away with - or relegate to the level of ugly performance hack - features that someone only experienced with something like Pascal would consider essential. Assignment statements are a good example of that. Well, could you be more specific once more ? I can't that many paradigm only available on dynamically typed languages ... beside duck-typing (which is basically a synonym for dynamically-typed) Given these kinds of differences, prior experience is *not* a valid reason for thinking that some difference must be wrong. Until you have experience with the language in question, you can't really decide that some feature being missing is intolerable. You're in the same position as the guy who told me that a language without a goto would be unusable based on his experience with old BASIC, FORTRAN IV and assembler. After more than two years of Python programming, I still fill the need for variable declarations. It would remove tons of bugs for little works and would also clarify the scope of any single variable. Pick one of the many languages that don't require declarations. Try writing a code in them,
Re: no variable or argument declarations are necessary.
Pierre Barbier de Reuille [EMAIL PROTECTED] writes: Mike Meyer a écrit : Antoon Pardon [EMAIL PROTECTED] writes: Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]: On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote: Declarations also allow easier writable closures. Since the declaration happens at a certain scope, the run time can easily find the correct scope when a variable is rebound. If it happens at runtime, then you can do it without declarations: they're gone by then. Come to think of it, most functional languages - which are the languages that make the heaviest use of closures - don't require variable declarations. Well, can you give a single example of such language ? Because all the functionnal language I know but one do need variable declaration : lisp, scheme, ocaml, haskell do need variable declaration ! Erlang do not ... Scheme and lisp don't need variable declerations. Last time I looked, Schemd didn't even *allow* variable declerations. Only in a few cases. Type inferencing is a well-understood technology, and will produce code as efficient as a statically type language in most cases. Type inferencing only works for statically typed languages AFAIK ! In a dynamically typed languages, typing a variable is simply impossible as any function may return a value of any type ! I think we're using different definitions of statically typed here. A language that is statically typed doesn't *need* type inferencing - the types are all declared! Type determines the thypes by inferenceing them from an examination of the program. So, for instance, it can determine that this function: def foo(): return 1 Won't ever return anything but an integer. I think language matters shouldn't be setlled by personal preferences. I have to agree with that. For whether or not a feature should be included, there should either be a solid reason dealing with the functionality of the language - meaning you should have a set of use cases showing what a feature enables in the language that couldn't be done at all, or could only be done clumsily, without the feature. Wrong argument ... with that kind of things, you would just stick with plain Turing machine ... every single computation can be done with it ! Computation is is not the same thing as Functionality. If you think otherwise, show me how to declare an object with a Turing machine. And there's also the issue of clumsily. Turing machines are clumsy to program in. Except declarations don't add functionality to the language. They effect the programing process. And we have conflicting claims about whether that's a good effect or not, all apparently based on nothing solider than personal experience. Which means the arguments are just personal preferences. Well, so why not *allow* for variable declaration ? Languages like Perl does that successfully ... you don't like : you don't do ! you like : you do ! A simple option at the beginning of the file tell the compilor if variable declaration is mandatory or not ! Perl is a red herring. Unless it's changed radically since I last looked, undeclared variables in Perl have dynamic scope, not lexical scope. While dynamically scoped variables are a powerful feature, and there have been proposals to add them to Python, having them be the default is just *wrong*. If I were writing in Perl, I'd want everything declared just to avoid that. Of course, if Python behaved that way, I'd do what I did with Perl, and change languages. Antoon, at a guess I'd say that Python is the first time you've encountered a dynamnic language. Being horrified at not having variable declarations, which is a standard feature of such languages dating back to the 1950s, is one such indication. Dynamic language and variable declaration are non-related issues ! You can have statically-typed language without variable declaration (i.e. BASIC) and dynamically-typed language with (i.e. Lisp) ! Please, when you says something about languages, at least give 1 name of language asserting what you're saying ! Declerations and typing are *also* non-related issues. See Perl. Also see the subject line. Dynamic languages tend to express a much wider range of programming paradigms than languages that are designed to be statically compiled. Some of these paradigms do away with - or relegate to the level of ugly performance hack - features that someone only experienced with something like Pascal would consider essential. Assignment statements are a good example of that. Well, could you be more specific once more ? I can't that many paradigm only available on dynamically typed languages ... beside duck-typing (which is basically a synonym for dynamically-typed) I said dynamic languages, *not* dynamically typed languages. They aren't the same thing. Dynamic languages let you create new functions, variables and attributes at run time. Python lets you delete them as well. This means that simle
Re: no variable or argument declarations are necessary.
Bengt Richter wrote:
On Wed, 05 Oct 2005 11:10:58 GMT, Ron Adam [EMAIL PROTECTED] wrote:
Looking at it from a different direction, how about adding a keyword to
say, from this point on, in this local name space, disallow new
names. Then you can do...
def few(x,y):
a = 'a'
b = 'b'
i = j = k = l = None
no_new_names
# raise an error after here if a new name is used.
...
for I in range(10): -- error
...
This is more suitable to Pythons style than declaring types or variables
I think. Add to this explicit name-object locking to implement
constants and I think you would have most of the features you want.
You can do that now with a decorator, if you are willing to assign something
to no_new_names (so it won't give you a name error if it doesn't exist). E.g.,
Works for me.
__lock_names__ = True
It's not too different than __name__ == '__main__'...
def nnn(f):
... names = f.func_code.co_names
... assert 'no_new_names' not in names or names[-1]=='no_new_names',
'Bad name:%r'%names[-1]
... return f
...
@nnn
... def few(x,y):
... a = 'a'
... b = 'b'
... i = j = k = l = None
... no_new_names=None
... for i in range(10): print i,
...
Traceback (most recent call last):
File stdin, line 1, in ?
File stdin, line 3, in nnn
AssertionError: Bad name:'range'
Hmm... To make it work this way, the globals and arguments need to have
local references.
@nnn
def few(x,y):
global range
range = range
x,y = x,y
a = 'a'
b = 'b'
i = j = k = l = None
L = 1
__no_new_names__ = True
L += 1
for i in range(x,y):
print I
@nnn
... def few(x,y):
... a = 'a'
... b = 'b'
... i = j = k = l = None
... no_new_names=None
... return a,b,i,j,k,l
...
few(123,456)
('a', 'b', None, None, None, None)
No guarantees, since this depends on the unguaranteed order of
f.func_code.co_names ;-)
I had the thought that collecting the names from the 'STORE FAST' lines
of dis.dis(f) would work nicely, but... dis.dis() doesn't return a
string like I expected, but prints the output as it goes. This seems
like it would be easy to fix and it would make the dis module more
useful. I'd like to be able to do...
D = dis.dis(f)
An alternate option to output the disassembly to a list of of tuples.
That would make analyzing the output really easy. ;-)
Something like...
good_names = []
nnnames = False
for line in dis.dislist(f):
if line[2] = 'SAVE_FAST':
if not nnnames:
if line[-1] = '(__no_new_names__)':
nnnames=True
continue
good_names.append(line[-1])
else:
assert line[-1]in good_names, 'Bad name:%r'% line[-1]
So, I wonder what kind of errors can be found by analyzing the disassembly?
so...
no_new_names # limit any new names
lock_name name # lock a name to it's current object
That last one you could probably do with a decorator that imports dis and
checks the disassembly (or does the equivalent check of the byte code) of f
for STORE_FASTs directed to particular names after the lock_name name
declaration,
which you would have to spell as a legal dummy statement like
lock_name = 'name'
or perhaps better, indicating a locked assignment e.g. to x by
x = lock_name = expr # lock_name is dummy target to notice in
disassembly, to lock x from there on
Using dis.dis it becomes two sequential 'STORE_FAST' operations. So add
(x) to the don't change list, and catch it on the next 'STORE_FAST' for
(x). ;-)
28 12 LOAD_GLOBAL 2 (True)
15 DUP_TOP
16 STORE_FAST 0 (x)
19 STORE_FAST 8 (__lock_name__)
Since names are stored in dictionaries, a dictionary attribute to
disallow/allow new keys, and a way to set individual elements in a
dictionary to read only would be needed. Once you can do that and it
proves useful, then maybe you can propose it as a language feature.
I would want to explore how to compose functionality with existing elements
before introducing either new elements or new syntax. E.g., the dictionaries
used for instance attribute names and values already exist, and you can
already
build all kinds of restrictions on the use of attribute names via properties
and descriptors of other kinds and via __getattribute__ etc.
That was more or less what I had in mind, but I think keeping things as
passive as possible is what is needed. One thought is to use this type
of thing along with __debug__.
if __debug__: __nnn__ = True
Wouldn't a debug block or suite be better than an if __debug__:? Just a
thought. Even if the -0 option is given the if __debug__: check is
still there. Which means you still need to comment it out if it's in an
Re: no variable or argument declarations are necessary.
Brian Quinlan [EMAIL PROTECTED] writes: Without a clear idea of the nature of the proposal, it is impossible to assess it's costs and benefits. So could a proponent of optional declarations please provide a more clear proposal? There is no proposal on the table. There's a discussion of how this stuff can work, and whether it's useful. As for how the compiler deals with imported modules, see for example Common Lisp or Haskell or ML--how do they do it? -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Ron Adam wrote: Is there a way to conditionally decorate? For example if __debug__ is True, but not if it's False? I think I've asked this question before. (?) the decorator is a callable, so you can simply do, say from somewhere import debugdecorator if not __debug__: debugdecorator = lambda x: x or def debugdecorator(func): if __debug__: ... else: return func etc. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Mike Meyer [EMAIL PROTECTED] writes:
I think we're using different definitions of statically typed
here. A language that is statically typed doesn't *need* type
inferencing - the types are all declared! Type determines the thypes
by inferenceing them from an examination of the program.
I thought static typing simply means the compiler knows the types of
all the expressions (whether through declarations or inference) so it
can do type checking at compile time:
So, for instance, it can determine that this function:
def foo():
return 1
Won't ever return anything but an integer.
Static typing in this case would mean that re.match('a.*b$', foo())
would get a compile time error, not a runtime error, since re.match
expects two string arguments. This can happen through type inference
w/o declarations.
Note apropos the private variable discussion that CPython can't
guarantee that foo() always returns an integer. Something might
change foo.func_code.co_code or something like that.
Maybe you're still writing code for a language with declerations? I
never felt that need. Then again, I came to Python from a language
that didn't require declerations: Scheme.
I've done a fair amount of Lisp programming and have found the lack of
compile-time type checking to cause about the same nuisance as in
Python. I also notice that the successors to the old-time Lisp/Scheme
communities seem to now be using languages like Haskell.
Well, in the end, I would really like an *option* at the beginning of a
module file requiring variable declaration for the module. It would
satisfy both the ones who want and the ones who don't want that ...
Nope. It would just change the argument from Python should have ...
to You should always use ... or Module foo should use
Perl has a feature like that right now, and it doesn't lead to many such
arguments.
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin http://[EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] writes:
I think we're using different definitions of statically typed
here. A language that is statically typed doesn't *need* type
inferencing - the types are all declared! Type determines the thypes
by inferenceing them from an examination of the program.
I thought static typing simply means the compiler knows the types of
all the expressions (whether through declarations or inference) so it
can do type checking at compile time:
So, for instance, it can determine that this function:
def foo():
return 1
Won't ever return anything but an integer.
Static typing in this case would mean that re.match('a.*b$', foo())
would get a compile time error, not a runtime error, since re.match
expects two string arguments. This can happen through type inference
w/o declarations.
Except for two problems:
One you noted:
Note apropos the private variable discussion that CPython can't
guarantee that foo() always returns an integer. Something might
change foo.func_code.co_code or something like that.
Two is that dynamic binding means that foo may not refer to the above
function when you get there at run time.
Maybe you're still writing code for a language with declerations? I
never felt that need. Then again, I came to Python from a language
that didn't require declerations: Scheme.
I've done a fair amount of Lisp programming and have found the lack of
compile-time type checking to cause about the same nuisance as in
Python.
So have I - basically none at all.
Well, in the end, I would really like an *option* at the beginning of a
module file requiring variable declaration for the module. It would
satisfy both the ones who want and the ones who don't want that ...
Nope. It would just change the argument from Python should have ...
to You should always use ... or Module foo should use
Perl has a feature like that right now, and it doesn't lead to many such
arguments.
As noted elsewhere, Perl isn't a good comparison. You don't simply say
This variable exists, you say this variable is local to this
function. Undeclared variables are dynamically bound, which means you
can get lots of non-obvious, nasty bugs that won't be caught by unit
testing. Making all your variables lexically bound (unless you really
need a dynamically bound variable) is a good idea. But that's already
true in Python.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Fredrik Lundh wrote: Ron Adam wrote: Is there a way to conditionally decorate? For example if __debug__ is True, but not if it's False? I think I've asked this question before. (?) the decorator is a callable, so you can simply do, say from somewhere import debugdecorator if not __debug__: debugdecorator = lambda x: x Ah... thanks. I suppose after(if) lambda is removed it would need to be. def nulldecorator(f): return f if not __debug__: debugdecorator = nulldecorator or def debugdecorator(func): if __debug__: ... else: return func etc. This one came to mind right after I posted. :-) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Dans l'article [EMAIL PROTECTED], Mike Meyer a écrit : Pierre Barbier de Reuille [EMAIL PROTECTED] writes: Mike Meyer a écrit : Antoon Pardon [EMAIL PROTECTED] writes: Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]: On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote: Declarations also allow easier writable closures. Since the declaration happens at a certain scope, the run time can easily find the correct scope when a variable is rebound. If it happens at runtime, then you can do it without declarations: they're gone by then. Come to think of it, most functional languages - which are the languages that make the heaviest use of closures - don't require variable declarations. Well, can you give a single example of such language ? Because all the functionnal language I know but one do need variable declaration : lisp, scheme, ocaml, haskell do need variable declaration ! Erlang do not ... Scheme and lisp don't need variable declerations. Last time I looked, Schemd didn't even *allow* variable declerations. When you want local variable in lisp you do : (let ((a 3)) (+ a 1)) For global variable you may do: (defparameter *a* 4) or: (defvar *a* 4) However, either way, variable assignment is done via : (setf *a* 5) (setf a 10) This is what I call variable declaration as you have different way to declare global variables and to assign them ... So the two operations are well defined and different. And here there is a difference between static language and declarative ones ... Lisp is a dynamic language that needs variable declarations. Only in a few cases. Type inferencing is a well-understood technology, and will produce code as efficient as a statically type language in most cases. Type inferencing only works for statically typed languages AFAIK ! In a dynamically typed languages, typing a variable is simply impossible as any function may return a value of any type ! I think we're using different definitions of statically typed here. A language that is statically typed doesn't *need* type inferencing - the types are all declared! Type determines the thypes by inferenceing them from an examination of the program. So, for instance, it can determine that this function: Well, indeed ... statically typed means only one thing : each *variable* has a *static* type, i.e. a type determined at compile time. Once again, OCaml and Haskell *are* statically typed but as they have type inference you don't *need* to explicitely type your functions / variables. However you *may* if you want ... def foo(): return 1 Won't ever return anything but an integer. I think language matters shouldn't be setlled by personal preferences. I have to agree with that. For whether or not a feature should be included, there should either be a solid reason dealing with the functionality of the language - meaning you should have a set of use cases showing what a feature enables in the language that couldn't be done at all, or could only be done clumsily, without the feature. Wrong argument ... with that kind of things, you would just stick with plain Turing machine ... every single computation can be done with it ! Computation is is not the same thing as Functionality. If you think otherwise, show me how to declare an object with a Turing machine. Well, that was bad spirit from me ;) My argument here wasn't serious in any mean ... And there's also the issue of clumsily. Turing machines are clumsy to program in. Except declarations don't add functionality to the language. They effect the programing process. And we have conflicting claims about whether that's a good effect or not, all apparently based on nothing solider than personal experience. Which means the arguments are just personal preferences. Well, so why not *allow* for variable declaration ? Languages like Perl does that successfully ... you don't like : you don't do ! you like : you do ! A simple option at the beginning of the file tell the compilor if variable declaration is mandatory or not ! Perl is a red herring. Unless it's changed radically since I last looked, undeclared variables in Perl have dynamic scope, not lexical scope. While dynamically scoped variables are a powerful feature, and there have been proposals to add them to Python, having them be the default is just *wrong*. If I were writing in Perl, I'd want everything declared just to avoid that. Of course, if Python behaved that way, I'd do what I did with Perl, and change languages. I never said to adopt the whole Perl variable semantic. I just pointed what I think is a good idea in Perl and that help (IMHO) precising what I intended ... Antoon, at a guess I'd say that Python is the first time you've encountered a dynamnic language. Being horrified at not having variable declarations, which is a standard feature of such languages dating back to the 1950s, is one such indication. Dynamic language and
Re: no variable or argument declarations are necessary.
Ron Adam wrote: Fredrik Lundh wrote: Ron Adam wrote: Is there a way to conditionally decorate? For example if __debug__ is True, but not if it's False? I think I've asked this question before. (?) the decorator is a callable, so you can simply do, say from somewhere import debugdecorator if not __debug__: debugdecorator = lambda x: x Ah... thanks. I suppose after(if) lambda is removed it would need to be. def nulldecorator(f): return f if not __debug__: debugdecorator = nulldecorator It would be easier to write if not __debug__: def debugdecorator(f): return f regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Barbier de Reuille [EMAIL PROTECTED] writes: Dans l'article [EMAIL PROTECTED], Mike Meyer a écrit : Pierre Barbier de Reuille [EMAIL PROTECTED] writes: Mike Meyer a écrit : Antoon Pardon [EMAIL PROTECTED] writes: Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]: On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote: Declarations also allow easier writable closures. Since the declaration happens at a certain scope, the run time can easily find the correct scope when a variable is rebound. If it happens at runtime, then you can do it without declarations: they're gone by then. Come to think of it, most functional languages - which are the languages that make the heaviest use of closures - don't require variable declarations. Well, can you give a single example of such language ? Because all the functionnal language I know but one do need variable declaration : lisp, scheme, ocaml, haskell do need variable declaration ! Erlang do not ... Scheme and lisp don't need variable declerations. Last time I looked, Schemd didn't even *allow* variable declerations. When you want local variable in lisp you do : (let ((a 3)) (+ a 1)) Excep that's not a decleration, that's a binding. That's identical to the Python fragment: a = 3 return a + 1 except for the creation of the new scope. Not a variable decleration in site. For global variable you may do: (defparameter *a* 4) or: (defvar *a* 4) That's not Scheme. When I was writing LISP, those weren't required. Which is what I said: variable declarations aren't required, and aren't allowedd in Scheme. However, either way, variable assignment is done via : (setf *a* 5) (setf a 10) This is what I call variable declaration as you have different way to declare global variables and to assign them ... So the two operations are well defined and different. Python uses global foo to declare global variables. And here there is a difference between static language and declarative ones ... Lisp is a dynamic language that needs variable declarations. LISP doesn't need variable declarations. I certainly never wrote any when I was writing it. Except declarations don't add functionality to the language. They effect the programing process. And we have conflicting claims about whether that's a good effect or not, all apparently based on nothing solider than personal experience. Which means the arguments are just personal preferences. Well, so why not *allow* for variable declaration ? Languages like Perl does that successfully ... you don't like : you don't do ! you like : you do ! A simple option at the beginning of the file tell the compilor if variable declaration is mandatory or not ! Perl is a red herring. Unless it's changed radically since I last looked, undeclared variables in Perl have dynamic scope, not lexical scope. While dynamically scoped variables are a powerful feature, and there have been proposals to add them to Python, having them be the default is just *wrong*. If I were writing in Perl, I'd want everything declared just to avoid that. Of course, if Python behaved that way, I'd do what I did with Perl, and change languages. I never said to adopt the whole Perl variable semantic. I just pointed what I think is a good idea in Perl and that help (IMHO) precising what I intended ... And I pointed out that it's a good idea in Perl because it does something that it doesn't need doing in Python. Dynamic languages tend to express a much wider range of programming paradigms than languages that are designed to be statically compiled. Some of these paradigms do away with - or relegate to the level of ugly performance hack - features that someone only experienced with something like Pascal would consider essential. Assignment statements are a good example of that. Well, could you be more specific once more ? I can't that many paradigm only available on dynamically typed languages ... beside duck-typing (which is basically a synonym for dynamically-typed) I said dynamic languages, *not* dynamically typed languages. They aren't the same thing. Dynamic languages let you create new functions, variables and attributes at run time. Python lets you delete them as well. This means that simle declarations can't tell you whether or not a variable will exist at runtime, because it may have been added at run time. Ok, I misunderstood ... however, can you still point some *usefull* paradigm available to dynamic languages that you cannot use with static ones ? As there are so many, it shouldn't be hard for you to show us some ! I find the ability to add attributes to an object or class at run time useful. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
On 6 Oct 2005 06:44:41 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: Op 2005-10-06, Bengt Richter schreef [EMAIL PROTECTED]: On 5 Oct 2005 09:27:04 GMT, Duncan Booth [EMAIL PROTECTED] wrote: Antoon Pardon wrote: It also is one possibility to implement writable closures. One could for instace have a 'declare' have the effect that if on a more inner scope such a declared variable is (re)bound it will rebind the declared variable instead of binding a local name. That is one possibility, but I think that it would be better to use a keyword at the point of the assigment to indicate assignment to an outer scope. This fits with the way 'global' works: you declare at (or near) the assignment that it is going to a global variable, not in some far away part of the code, so the global nature of the assignment is clearly visible. The 'global' keyword itself would be much improved if it appeared on the same line as the assignment rather than as a separate declaration. e.g. something like: var1 = 0 def f(): var2 = 0 def g(): outer var2 = 1 # Assign to outer variable global var1 = 1 # Assign to global IMO you don't really need all that cruft most of the time. E.g., what if ':=' meant 'assign to variable wherever it is (and it must exist), searching according to normal variable resolution order (fresh coinage, vro for short ;-), starting with local, then lexically enclosing and so forth out to module global (but not to builtins).' Just some ideas about this 1) Would it be usefull to make ':=' an expression instead if a statement? Some people would think so, but some would think that would be tempting the weak ;-) I think the most important reason that the assignment is a statement and not an expression would apply less here because '==' is less easy to turn into ':=' by mistake than into = Even if people though that kind of bug was still too easy 2) What if we reversed the operation. Instead of var := expression, we write expression =: var. IMO this would make it almost impossible to write an assignment by mistake in a conditional when you meant to test for equality. It's an idea. You could also have both, and use it to differentiate pre- and post-operation augassign variants. E.g., alist[i+:=2] # add and assign first, index value is value after adding alist[i=:+2] # index value is value before adding and assigning Some people might think that useful too ;-) Hm, I wonder if any of these variations would combine usefully with the new short-circuiting expr_true if cond_expr else expr_false ... Sorry I'll miss the flames, I'll be off line a while ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-04, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]: On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote: Declarations also allow easier writable closures. Since the declaration happens at a certain scope, the run time can easily find the correct scope when a variable is rebound. If it happens at runtime, then you can do it without declarations: they're gone by then. That depends on how they are implemented. declarations can be executable statements. It is not about can we do without or not. It is about are they helpfull or not. Python would be a whole different language if it never adapted something it could do without. Come to think of it, most functional languages - which are the languages that make the heaviest use of closures - don't require variable declarations. But AFAIK they don't work like python which makes any variable that is assigned to in a function, local. Which is a problem if you want a writable closure. They also relieve a burden from the run-time, since all variables are declared, the runtime doesn't has to check whether or not a variable is accesible, it knows it is. Not in a dynamic language. Python lets you delete variables at run time, so the only way to know if a variable exists at a specific point during the execution of an arbitrary program is to execute the program to that point. It is not perfect, that doesn't mean it can't help. How much code deletes variables. And if you provide type information with the declaration, more efficient code can be produced. Only in a few cases. Type inferencing is a well-understood technology, and will produce code as efficient as a statically type language in most cases. I thought it was more than in a few. Without some type information from the coder, I don't see how you can infer type from library code. I think language matters shouldn't be setlled by personal preferences. I have to agree with that. For whether or not a feature should be included, there should either be a solid reason dealing with the functionality of the language - meaning you should have a set of use cases showing what a feature enables in the language that couldn't be done at all, or could only be done clumsily, without the feature. I think this is too strict. Decorators would IMO never made it. The old way to do it, was certainly not clumsy IME. I think that a feature that could be helpfull in reduction errors, should be a candidate even if it has no other merrits. Except declarations don't add functionality to the language. They effect the programing process. It would be one way to get writable closures in the language. That is added functionality. And we have conflicting claims about whether that's a good effect or not, all apparently based on nothing solider than personal experience. Which means the arguments are just personal preferences. Whether the good effect is good enough is certainly open for debate. But the opponents seem to argue that since it is no absolute guarantee, it is next to useless. Well I can't agree with that kind of argument and will argue against it. Antoon, at a guess I'd say that Python is the first time you've encountered a dynamnic language. Being horrified at not having variable declarations, which is a standard feature of such languages dating back to the 1950s, is one such indication. No I'm not horrified at not having variable declarations. I'm in general very practical with regard to programming, and use what features a language offers me. However that doesn't stop me from thinking: Hey if language X would have feature F from language Y, that could be helpfull. Now if the developers think such a feature is not important enough fine, by me. It is however something different if people start arguing that feature F is totally useless. Now my impression is that a number of people regard python or at least some aspects of it as holy and that suggesting that some specific features could be usefull is considered sacriledge. Dynamic languages tend to express a much wider range of programming paradigms than languages that are designed to be statically compiled. Some of these paradigms do away with - or relegate to the level of ugly performance hack - features that someone only experienced with something like Pascal would consider essential. Assignment statements are a good example of that. I think we should get rid of thinking about a language as static or dynamic. It is not the language which should determine a static or dynamic approach, it is the problem you are trying to solve. And if the coder thinks that a static approach is best for his problem, why shouldn't he solve it that way. That a language allows a static approach too, doesn't contradict that it can work dynamically. Everytime a static feature is suggested, some dynamic folks react as if the dynamic aspect of
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Brian Quinlan [EMAIL PROTECTED] writes: Have those of you who think that the lack of required declarations in Python is a huge weakness given any thought to the impact that adding them would have on the rest of the language? I can't imagine how any language with required declarations could even remotely resemble Python. What's the big deal? Perl has an option for flagging undeclared variables with warnings (perl -w) or errors (use strict) and Perl docs I've seen advise using at least perl -w routinely. Those didn't have much impact. Python already has a global declaration; how does it de-Pythonize the language if there's also a local declaration and an option to flag any variable that's not declared as one or the other? The difference is that perl actually needs 'use strict' to be useful for anything more than trivial scripts. Without 'use strict' you can reference any variable name without getting an error. Python takes a stricter approach to begin with by throwing an exception if you reference an undefined variable. This only leaves the 'assigning to a different name than the one we intended' problem which seems to worry some people here, and as has been explained in great detail it incurs a cost to anyone reading the code for what most Python users consider to be a very small benefit. If you think variable declarations should be required, then you presumably want that to cover class attributes as well as local and global variables. After all assigning to 'x.i' when you meant 'x.j' is at least as bad as assigning to 'i' instead of 'j'. But unless you know the type of 'x', how do you know whether it has attributes 'i' or 'j'? So do we need type declarations, or perhaps we need a different syntax for 'create a new attribute' vs 'update an existing attribute', both of which would throw an exception if used in the wrong situation, and would therefore require lots of hasattr calls for the cases where we don't care. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-04, Ron Adam schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]: And lo, one multi-billion dollar Mars lander starts braking either too early or too late. Result: a new crater on Mars, named after the NASA employee who thought the compiler would catch errors. Using (unit)tests will not guarantee that your programs is error free. So if sooner or later a (unit)tested program causes a problem, will you then argue that we should abondon tests, because tests won't catch all errors. Maybe you need to specify what kind of errors you want to catch. Different types of errors require different approaches. I want to catch all errors of course. I know that nothing will ever guarantee me this result, but some things may help in getting close. So if a language provides a feature that can help, I generally think that is positive. That such a feature won't solve all problems shouldn't be considered fatal as some counter arguments seem to suggest. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
[EMAIL PROTECTED] wrote: Some people just don't get the simple fact that declarations are essentially kind of unit test you get for free (almost), and the compiler is a testing framework for them. It seems you've missed the entire point of using a dynamically typed language. It's not just about saving typing time and making your methods take up fewer lines of code. It's about writing generic code. Just look at C++ with all that mess with complex templates, silly casting and dangerous void pointers etc that are needed to achieve a fraction of the genericity that Python provides with no effort from the programmer. With properly written tests, you can be reasonably that the program does what you want. Type declarations are extremely limited in this aspect, and they often give programmers a false sense of security. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Duncan Booth [EMAIL PROTECTED] writes: If you think variable declarations should be required, I don't think they should be required. I think there should optional declarations along with a compiler flag that checks for them if the user asks for it, like Perl has. then you presumably want that to cover class attributes as well as local and global variables. After all assigning to 'x.i' when you meant 'x.j' is at least as bad as assigning to 'i' Yes, lots of people mistakenly use __slots__ for exactly that purpose. Maybe the function they think __slots__ is supposed to implement is a legitimate one, and having a correct way to do it is a good idea. But unless you know the type of 'x', how do you know whether it has attributes 'i' or 'j'? If the compiler knows (through declarations, type inference, or whatever) that x is a certain type of class instance, then it knows what attributes x has. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Magnus Lycka [EMAIL PROTECTED] writes: It seems you've missed the entire point of using a dynamically typed language. It's not just about saving typing time and making your methods take up fewer lines of code. It's about writing generic code. Just look at C++ with all that mess with complex templates, silly casting and dangerous void pointers etc that are needed to achieve a fraction of the genericity that Python provides with no effort from the programmer. So where are the complex templates and dangerous void pointers in ML? -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-05, Duncan Booth schreef [EMAIL PROTECTED]: Paul Rubin wrote: Brian Quinlan [EMAIL PROTECTED] writes: Have those of you who think that the lack of required declarations in Python is a huge weakness given any thought to the impact that adding them would have on the rest of the language? I can't imagine how any language with required declarations could even remotely resemble Python. What's the big deal? Perl has an option for flagging undeclared variables with warnings (perl -w) or errors (use strict) and Perl docs I've seen advise using at least perl -w routinely. Those didn't have much impact. Python already has a global declaration; how does it de-Pythonize the language if there's also a local declaration and an option to flag any variable that's not declared as one or the other? The difference is that perl actually needs 'use strict' to be useful for anything more than trivial scripts. Without 'use strict' you can reference any variable name without getting an error. Python takes a stricter approach to begin with by throwing an exception if you reference an undefined variable. This only leaves the 'assigning to a different name than the one we intended' problem which seems to worry some people here, and as has been explained in great detail it incurs a cost to anyone reading the code for what most Python users consider to be a very small benefit. It also is one possibility to implement writable closures. One could for instace have a 'declare' have the effect that if on a more inner scope such a declared variable is (re)bound it will rebind the declared variable instead of binding a local name. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
James A. Donald wrote: What can one do to swiftly detect this type of bug? Unit tests. In my experience the edit - test cycle in Python is typically roughly as fast as the edit - compile cycle in e.g. C++, and much faster than the full edit - compile - link - test cycle in C++. You do use automated tests for your programs don't you? Otherwise I think you are sifting out gnats while you are are swallowing camels. There are also lint-like tools such as pylint and pychecker if you think static tests are useful for you. Here at Carmen, we've actually skipped the unit test step, and run functional tests at once, using the Texttest framework--and that fits well with our type of apps. See http://texttest.carmen.se/ -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon wrote: It also is one possibility to implement writable closures. One could for instace have a 'declare' have the effect that if on a more inner scope such a declared variable is (re)bound it will rebind the declared variable instead of binding a local name. That is one possibility, but I think that it would be better to use a keyword at the point of the assigment to indicate assignment to an outer scope. This fits with the way 'global' works: you declare at (or near) the assignment that it is going to a global variable, not in some far away part of the code, so the global nature of the assignment is clearly visible. The 'global' keyword itself would be much improved if it appeared on the same line as the assignment rather than as a separate declaration. e.g. something like: var1 = 0 def f(): var2 = 0 def g(): outer var2 = 1 # Assign to outer variable global var1 = 1 # Assign to global -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Brian Quinlan [EMAIL PROTECTED] writes:
Python already has a global declaration;
Which is evaluated at runtime, does not require that the actual global
variable be pre-existing, and does not create the global variable if
not actually assigned. I think that is pretty different than your
proposal semantics.
Different how?
Your making this feature optional contradicts the subject of this
thread i.e. declarations being necessary.
They're necessary if you enable the option.
But, continuing with your declaration thought experiment, how are
you planning on actually adding optional useful type declarations to
Python e.g. could you please rewrite this (trivial) snippet using
your proposed syntax/semantics?
def do_add(x-str, y-str):
return '%s://%s' % (x, y)
def do_something(node-Node):
if node.namespace == XML_NAMESPACE:
return do_add('http://', node.namespace)
elif node.namespace == ...
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote:
Brian Quinlan [EMAIL PROTECTED] writes:
Have those of you who think that the lack of required declarations in
Python is a huge weakness given any thought to the impact that adding
them would have on the rest of the language? I can't imagine how any
language with required declarations could even remotely resemble
Python.
Python already has a global declaration;
Which is evaluated at runtime, does not require that the actual global
variable be pre-existing, and does not create the global variable if not
actually assigned. I think that is pretty different than your proposal
semantics.
how does it de-Pythonize the language if there's also a local
declaration and an option to flag any variable that's not declared as
one or the other?
Your making this feature optional contradicts the subject of this
thread i.e. declarations being necessary. But, continuing with your
declaration thought experiment, how are you planning on actually adding
optional useful type declarations to Python e.g. could you please
rewrite this (trivial) snippet using your proposed syntax/semantics?
from xml.dom import *
def do_add(x, y):
return '%s://%s' % (x, y)
def do_something(node):
if node.namespace == XML_NAMESPACE:
return do_add('http://', node.namespace)
elif node.namespace == ...
...
There's been a proposal from none other than GvR to add optional
static declarations to Python:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
A few points:
1. making it work in a reasonable way is an acknowledged hard problem
2. it will still probably not involve doing type checking at
compile-time
3. it would only generate a warning, not an error
Cheers,
Brian
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Brian Quinlan wrote: Paul Rubin wrote: Brian Quinlan [EMAIL PROTECTED] writes: Have those of you who think that the lack of required declarations in Python is a huge weakness given any thought to the impact that adding them would have on the rest of the language? I can't imagine how any language with required declarations could even remotely resemble Python. Python already has a global declaration; Which is evaluated at runtime, does not require that the actual global variable be pre-existing, and does not create the global variable if not actually assigned. I think that is pretty different than your proposal semantics. I believe that global is the one Python statement that isn't actually executable, and simply conditions the code generated during compilation (to bytecode). Hard to see why someone would want to use a global declaration unless they were intending to assign to it, given the sematnics of access. [...] regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-05, Duncan Booth schreef [EMAIL PROTECTED]: Antoon Pardon wrote: It also is one possibility to implement writable closures. One could for instace have a 'declare' have the effect that if on a more inner scope such a declared variable is (re)bound it will rebind the declared variable instead of binding a local name. That is one possibility, but I think that it would be better to use a keyword at the point of the assigment to indicate assignment to an outer scope. This fits with the way 'global' works: you declare at (or near) the assignment that it is going to a global variable, not in some far away part of the code, so the global nature of the assignment is clearly visible. As far as I understand people don't like global very much so I don't expect that a second keyword with the same kind of behaviour has any chance. The 'global' keyword itself would be much improved if it appeared on the same line as the assignment rather than as a separate declaration. e.g. something like: var1 = 0 def f(): var2 = 0 def g(): outer var2 = 1 # Assign to outer variable global var1 = 1 # Assign to global And what would the following do: def f(): var = 0 def g(): var = 1 def h(): outer var = 2 * var + 1 h() print var g() print var f() -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon wrote: Op 2005-10-04, Ron Adam schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]: And lo, one multi-billion dollar Mars lander starts braking either too early or too late. Result: a new crater on Mars, named after the NASA employee who thought the compiler would catch errors. Using (unit)tests will not guarantee that your programs is error free. So if sooner or later a (unit)tested program causes a problem, will you then argue that we should abondon tests, because tests won't catch all errors. Maybe you need to specify what kind of errors you want to catch. Different types of errors require different approaches. I want to catch all errors of course. Yes, of course, and so do other programmers. What I mean is to try and break it down into specific instances and then see what the best approach is for each one is. When I first started leaning Python I looked for these features as well, but after a while my programming style changed and I don't depend on types and names to check my data near as much now. But instead write better organized code and data structures with more explicit value checks where I need them. My concern now is having reusable code and modules I can depend on. And also separating my data and data management operations from the user interface. Having functions and names that don't care what type the objects are, makes doing this separation easier. Another situation where typeless names are useful is routines that explicitly check the type, then depending on the type does different things. For example if you have a list with a lot of different type objects stored in it, you can sort the contents into sublists by type. Looking at it from a different direction, how about adding a keyword to say, from this point on, in this local name space, disallow new names. Then you can do... def few(x,y): a = 'a' b = 'b' i = j = k = l = None no_new_names # raise an error after here if a new name is used. ... for I in range(10): -- error ... This is more suitable to Pythons style than declaring types or variables I think. Add to this explicit name-object locking to implement constants and I think you would have most of the features you want. so... no_new_names # limit any new names lock_name name # lock a name to it's current object Since names are stored in dictionaries, a dictionary attribute to disallow/allow new keys, and a way to set individual elements in a dictionary to read only would be needed. Once you can do that and it proves useful, then maybe you can propose it as a language feature. These might also be checked for in the compile stage and would probably be better as it wouldn't cause any slow down in the code or need a new dictionary type. An external checker could possibly work as well if a suitable marker is used such as a bare string. ... x = y = z = None No_New_Names# checker looks for this ... X = y/z # and reports this as an error return x,y and.. ... Author = Fred Name_Lock Author# checker sees this... ... Author = John # then checker catches this ... So there are a number of ways to possibly add these features. Finding common use cases where these would make a real difference would also help. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon wrote: As far as I understand people don't like global very much so I don't expect that a second keyword with the same kind of behaviour has any chance. That's why the behaviour I suggest is different than the current behaviour of global. Arguments against global (it is the only non-executable statement in Python it is confusing because people don't understand the declaration goes inside the function instead of at global scope) don't apply. The 'global' keyword itself would be much improved if it appeared on the same line as the assignment rather than as a separate declaration. e.g. something like: var1 = 0 def f(): var2 = 0 def g(): outer var2 = 1 # Assign to outer variable global var1 = 1 # Assign to global And what would the following do: def f(): var = 0 def g(): var = 1 def h(): outer var = 2 * var + 1 h() print var g() print var f() It would follow the principle of least surprise and set the value of var in g() of course. The variable in f is hidden, and if you didn't mean to hide it you didn't need to give the two variables the same name. So the output would be: 3 0 (output verified by using my hack for setting scoped variables:) --- from hack import * def f(): var = 0 def g(): var = 1 def h(): assign(lambda: var, 2 * var + 1) h() print var g() print var f() --- -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote:
Which is evaluated at runtime, does not require that the actual global
variable be pre-existing, and does not create the global variable if
not actually assigned. I think that is pretty different than your
proposal semantics.
Different how?
Aren't you looking for some of compile-time checking that ensures that
only declared variables are actually used? If so, how does global help?
Your making this feature optional contradicts the subject of this
thread i.e. declarations being necessary.
They're necessary if you enable the option.
OK. Would it work on a per-module basis or globally?
def do_add(x-str, y-str):
return '%s://%s' % (x, y)
def do_something(node-Node):
if node.namespace == XML_NAMESPACE:
return do_add('http://', node.namespace)
elif node.namespace == ...
Wouldn't an error be generated because XML_NAMESPACE is not declared?
And I notice that you are not doing any checking that namespace is a
valid attribute of the node object. Aren't the typos class of error that
you are looking to catch just as likely to occur for attributes as
variables?
Cheers,
Brian
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Mike Meyer wrote:
(snip)
Antoon, at a guess I'd say that Python is the first time you've
encountered a dynamnic language. Being horrified at not having
variable declarations,
Mike, being horrified by the (perceived as...) lack of variable
declaration was the OP's reaction, not Antoon's.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Brian Quinlan [EMAIL PROTECTED] writes:
Aren't you looking for some of compile-time checking that ensures that
only declared variables are actually used? If so, how does global help?
You'd have to declare any variable global, or declare it local, or it
could be a function name (defined with def) or a function arg (in the
function scope), or maybe you could also declare things like loop
indices. If it wasn't one of the above, the compiler would flag it.
Your making this feature optional contradicts the subject of this
thread i.e. declarations being necessary.
They're necessary if you enable the option.
OK. Would it work on a per-module basis or globally?
Whatever perl does. I think that means per-module where the option is
given as use strict inside the module.
def do_add(x-str, y-str):
return '%s://%s' % (x, y)
def do_something(node-Node):
if node.namespace == XML_NAMESPACE:
return do_add('http://', node.namespace)
elif node.namespace == ...
Wouldn't an error be generated because XML_NAMESPACE is not declared?
XML_NAMESPACE would be declared in the xml.dom module and the type
info would carry over through the import.
And I notice that you are not doing any checking that namespace is a
valid attribute of the node object. Aren't the typos class of error
that you are looking to catch just as likely to occur for attributes
as variables?
The node object is declared to be a Node instance and if the Node
class definition declares a fixed list of slots, then the compiler
would know the slot names and check them. If the Node class doesn't
declare fixed slots, then they're dynamic and are looked up at runtime
in the usual way.
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote:
You'd have to declare any variable global, or declare it local, or it
could be a function name (defined with def) or a function arg (in the
function scope), or maybe you could also declare things like loop
indices. If it wasn't one of the above, the compiler would flag it.
OK. The Python compiler would check that the name is declared but it
would not check that it is defined before use? So this would be acceptable:
def foo():
local x
return x
OK. Would it work on a per-module basis or globally?
Whatever perl does. I think that means per-module where the option is
given as use strict inside the module.
def do_add(x-str, y-str):
return '%s://%s' % (x, y)
def do_something(node-Node):
if node.namespace == XML_NAMESPACE:
return do_add('http://', node.namespace)
elif node.namespace == ...
Wouldn't an error be generated because XML_NAMESPACE is not declared?
XML_NAMESPACE would be declared in the xml.dom module and the type
info would carry over through the import.
Problems:
1. your type checking system is optional and xml.dom does not use it
1a. even if xml.dom did declare the type, what if the type were declared
conditionally e.g.
try:
unicode
except NameError:
XML_NAMESPACEstr = ...
else:
XML_NAMESPACEunicode = u...
2. the compiler does not have access to the names in other modules
anyway
And I notice that you are not doing any checking that namespace is a
valid attribute of the node object. Aren't the typos class of error
that you are looking to catch just as likely to occur for attributes
as variables?
The node object is declared to be a Node instance and if the Node
class definition declares a fixed list of slots, then the compiler
would know the slot names and check them.
How would you find the class definition for the Node object at
compile-time? And by slots do you mean the existing Python slots
concept or something new?
If the Node class doesn't
declare fixed slots, then they're dynamic and are looked up at runtime
in the usual way.
So only pre-defined slotted attributes would be accessable (if the
object uses slots). So the following would not work:
foo = Foo() # slots defined
foo.my_attribute = 'bar'
print foo.my_attribute
Cheers,
Brian
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: So where are the complex templates and dangerous void pointers in ML? You're right about that of course. There aren't any templates or pointers in COBOL either as far as I know, and COBOL has been used for lots of real world code (which ML hasn't). I don't know what your point is though. Sure, Python could have Perl-like declarations, where you just state that you intend to use a particular name, but don't declare its type. I don't see any harm in that. Type declarations or inferred types would, on the other hand, make Python considerably less dynamic, and would probably bring the need of additional featurs such as function overloading etc. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon [EMAIL PROTECTED] writes: They also relieve a burden from the run-time, since all variables are declared, the runtime doesn't has to check whether or not a variable is accesible, it knows it is. Not in a dynamic language. Python lets you delete variables at run time, so the only way to know if a variable exists at a specific point during the execution of an arbitrary program is to execute the program to that point. It is not perfect, that doesn't mean it can't help. How much code deletes variables. It's not perfect means it may not help. Depends on the cost of being wrong - which means we need to see how things would be different if the code was assuming that a variable existed, and then turned out to be wrong. Actually, I'd be interested in knowing how you would improve the current CPython implementation with knowledge about whether or not a variable existed. The current implementation just does a dictionary lookup on the name. The lookup fails if the variable doesn't exist. So checking on the existence of the variable is a byproduct of finding the value of the variable. So even if it was perfect, it wouldn't help. And if you provide type information with the declaration, more efficient code can be produced. Only in a few cases. Type inferencing is a well-understood technology, and will produce code as efficient as a statically type language in most cases. I thought it was more than in a few. Without some type information from the coder, I don't see how you can infer type from library code. There's nothing special about library code. It can be anaylyzed just like any other code. I think language matters shouldn't be setlled by personal preferences. I have to agree with that. For whether or not a feature should be included, there should either be a solid reason dealing with the functionality of the language - meaning you should have a set of use cases showing what a feature enables in the language that couldn't be done at all, or could only be done clumsily, without the feature. I think this is too strict. Decorators would IMO never made it. From the impressions I get here, a lot of people would have been happy with that result. I think that a feature that could be helpfull in reduction errors, should be a candidate even if it has no other merrits. Yes, but that doesn't mean it should be accepted. Otherwise, every language would be Eiffel. You have to weigh the cost of a feature against the benefit you get from it - and different people come to different conclusions. Which is why different languages provide different levels of bondage. Except declarations don't add functionality to the language. They effect the programing process. It would be one way to get writable closures in the language. That is added functionality. Except just adding declerations doesn't give you that. You have to change the language so that undeclared variables are looked for up the scope. And that's the only change you need to get writable variables - some way to indicate that a variable should be checked for up the scope. There are more lightweight ways to do that than tagging every *other* variable. Those have been proposed - and rejected. And we have conflicting claims about whether that's a good effect or not, all apparently based on nothing solider than personal experience. Which means the arguments are just personal preferences. Whether the good effect is good enough is certainly open for debate. But the opponents seem to argue that since it is no absolute guarantee, it is next to useless. Well I can't agree with that kind of argument and will argue against it. You're not reading the opponents arguments carefully enough. The argument is that the benefit from type declerations is overstated, and in reality doesn't outweigh the cost of declerations. Antoon, at a guess I'd say that Python is the first time you've encountered a dynamnic language. Being horrified at not having variable declarations, which is a standard feature of such languages dating back to the 1950s, is one such indication. No I'm not horrified at not having variable declarations. I'm in general very practical with regard to programming, and use what features a language offers me. However that doesn't stop me from thinking: Hey if language X would have feature F from language Y, that could be helpfull. I'm sorry - I thought you were the OP, who said he was horrified by that lack. Dynamic languages tend to express a much wider range of programming paradigms than languages that are designed to be statically compiled. Some of these paradigms do away with - or relegate to the level of ugly performance hack - features that someone only experienced with something like Pascal would consider essential. Assignment statements are a good example of that. I think we should get rid of thinking about a language as static or dynamic. It is not the language which should determine a static or
Re: no variable or argument declarations are necessary.
This is naive. Testing doesn't guarantee anything. If this is what you think about testing, then testing gives you a false impression of security. Maybe we should drop testing. Typechecking is done by a reduced lamda calculus (System F, which is ML-Style), whereas testing has the full power of a turing complete language. So _if_ one has to be dropped, it would certainly be typechecking. Additionally, testing gives you the added benefit of actually using your decelared APIs - which serves documentation purposes as well as securing your design decisions, as you might discover bad design while actually writing testcases. Besides that, the false warm feeling of security a successful compilation run has given many developers made them check untested and actually broken code into the VCS. I've seen that _very_ often! And the _only_ thinng that prevents us from doing so is to enforce tests. But these are more naturally done in python (or similar languages) as every programmer knows unless the program run sucsessfully, I can't say anything about it than in a statically typed language where the programmer argues hey, it compiled, it should work! Regards, Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Brian Quinlan [EMAIL PROTECTED] writes: OK. The Python compiler would check that the name is declared but it would not check that it is defined before use? So this would be acceptable: def foo(): local x return x Come on, you are asking silly questions. Any reasonable C compiler would flag something like that and Python (with the flag set) should do the same. If you want to ask substantive questions, that's fine, but stop wasting our time with silly stuff. XML_NAMESPACE would be declared in the xml.dom module and the type info would carry over through the import. 1. your type checking system is optional and xml.dom does not use it If type checking is implemented then the stdlib should be updated to add declarations for public symbols. If not, the compiler would flag the undeclared symbol. You could always declare it to be of type 'object'. try: unicode except NameError: XML_NAMESPACEstr = ... else: XML_NAMESPACEunicode = u... This wouldn't be allowed. 2. the compiler does not have access to the names in other modules anyway You're being silly again. The compiler would examine the other module when it processes the import statement, just like it does now. How would you find the class definition for the Node object at compile-time? By processing the xml.dom module when it's imported. And by slots do you mean the existing Python slots concept or something new? Probably something new, if the existing concept is incompatible in some way. So only pre-defined slotted attributes would be accessable (if the object uses slots). So the following would not work: foo = Foo() # slots defined foo.my_attribute = 'bar' print foo.my_attribute Yes, correct, many people already think the existing __slots__ variable is intended for precisely that purpose and try to use it that way. Note you can get the same effect with a suitable __setattr__ method that's activated after __init__ returns, so all we're discussing is a way to make the equivalent more convenient. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]: On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote: Op 2005-10-03, Duncan Booth schreef [EMAIL PROTECTED]: Antoon Pardon wrote: A language where variable have to be declared before use, would allow to give all misspelled (undeclared) variables in on go, instead of just crashing each time one is encounterd. Wrong. It would catch at compile-time those misspellings which do not happen to coincide with another declared variable. Fine, it is still better than python which will crash each time one of these is encountered. Python doesn't crash when it meets an undeclared variable. It raises an exception. Your nit-picking. For the sake of finding misspelled variables the difference is irrelevant. Moreover, it adds a burden on the programmer who has to write all those declarations, So? He has to write all those lines of code too. People often promote unittesting here. Writing all those unittest is an added burden too. But people think this burden is worth it. Yes, but there is no evidence that pre-declaration of variables is a burden worth carrying. It doesn't catch any errors that your testing wouldn't catch anyway. Maybe not, but it may catch them earlier and may make them easier to recognize. Declarations also allow easier writable closures. Since the declaration happens at a certain scope, the run time can easily find the correct scope when a variable is rebound. They also relieve a burden from the run-time, since all variables are declared, the runtime doesn't has to check whether or not a variable is accesible, it knows it is. And if you provide type information with the declaration, more efficient code can be produced. I think writing declaration is also worth it. The gain is not as much as with unittesting but neither is the burden, so that balances out IMO Speaking as somebody who spent a long time programming in Pascal, I got heartedly sick and tired of having to jump backwards and forwards from where I was coding to the start of the function to define variables. I have programmed a lot in Pascal too and Modula II and other languages. I never found declarations that much a burden. That you got heartedly sick of having to use declarations says very little about declarations and says more about you. I think language matters shouldn't be setlled by personal preferences. It got to the stage that sometimes I'd pre-define variables I thought I might need, intending to go back afterwards and delete the ones I didn't need. When the programmer is having to to jump through hoops to satisfy the compiler, there is something wrong. Maybe it was your way of working. I never thought I had to go through hoops to satisfy the compiler. You have to satisfy that compilor anyway, for the moment I have more problems with colons that have to be put after an if, else etc than I ever had with declarations. and worse it adds a burden on everyone reading the code who has more lines to read before understanding the code. Well maybe we should remove all those comments from code too, because all it does is add more lines for people to read. Well-written comments should give the reader information which is not in the code. If the comment gives you nothing that wasn't obvious from the code, it is pointless and should be removed. Variable declarations give the reader nothing that isn't in the code. If I write x = 15, then both I and the compiler knows that there is a variable called x. It is blindingly obvious. Why do I need to say define x first? Because it isn't at all obvious at which scope that x is. Sure you can define your language that rebinding is always at local scope, but that you need to define it so, means it isn't that obvious. Also the question is not whether or not there is a variable x, the quesntions whether or not there should be a variable x. That is not at all that obvious when you write x = 15. Pre-defining x protects me from one class of error, where I typed x instead of (say) n. That's fine as far as it goes, but that's not necessarily an _error_. If the typo causes an error, e.g.: def spam(n): return spam * x # oops, typo then testing will catch it, and many other errors as well. Declaring the variable doesn't get me anything I wouldn't already get. Yes it would have caught this error even before you had to begin testing. But if it doesn't cause an error, e.g.: def spam(n): if n: return spam * n else: x = 0 # oops, typo return spam * n This may never cause a failure, since n is always an integer. Since my other testing guarantees that n is always an integer, This is naive. Testing doesn't guarantee anything. If this is what you think about testing, then testing gives you a false impression of security. Maybe we should drop testing. it doesn't matter that I've created a variable x that doesn't get used. Yes,
Re: no variable or argument declarations are necessary.
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]: On Mon, 03 Oct 2005 06:59:04 +, Antoon Pardon wrote: Well I'm a bit getting sick of those references to standard idioms. There are moments those standard idioms don't work, while the gist of the OP's remark still stands like: egold = 0: while egold 10: if test(): ego1d = egold + 1 for item in [x for x in xrange(10) if test()]: But it isn't about the idioms. It is about the trade-offs. Python allows you to do things that you can't do in other languages because you have much more flexibility than is possible with languages that require you to declare variables before using them. The cost is, some tiny subset of possible errors will not be caught by the compiler. But since the compiler can't catch all errors anyway, you need to test for errors and not rely on the compiler. No compiler will catch this error: x = 12.0 # feet # three pages of code y = 15.0 # metres # three more pages of code distance = x + y if distance 27: fire_retro_rockets() And lo, one multi-billion dollar Mars lander starts braking either too early or too late. Result: a new crater on Mars, named after the NASA employee who thought the compiler would catch errors. Using (unit)tests will not guarantee that your programs is error free. So if sooner or later a (unit)tested program causes a problem, will you then argue that we should abondon tests, because tests won't catch all errors. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Mike Meyer wrote: Steven D'Aprano [EMAIL PROTECTED] writes: Declared variables have considerable labour costs, and only marginal gains. Since the steps you take to protect against other errors will also protect against mistyping variables, declarations of variables is of little practical benefit. As far as I can tell, this is as much hearsay and personal experience as the alternate claim that not having them costs you lots of debugging time and errors. If anyone has pointers to real research into this area (I've heard the TRAK folks did some, but haven't been able to turn any up), I'd love to hear it. Sorry, I have no hard research to point to. If I did, I would have referenced it. My gut reaction is that it's a wash. The time taken to declare variables in well-written code in a well-designed language - meaning the declarations and use will be close together - isn't all that great, but neither are the savings. It isn't the typing time to declare variables, it is the context switching. You're focused on implementing an algorithm, realise you need to declare another variable, your brain does a mini-context switch, you scroll up to the declaration section, you declare it, you scroll back to where you were, and now you have to context switch again. You've gone from thinking about the implementation of the algorithm to thinking about how to satisfy the requirements of the compiler. As context switches go, it isn't as big as the edit-compile-make-run method of testing, but it is still a context switch. Or you just code without declaring, intending to go back and do it later, and invariably forget. [snip] If I'm going to get compiler support for semantic checking like this, I want it to serious levels. I want function pre/post conditions checked. I want loop and class invariant checked. I want subsumption in my inheritance tree. Nuts - I want a complete, well-designed inheritance tree. Duck typing is great stuff, but if I'm going to be doing the work to declare everything, I want *everything* that can be checked checked. We like to think of programming as a branch of engineering. It isn't, not yet. I've worked for architects who were involved in some major engineering projects. One of the things I learnt is that there are times when you need to specify objects strictly. When only a 5% titanium stainless steel alloy will do, then *only* a 5% titanium stainless steel alloy will do. That's when you want strict type-checking. But the rest of the time, just about any stainless steel will do, and sometimes you don't even care if it is steel -- iron will do the job just as well. If the nail is hard enough to be hammered into the wood, and long enough to hold it in place, it is good enough for the job. That's the real-world equivalent of duck typing. Static typed languages that do all those checks are the equivalent of building the space shuttle, where everything must be specified in advance to the nth degree: it must not just be a three inch screw, but a three inch Phillips head anti-spark non-magnetic corrosion-resistant screw rated to a torque of such-and-such and capable of resisting vaccuum welding, extreme temperatures in both directions, and exposure to UV radiation. For that, you need a compiler that will do what Mike asks for: check *everything*. I don't know whether there are languages that will check everything in that way. If there aren't, then perhaps there should be. But Python shouldn't be one of them. Specifying every last detail about the objects making up the space shuttle is one of the reasons why it costs umpty-bazillion dollars to build one, and almost as much to maintain it -- and it still has a safety record worse than most $10,000 cars. That level of specification is overkill for most engineering projects, and it's overkill for most programming projects too. It is all well and good to tear your hair and rip your clothes over the possibility of the language allowing some hidden bug in the program, but get over it: there is always a trade off to be made between cost, time and risk of bugs. Python is a language that makes the trade off one way (fast development, low cost, high flexibility, moderate risk) rather than another (slow development, high cost, low flexibility, low risk). We make the same trade offs in the real world too: the chair you sit on is not built to the same level of quality as the space shuttle, otherwise it would cost $100,000 instead of $100. Consequently, sometimes chairs break. Deal with it. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
bruno modulix [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
James A. Donald wrote:
I am contemplating getting into Python, which is used by engineers I
admire - google and Bram Cohen, but was horrified
horrified ???
Ok, so I'll give you more reasons to be 'horrified':
- no private/protected/public access restriction - it's just a matter of
conventions ('_myvar' - protected, '__myvar' - private)
- no constants (here again just a convention : a name in all uppercase
is considered a constant - but nothing will prevent anyone to modify it)
- possibility to add/delete attributes to an object at runtime
- possibility to modify a class at runtime
- possibility to change the class of an object at runtime
- possibility to rebind a function name at runtime
If you find all this horrifying too, then hi-level dynamic languages are
not for you !-)
Not to mention that since the O.P. seem to assume that the compiler will
protect against deliberate subversion by evil programmers then he must be
further horrified to learn that, although it is harder to do the above in
f.ex. C++, it is not at all impossible, a carefully crafted pointer or a
little devious sub-classing goes a long way.
If all else fails, The humble Linker holds the Word of Power!
Tampering with linking is both the easiest way to subvert code reviews,
language checks and boundaries and also the hardest to discover because the
tampering will be buried somewhere deep inside the build process, the part
that never, ever gets reviewed because it is automated anyway and too
complex entirely so nobody sane will actually mess with it once it works
i.e. produces runnable code!.
Finally, given proper permissions, one can of course re-link the binary
executable, should the occasion merit. Like when one needs HIP in Telnet
which is an absolute brd to build on a modern Linux box. (Somebody build
that *once* in maybe 1978, I think ;-) One can replace classes in Jar
archives too - possibly one can even get the Java runtime to load the new
version of a jar archive in preference to the shipped one ...
I.O.W:
Superficially, the compile-time checks of Java and C++ provides some checks
boundaries but it comes at the expense of much more machinery with many
more intricate movable parts than *also* can be interfered with (or broken).
Python is simple and self-contained, thus it is pretty obvious - or at least
not too difficult, to check what *actually* goes on with an application.
If there is no trust, nothing can be done safely. If there is trust, then
most of the percieved safety just get in the way of work.
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-04, Steven D'Aprano schreef [EMAIL PROTECTED]: Mike Meyer wrote: Steven D'Aprano [EMAIL PROTECTED] writes: Declared variables have considerable labour costs, and only marginal gains. Since the steps you take to protect against other errors will also protect against mistyping variables, declarations of variables is of little practical benefit. As far as I can tell, this is as much hearsay and personal experience as the alternate claim that not having them costs you lots of debugging time and errors. If anyone has pointers to real research into this area (I've heard the TRAK folks did some, but haven't been able to turn any up), I'd love to hear it. Sorry, I have no hard research to point to. If I did, I would have referenced it. My gut reaction is that it's a wash. The time taken to declare variables in well-written code in a well-designed language - meaning the declarations and use will be close together - isn't all that great, but neither are the savings. It isn't the typing time to declare variables, it is the context switching. You're focused on implementing an algorithm, realise you need to declare another variable, your brain does a mini-context switch, you scroll up to the declaration section, you declare it, you scroll back to where you were, and now you have to context switch again. You've gone from thinking about the implementation of the algorithm to thinking about how to satisfy the requirements of the compiler. As context switches go, it isn't as big as the edit-compile-make-run method of testing, but it is still a context switch. Nobody forces you to work this way. You can just finish your algorithm and declare your variables afterwards. Besides likewise things can happen in python. If you suddenly realise your class needs an instance variable, chances are you will have to add initialisation code for that instance variable in the __init__ method. So either you do a context switch from implementing whatever method you were working on to the initialisation in __init__ and back or you just code without initialisation, intending to go back an do it later. Or you just code without declaring, intending to go back and do it later, and invariably forget. What's the problem, the compilor will allert you to your forgetfullness and you can then correct them all at once. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon [EMAIL PROTECTED] writes: Or you just code without declaring, intending to go back and do it later, and invariably forget. What's the problem, the compilor will allert you to your forgetfullness and you can then correct them all at once. Thiat in fact happens to me all the time and is an annoying aspect of Python. If I forget to declare several variables in C, the compiler gives me several warning messages and I fix them in one edit. If I forget to initialize several variables in Python, I need a separate test-edit cycle to hit the runtime error for each one. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Antoon Pardon [EMAIL PROTECTED] writes: Or you just code without declaring, intending to go back and do it later, and invariably forget. What's the problem, the compilor will allert you to your forgetfullness and you can then correct them all at once. Thiat in fact happens to me all the time and is an annoying aspect of Python. If I forget to declare several variables in C, the compiler gives me several warning messages and I fix them in one edit. If I forget to initialize several variables in Python, I need a separate test-edit cycle to hit the runtime error for each one. Well I hope you aren't suggesting that declaring variables makes it impossible to forget to initalise them. So I don;t really see the relevance of this remark, since you simply add an extra run to fix up the forgot to declare problem. After that you get precisely one runtime error per forgot to initialize. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-04, Steve Holden schreef [EMAIL PROTECTED]: Paul Rubin wrote: Antoon Pardon [EMAIL PROTECTED] writes: Or you just code without declaring, intending to go back and do it later, and invariably forget. What's the problem, the compilor will allert you to your forgetfullness and you can then correct them all at once. Thiat in fact happens to me all the time and is an annoying aspect of Python. If I forget to declare several variables in C, the compiler gives me several warning messages and I fix them in one edit. If I forget to initialize several variables in Python, I need a separate test-edit cycle to hit the runtime error for each one. Well I hope you aren't suggesting that declaring variables makes it impossible to forget to initalise them. So I don;t really see the relevance of this remark, since you simply add an extra run to fix up the forgot to declare problem. After that you get precisely one runtime error per forgot to initialize. Declaration and initialisation often go together. So the fixup to declare is often enough a fixup for the initialisation too. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
What can one do to swiftly detect this type of bug? While I can only speak from my own experience I can't remember a single instance where this type of bug caused any kind of serious problem. IMHO these are very trivial errors, that get caught immediately and I would not even qualify them as bugs, more like typos, spelling mistakes, etc. Real bugs are a lot more insidious than that, and they might even occur more frequently if there was type checking ... since it might even lead to longer code just my $0.01 Istvan. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Have those of you who think that the lack of required declarations in Python is a huge weakness given any thought to the impact that adding them would have on the rest of the language? I can't imagine how any language with required declarations could even remotely resemble Python. And if you want to use such a different language, wouldn't a different existing language better fit your needs...? Cheers, Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon [EMAIL PROTECTED] writes: Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]: On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote: Declarations also allow easier writable closures. Since the declaration happens at a certain scope, the run time can easily find the correct scope when a variable is rebound. If it happens at runtime, then you can do it without declarations: they're gone by then. Come to think of it, most functional languages - which are the languages that make the heaviest use of closures - don't require variable declarations. They also relieve a burden from the run-time, since all variables are declared, the runtime doesn't has to check whether or not a variable is accesible, it knows it is. Not in a dynamic language. Python lets you delete variables at run time, so the only way to know if a variable exists at a specific point during the execution of an arbitrary program is to execute the program to that point. And if you provide type information with the declaration, more efficient code can be produced. Only in a few cases. Type inferencing is a well-understood technology, and will produce code as efficient as a statically type language in most cases. I think language matters shouldn't be setlled by personal preferences. I have to agree with that. For whether or not a feature should be included, there should either be a solid reason dealing with the functionality of the language - meaning you should have a set of use cases showing what a feature enables in the language that couldn't be done at all, or could only be done clumsily, without the feature. Except declarations don't add functionality to the language. They effect the programing process. And we have conflicting claims about whether that's a good effect or not, all apparently based on nothing solider than personal experience. Which means the arguments are just personal preferences. Until someone does the research to provide hard evidence one way or another, that's all we've got to work with. Which means that languages should exist both with and with those features, and if one sides experiences generalize to the population at large, they alternative languages will die out. Which hasn't happened yet. But we should decide what language features are usefull and which are not by what some individual can or can't live without. Um - that's just personal preference (though I may have misparsed your sentence). What one person can't live without, another may not be able to live with. All that means is that they aren't likely to be happy with the same programming language. Which is fine - just as no programming language can do everything, no programming language can please everyone. Antoon, at a guess I'd say that Python is the first time you've encountered a dynamnic language. Being horrified at not having variable declarations, which is a standard feature of such languages dating back to the 1950s, is one such indication. Dynamic languages tend to express a much wider range of programming paradigms than languages that are designed to be statically compiled. Some of these paradigms do away with - or relegate to the level of ugly performance hack - features that someone only experienced with something like Pascal would consider essential. Assignment statements are a good example of that. Given these kinds of differences, prior experience is *not* a valid reason for thinking that some difference must be wrong. Until you have experience with the language in question, you can't really decide that some feature being missing is intolerable. You're in the same position as the guy who told me that a language without a goto would be unusable based on his experience with old BASIC, FORTRAN IV and assembler. Pick one of the many languages that don't require declarations. Try writing a code in them, and see how much of a problem it really is in practice, rather than trying to predict that without any information. Be warned that there are *lots* of variations on how undeclared variables are treated when referenced. Python raises exceptions. Rexx gives them their print name as a value. Other languages do other things. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Steven D'Aprano [EMAIL PROTECTED] writes: My gut reaction is that it's a wash. The time taken to declare variables in well-written code in a well-designed language - meaning the declarations and use will be close together - isn't all that great, but neither are the savings. You've gone from thinking about the implementation of the algorithm to thinking about how to satisfy the requirements of the compiler. As context switches go, it isn't as big as the edit-compile-make-run method of testing, but it is still a context switch. I'm making context switches all the time when programming. I go from thinking about the problem in terms of the problem, to thinking about in terms of programming language objects, to thinking about the syntax for expressing those objects. Adding another one does have a cost - but it's no big deal. I don't know whether there are languages that will check everything in that way. If there aren't, then perhaps there should be. But Python shouldn't be one of them. Right. You're doing different things when you program in a language like Python, vs. Eiffel (which is where I drew most of my checks from). Each does what it does well - but they don't do the same things. Specifying every last detail about the objects making up the space shuttle is one of the reasons why it costs umpty-bazillion dollars to build one, and almost as much to maintain it -- and it still has a safety record worse than most $10,000 cars. As if a something that's designed to literally blow you off the face of the earth could reasonably be compared with an internal combustion engine that never leaves the ground for safety. The shuttle has one of the best safety records around for vehicles that share it's purpose. It's doing something that's inherently very dangerous, that we are still learning how to do. Overengineering is the only way to get any measure of safety. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: Paul Rubin wrote: Antoon Pardon [EMAIL PROTECTED] writes: Or you just code without declaring, intending to go back and do it later, and invariably forget. What's the problem, the compilor will allert you to your forgetfullness and you can then correct them all at once. Thiat in fact happens to me all the time and is an annoying aspect of Python. If I forget to declare several variables in C, the compiler gives me several warning messages and I fix them in one edit. If I forget to initialize several variables in Python, I need a separate test-edit cycle to hit the runtime error for each one. Well I hope you aren't suggesting that declaring variables makes it impossible to forget to initalise them. So I don;t really see the relevance of this remark, since you simply add an extra run to fix up the forgot to declare problem. After that you get precisely one runtime error per forgot to initialize. It's hard to say what anyone's suggesting, unless some recent utterance from GvR has hinted at a possible declaration syntax in future Pythons. Short of that, it's ... a universe of possibilities, none of them likely enough to be very interesting. In the functional language approach I'm familiar with, you introduce a variable into a scope with a bind - let a = expr in ... do something with a and initialization is part of the package. Type is usually inferred. The kicker though is that the variable is never reassigned. In the ideal case it's essentially an alias for the initializing expression. That's one possibility we can probably not find in Python's universe. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
On Tue, 04 Oct 2005 10:18:24 -0700, Donn Cave [EMAIL PROTECTED] wrote: [...] In the functional language approach I'm familiar with, you introduce a variable into a scope with a bind - let a = expr in ... do something with a and initialization is part of the package. Type is usually inferred. The kicker though is that the variable is never reassigned. In the ideal case it's essentially an alias for the initializing expression. That's one possibility we can probably not find in Python's universe. how would you compare that with lambda a=expr: ... do something (limited to expression) with a ? Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Bengt Richter) wrote: On Tue, 04 Oct 2005 10:18:24 -0700, Donn Cave [EMAIL PROTECTED] wrote: [...] In the functional language approach I'm familiar with, you introduce a variable into a scope with a bind - let a = expr in ... do something with a and initialization is part of the package. Type is usually inferred. The kicker though is that the variable is never reassigned. In the ideal case it's essentially an alias for the initializing expression. That's one possibility we can probably not find in Python's universe. how would you compare that with lambda a=expr: ... do something (limited to expression) with a ? OK, the limitations of a Python lambda body do have this effect. But compare programming in a language like that, to programming with Python lambdas? Maybe it would be like living in a Zen Monastery, vs. living in your car. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
