Re: [Edu-sig] Properties use case
> This reminds me of a question I have with new-style classes. I just asked basically this question on c.l.p, and Alex Martelli has answered, quite helpfully. See topic "can't rebind magic methods' Michael Tobis ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
On Saturday 18 March 2006 16:39, Michael Tobis wrote: > > So, is there a problem with wrapping them thus: > > ### > class mcx(object): > > def __init__(self,val): > self.val = complex(val) > > def __add__(self,other): > """ and similarly for most other special methods """ > return self.val.__add__(other) > ### > This reminds me of a question I have with new-style classes. With classic Python classes, we can do something like this even more simply with getattr magic: class Mutable: def __init__(self, value): self.value = value def __getattr__(self,name): return getattr(self.value, name) This saves me the trouble of having to specifically reimplement all of the methods just so that I can trivially pass the work off to self.value. Everything works just fine: >>> from mutable import Mutable >>> x = Mutable(3+5j) >>> x (3+5j) >>> x + (4+7j) (7+12j) >>> print x (3+5j) >>> x.value = 3 >>> x + 4 7 I've used this technique to good advantage when mixing objects from different toolkits. My question is, is there an easy way to do this with new-style classes? While I'm on the thread, let me just add my 2 cents on Arthur's "creepy" mutable complex type. I understand all of the arguments about the potential pitfalls of mutable types (I'm one of those "CS types," don't you know :-). But OOP is all about mutable objects. As a _design_ decision, if a mutable complex will streamline my system, or make it more intuitive, then I wouldn't hesitate to do it. I think the "creepiness" here is just in the name. We don't expect complex numbers to be mutable. Let's call the new type a complex container with auto-unboxing. Does anyone object to a mutable container? I hope not, we used to just call them variables. Since the contents are isomorphic to complex, it could be handy to have the container object also duck-type to a complex (or whatever else it contained). I don't see any creepiness in that. Of course, this kind of thinking could get out of hand. The next thing you know people might use these to simulate wacko things like reference parameters (oh, the horror! :-) Just my 2 cents. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: Michael Tobias [mailto:[EMAIL PROTECTED] > > > >I would be happy to discuss the topic, but this requires > >that I approach the design with due skepticism. If you don't > >care to explain your needs you can't expect many useful > >answers, though I think it's reasonable to expect fewer and > >shorter non-useful ones! I sincerely appreciate your offer, and there is good reason to believe that you have a good beat on my objectives. But as I say, these conversations have actually caused me to reconceptualize a bit. So that talking about my complex "object"'s issues in its specifics seems to address where I was at the beginning of the conversation rather than where I am at the moment. I will have a better idea as to where I am at the moment if the power supply to my laptop decides to begin talking to my laptop. That and a day or two to futz, and than I'd love to reconvene. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
Well, if you are sacrificing performance, what is wrong with wrapping the complex number in a pure python class with all the magic methods overridden? I share your objectives and agree that Python provides a platform for addressing them. See my article at http://geosci.uchicago.edu/~tobis/ciseps.pdf You do not explain why a properly duck-typed pure Python wrapper of a complex number fails to achieve those objectives in your case. Calling it an "API" issue appears to me to miss my point. You can present the identical API with a wrapper as with a native extension, and stay out of the mathematician's way altogether, no? If not, why not? Note that when you stray from pure python you shrink your user base and complicate your support issues substantially. I would be happy to discuss the topic, but this requires that I approach the design with due skepticism. If you don't care to explain your needs you can't expect many useful answers, though I think it's reasonable to expect fewer and shorter non-useful ones! Michael ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: Arthur [mailto:[EMAIL PROTECTED] > >These kinds of API issues, tied to the program's intent, are > >- IMO - necessary soft, and folks can disagree about what > >works. I decided this was serious enough not only to make > >the effort to implement, but to sacrifice performance on its behalf. And maybe even more to the point than that - since this is the way that *I* was thinking about these objects - I wanted my conception of the object and their implementation to be as closely and purely allied as possible. With the instinct that doing so would lead me to where I should be going next. Which I think it has. Not textbook, to be sure. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: Arthur [mailto:[EMAIL PROTECTED] > > > >Because it didn't *feel* yet that I couldn't come up with > >something better, that I was at the end of the road. No > >question, it was workable - and if I was being paid to do > >this work by the hour it would have been some form of sin to > >look further. But I'm not. I bit more to the point, is I that I consider it an API issue, but an API issue specific to the intent of PyGeo - and that is to allow people to use and extend it as much as possible thinking as geometers and mathematicians and math students rather than as programmers. And there seemed to me something much more natural about saying- think of this *as* a complex number rather than think about wrapping something within a something else. These kinds of API issues, tied to the program's intent, are - IMO - necessary soft, and folks can disagree about what works. I decided this was serious enough not only to make the effort to implement, but to sacrifice performance on its behalf. Judgment call. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: Michael Tobis [mailto:[EMAIL PROTECTED] > >So unless there's a performance issue I can't see what you > >lose by wrapping the complex number. My last friend oh well. Because it didn't *feel* yet that I couldn't come up with something better, that I was at the end of the road. No question, it was workable - and if I was being paid to do this work by the hour it would have been some form of sin to look further. But I'm not. ;) Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> And I can't easily explain why I felt the need to push it a step further - Do give it a try, please. > to in fact having a more truly full implementation of complex numerics > contained *as* my object - not as an attribute of it. But there were > reasons. Some more practical, more less. Well, if you do it right, the enclosing code would not be different from that of a "truly full" implementation. That's why we use objects in the first place! The rest of the code should need no information about how you implement your mutable complex type. So unless there's a performance issue I can't see what you lose by wrapping the complex number. mt ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Michael Tobis > >objects than values. > > > >So, is there a problem with wrapping them thus: > > > >### > >class mcx(object): > > > > def __init__(self,val): > > self.val = complex(val) > > > > def __add__(self,other): > > """ and similarly for most other special methods """ > > return self.val.__add__(other) >### > > > >I think Arthur would duckishly call this a mutable complex > >type and others would more formally call it an object > >containing a reference to an immutable complex type and we > >could all live happily ever after. Not so easy, I'm afraid. If I am understanding correctly the implementation that you are suggesting is exactly the one I had one generation ago. Kind of the UserArray solution. No? And I can't easily explain why I felt the need to push it a step further - to in fact having a more truly full implementation of complex numerics contained *as* my object - not as an attribute of it. But there were reasons. Some more practical, more less. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Arthur > > > >What was "creepy" - *I thought* - was the concept of > >mutable complex number as a type, in the same sense that any > >class is a type. Just so that I am not accused of being disingenuous. That subject of primitive type was raised early in the discussion, but only intended in the context of the fact that Numeric arrays were prepared to except the immutable built-ins as complex numbers and unprepared to accept the custom class that was the same but mutable, as such. It presented a practical problem to me, and I was looking for practical solutions to it beyond the one had I been working with but found not fully satisfactory. But to repeat - The course of these discussions had some real practical value to me, having helped me come upon an idea for the implementation of the objects of the complex plane geometric objects that I think better reflects the ground of the mathematical ideas being explored, and with less of a performance trade-off. I could not want more, and I just hope I am not missing anything important by being excited about getting to the implementation. The small problem at the moment being the laptop on which I have my latest working version ain't taking well to getting powered up. ARG., Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
The following, modulo a pronoun shift were exactly the words I was sitting down to type. > I am not designing a programming language, I am designing an application. That is why, to me, the advice offerred to date seems quite far off the mark. > And bingo - for that application I need them to be more objects than values. So, is there a problem with wrapping them thus: ### class mcx(object): def __init__(self,val): self.val = complex(val) def __add__(self,other): """ and similarly for most other special methods """ return self.val.__add__(other) ### I think Arthur would duckishly call this a mutable complex type and others would more formally call it an object containing a reference to an immutable complex type and we could all live happily ever after. If I am right then the vast verbiage expended on this thread so far deflates into exactly nothing. If this is inadequate for anyone, what exactly is the problem? mt ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Scott David Daniels > > > >Arthur wrote: > >> > >> ... > >> Isn't the creation of any class the creation of one's own > >type? Now > >> what am I missing now? > >Ahh, I thought we were talking about language primitives. I guess I have the advantage that this is abstract to everybody else, quite concrete to myself as the class we are talking about is created, in use, and doing its thing. And it is possible - just possible - that people who have never had use for this kind of class might not have ever created dynamic, graphical applications of just the PyGeo kind. Not surprising, because not many people have. Maybe for good enough reason- but that's a separate issue. What was "creepy" - *I thought* - was the concept of mutable complex number as a type, in the same sense that any class is a type. Because what else could we be talking about, since I am designing only an application, not a programming language. And if the consensus now needs to shift to one that I am amateurishly out-of-my-mind to think that this could quite reasonably be a serviceable class *for just the kind of application on which I happen to be working* - let-it-be-so. > >It is not, except for one thing: one often thinks of complex > >numbers as values, and when they are mutable, they are more > >objects than values. I am not designing a programming language, I am designing an application. And bingo - for that application I need them to be more objects than values. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
Hello Scott, In C++ we have a saying for value types, such as complex numbers: "Do as the ints do". The complex class in C++ is also immutable. I have never seen a need for mutable numeric, scalar quantities since I began scientific programming 30 years ago. Just a perspective. Friday, March 17, 2006, 5:23:08 PM, you wrote: SDD> [EMAIL PROTECTED] wrote: >> Instead of having my geometric objects of the complex plane *be* complex >> numbes, >> there is certainly the solution of having a complex number as an attribute >> of these objects - >> and then I can take more your approach, and at the speed of C, since I would >> then >> be using the built-in for arithmettic operations. >> >> There remained something unsatisfying to me about that approach. >> >> Until something blows up about my current approach, I am quite happy with >> it. SDD> The thing that typically blows up is when you are (for example) SDD> computing with a complex number that is changed halfway through SDD> the computation by another thread (say a mouse drag). The square SDD> root winds up being neither the square root of the original number SDD> nor of the new changed number. Further, it becomes dicey to SDD> try to prove that your square root function will always terminate SDD> (a step size from one that is guaranteed to settle might be a SDD> disaster at the new-improved value. SDD> So, that's why CS people like immutable primitive types. SDD> -- Scott David Daniels SDD> [EMAIL PROTECTED] SDD> ___ SDD> Edu-sig mailing list SDD> Edu-sig@python.org SDD> http://mail.python.org/mailman/listinfo/edu-sig -- Best regards, Chuck ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
Arthur wrote: > > ... > Isn't the creation of any class the creation of one's own type? Now what am > I missing now? Ahh, I thought we were talking about language primitives. The range of behavior for non-primitives is larger. For example, a Vertex in 3-space for a polyhedron might have mutable x, y, and z properties just so that shared points and coincident points are distinguished. > My class - unless I am missing something else - does complex mathematics > exactly as does the built-in type. But it is now the Complex type, say. > Which allows me to say a=Complex(5,3) on creation, and a.real = 6 somewhere > down the line. Obviously notation ally, a=5 +3j will still return the Python > immutable built-in type. Which is fine by me. I thought you had been asking why it was wrong to make a primitive mutable. > That's exactly why I am having so much trouble with the problem I seem to be > causing here. I understand next to nothing about threading, but can't > understand why this particular class is any less safe than any other class > one might create and use. It is not, except for one thing: one often thinks of complex numbers as values, and when they are mutable, they are more objects than values. It is dangerous in that users of the type may have wrong intuitions. > ...But no, *don't* like to give up performance, and have been happy to have > had > a discussion that led me to a possible alternative that is prettier, *and* > faster. OK, so one big performance gain is that immutable values can be safely shared, a copy is never a meaningful operation on an immutable type. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: Laura Creighton [mailto:[EMAIL PROTECTED] > >Sent: Saturday, March 18, 2006 3:01 PM > >To: Arthur > > > >I'm confused too. > > > >It sounds to me that you want to invent your own type. Does > >your type have any relationship to the complex numbers that > >we know and love, or do you just want a type that has 2 parts? > > > >In particular, check out: > >http://home.scarlet.be/~ping1339/complget.htm#Polar-representation > > > >Do you want this > > > >a + ib = r (cos(t) + i sin(t)) > > > >to be true for your type as well? I think so. Isn't the creation of any class the creation of one's own type? Now what am I missing now? My class - unless I am missing something else - does complex mathematics exactly as does the built-in type. But it is now the Complex type, say. Which allows me to say a=Complex(5,3) on creation, and a.real = 6 somewhere down the line. Obviously notation ally, a=5 +3j will still return the Python immutable built-in type. Which is fine by me. That's exactly why I am having so much trouble with the problem I seem to be causing here. I understand next to nothing about threading, but can't understand why this particular class is any less safe than any other class one might create and use. Use cases? Seems to me to be a totally separate and different issue. One that, for example, Michael was skeptical about from the beginning. But that really doesn't seem to me to be what the discussion has been about - at least the discussion that others seem to want to have. >From the use case point of view, I have retained my own skepticism, as I tried to make clear. I had my reasonable reasons to go in that direction, I think. But there wasn't any really, really deep soul searching, precisely because there didn't seem to be anything at all unusual about the idea of this kind of class compared to others I might create and use as a matter of course - despite that there was a similar built-in. But no, *don't* like to give up performance, and have been happy to have had a discussion that led me to a possible alternative that is prettier, *and* faster. Ain't Edu-sig cool ;) Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
Arthur wrote: > > >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Arthur >>> Sent: Saturday, March 18, 2006 1:39 PM >>> To: 'Scott David Daniels'; edu-sig@python.org > >>> I don't understand, really, the distinction >>> between a vector expressed as a list and a vector expressed >>> as a tuple, from the concept of a complex number in mutable >>> form, and one in immutable form. >>> >>> If you feel like trying to help... > > > Put another way, if I take the PyPy implementation of the complex primitive, > and comment out the 2 property lines that restrict the write to real and > imag - and instead of calling it a primitive I call it a class. And I use > the class as such - where have I gone wrong? > > Art OK, so as I said in my over-long thing, immutable types have an exciting property that you can't really tell aliases from copies. This makes Python's call method behave a lot like "call-by-value" -- a good thing, since call-by-value is easy to analyze (both for machines and humans). With mutables, you have the question of "caller-saves" or "callee-saves" in function calls. Caller-saves makes a copy to do the call with, and callee-saves makes a copy on function entry (at least for those args for which there will be mutation). Typically, a lot of effort (either by the compiler or the programmer) is expended to keep all of this copying to a minimum. With immutables, you needn't do any of the bookkeeping. It is not that you have gone terribly wrong; it is that you have opened the lid on a large class of avoidable problems. If you look at Java's strings (as I remember -- it has been forever since I studied Java at all), you will find they are mutable. You also find that Java code copies strings a _lot_, just to be safe against lower- level mutation. Your primitive complex (the mutable one) also could not be used as a dictionary key except by identity, which would not allow rapid access. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
In a message of Sat, 18 Mar 2006 14:11:03 EST, Arthur writes: >> >-Original Message- >> >From: [EMAIL PROTECTED] >> >[mailto:[EMAIL PROTECTED] On Behalf Of Arthur >> >Sent: Saturday, March 18, 2006 1:39 PM >> >To: 'Scott David Daniels'; edu-sig@python.org > >>>I don't understand, really, the distinction >> >between a vector expressed as a list and a vector expressed >> >as a tuple, from the concept of a complex number in mutable >> >form, and one in immutable form. >> > >> >If you feel like trying to help... > > >Put another way, if I take the PyPy implementation of the complex primiti >ve, >and comment out the 2 property lines that restrict the write to real and >imag - and instead of calling it a primitive I call it a class. And I use >the class as such - where have I gone wrong? > >Art I'm confused too. It sounds to me that you want to invent your own type. Does your type have any relationship to the complex numbers that we know and love, or do you just want a type that has 2 parts? In particular, check out: http://home.scarlet.be/~ping1339/complget.htm#Polar-representation Do you want this a + ib = r (cos(t) + i sin(t)) to be true for your type as well? I think so. I'm worried that when you start mutating the type -- as opposed to simply assigning new values to it -- you can create a state where this is _not_ true. Am I wrong? Laura ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Arthur > >Sent: Saturday, March 18, 2006 1:39 PM > >To: 'Scott David Daniels'; edu-sig@python.org >>I don't understand, really, the distinction > >between a vector expressed as a list and a vector expressed > >as a tuple, from the concept of a complex number in mutable > >form, and one in immutable form. > > > >If you feel like trying to help... Put another way, if I take the PyPy implementation of the complex primitive, and comment out the 2 property lines that restrict the write to real and imag - and instead of calling it a primitive I call it a class. And I use the class as such - where have I gone wrong? Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Scott David Daniels > >Sent: Saturday, March 18, 2006 1:03 PM > >To: edu-sig@python.org > >Subject: Re: [Edu-sig] Properties use case > > > >Arthur wrote: > >Some of the questions feel a lot like, "why so many planar > >surfaces in architecture;" to answer them requires work, not > >simply in the saying, but in looking back for the whys. > >Often the first answer "it makes my skin crawl" is the real > >answer; some rule has become so internalized you don't know > >why you feel it. It doesn't necessarily mean Kirby was > >saying you had done an incredibly stupid thing; it might > >simply mean that something about that as design felt > >dangerous to him in some way. Can we allow this to be about the communication between teacher and student, and me be the student recognizing that the teacher has the knowledge he seeks, but frustrated... Because it is probably exactly my inability to phrase the question properly - I'm just a student - that leads to the problem. But if I was able to ask the question exactly properly, I probably wouldn't need to ask it - I would probably already have the answer. So I am recognizing that *I* am the source of the problem, in this sense. But that doesn't make the problem go away. Or allow us the say that the process is working. Intuitively, there is something qualitatively different - float as primitive, complex number as primitive. Simply a wrong intuition? Nothing lying beneath it? >From where I sit it looks that one might choose to express a 3 element vector as a tuple or one might choose to express is as a list, or even more likely a mutable array. And while suspecting that one can get into religious arguments about the matter, in practice smart people can be found doing either or both. I don't understand, really, the distinction between a vector expressed as a list and a vector expressed as a tuple, from the concept of a complex number in mutable form, and one in immutable form. If you feel like trying to help... Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
Arthur wrote: > ... But if we trace back the thread we will see that the bottom line question > that I was struggling with at the beginning was precisely the question of > what *makes* a primitive type such. Obviously something much deeper than the > fact that it is coded in C. Well, if it hadn't been buried in a hail of words, it would have been more obvious to the readers as well as the writer. I'll try to talk from the point of view of a language designer. Typically, a computer language is developed to solve some kind of problem (or family of problems). The primitives must be enough to express, succinctly, problems in that space and parts of solutions to those problems. You'd be surprised at the variety of things people want to express. It used to be commonly accepted that "little languages" was the way to attack this problem. A new problem space meant building a "little language" to express its problems and solutions. However, it turns out that these "little languages" have this "feeping creaturism" problem; the users often want "just a bit more" added until the language (which was once nice and small and tidy) seems to be all bolts and knobs and corners where unanticipated extensions got thrown on to solve "just one problem." Also, the number of people capable of building, supporting, and extending a language is not huge in comparison to the number of problem spaces. Experience in building languages has shown us that the more "distinct" things in the language, the harder it is to learn, use, and remember. Here I am not talking about the complexity of the compiler/interpreter/language translation system, but the amount of "stuff" a _user_ of the language needs to know about the language. The fewer things a user has to track mentally, the "simpler" the language. So, here is a tension: we want a simple language that can express succinctly problems and (effective) solutions to problems. The simpler the language, the more quickly you can become expert in the language, and move on to the problems you really want to solve. The more expressive the language, the simpler your programs in your field of discourse. We do know that program complexity grows _significantly_ worse than linearly with the size of a program, so we want the programs the user writes to be small to help him out. Often adding more to the language shrinks the users code, so there is a balancing act here. Here are some criteria for primitives. We want as few primitives as possible. We should add primitives for anything almost every user will need. In addition to those, we may add some primitives for those things that the user cannot build himself nearly as efficiently (or perhaps is very likely to get wrong). We probably need primitives for every "manifest constant" in a program (the 5 in "i *= 5"). Almost always, programs need a way to perform I/O (Knuth, in one class defined a computer program as something that took zero or more inputs and produced one or more outputs, on the grounds a rock implements anything that produces zero outputs). But programs that simply produce output, but consume no input are rare; ab initio chemists may write some of these. Usually the programs are to be operated by people other than those who wrote the programs, so they must consume input in some form. Input, output, and calculation all need to be expressed. Even if you have no intention of doing text processing, input and output almost force you to have a text type. Most calculation will want to do arithmetic (there are languages w/o arithmetic primitives). There must be a way to build data structures (combine our primitives), since the design and use of data structures is core CS (and the key to not having to build everything into the language). We need to be able to define functions (a way to decompose problems), and how functions and their results are combined is, finally, the probable answer to the mutability question. If every time you call a function it might mutate its arguments, safe practice is to copy any arguments to the function. Early FORTRAN said a procedure could change its arguments, and the change would be reflected in the calling program. So, after: pi = 3.1415297 somesub(pi, 3) the value of pi might be changed. Even worse, the program might change the value of 3 (the constant used in the compiled chunk of code for 3). The FORTRAN solution was to tell the programmer "don't do that." We now solve these problems either by using "pass-by-value" semantics (the subroutine gets a copy of its argument), or by passing immutable objects. So, it makes sense that manifest constants must be immutable in a language like Python that does call-by-sharing. Also you avoid another nasty problems called "aliasing". If you have a function like: def same_range(a, b): while a < b: a *= 2 while a >= b: a /= 2 return a Calling "same_range(lumberjacks, lumberjacks)"
Re: [Edu-sig] Thinking about my class...
> You could go:
>
> def makefunction():
> theletters = uppercase[:26] + ' '
> copyof = list(theletters) # reason: to allow a shuffle
> shuffle(copyof)
> return dict(zip(theletters, copyof))
I like it. Hadn't considered zipping a string with a list:
>>> zip('abc',['r','s','t'])
[('a', 'r'), ('b', 's'), ('c', 't')]
Kirby
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
