Re: [Python-ideas] aliasing
Le 31 août 2011 à 17:20, python-ideas-request@python.org a écrit :
I don't agree with you when you say there is no necessary use case, e.g. I have two images in a gui and they must stay at the same position (relatively one to the other) but follow the movements of the arrow keys (truthful!). You can't do it by using an intermediate list because the list object is mutable but his data not: ------------------------
I really don't see any other solution, even I'm sure it would be a twisted operation and I don't find it very pythonic... Amicalement, Peio
On Thu, Sep 1, 2011 at 6:19 AM, Peio Borthelle <peio.borthelle@gmail.com>wrote:
This little snippet is unsurprising and would be extremely surprising if it printed 6 instead.
If you don't see any other solution than you're not looking hard enough. What you're saying is you have objects in a gui which must be manipulated by simple variables rather than be encapsulated in a class. I don't buy it. How does this work with N objects which must lock together? I note that you say "relative to one another" so what you really mean is x2 locks to x1 + A and y2 locks to x1 + B. That's not a simple alias. Can I assign to x2? If you think assigning to x2 will change x1, you haven't thought it through. If you think it won't but instead will break the alias, then what is the advantage of not just writing x2()?? You save two characters (and a lambda somewhere else) at the expense of making the code much harder to understand. It's like a programmer building a spreadsheet app in Python saying this is the only way he can implement cell recalc. Fortran has a statement called COMMON which aliases variables. It's useful for reshaping arrays. Other than that, it's an easy way to confuse programmers and the compiler. --- Bruce
On 9/1/2011 11:38 AM, Bruce Leban wrote:
You put them in a frame so that their positions are relative to a frame rather than absolute pixel positions. Then you move the frame. Relative positioning is fundamental to computer graphics.
What you're saying is you have objects in a gui which must be manipulated by simple variables rather than be encapsulated in a class.
The position should be an attribute of a class and relative to something.
Fortran has a statement called COMMON which aliases variables.
This works because in Fortran a 'variable' is a block of memory. As I remember, COMMON says to reuse memory for different variables.
-- Terry Jan Reedy
Terry Reedy wrote:
This works because in Fortran a 'variable' is a block of memory. As I remember, COMMON says to reuse memory for different variables.
Also I think in early versions of Fortran it was the only way of sharing variables between subroutines, because there was no concept of a global namespace -- each subroutine was compiled independently, even if they were in the same source file. -- Greg
Stephen J. Turnbull wrote:
I don't see the connection. The first proposal for Fortran was 1953, with the first public release in 1957, while John McCarthy didn't start work on Lisp until 1958. I'm not sure when a Lisp compiler was first available, but there's no doubt that Fortran pre-dates Lisp. But even if it didn't, there's no logical inconsistency between Lisp using stack allocation and Fortran not. (There's no evidence that I can see that either language influenced the other directly.) -- Steven
Steven D'Aprano writes:
He didn't start work on Lisp the language, or Lisp the interpreter? The language existed for some time before it occurred to people to implement an interpreter, but implementing the interpreter was fairly quick once somebody thought of it as I understand it. After all, once you have the read-eval-print loop, lambda, cond, cons, car, cdr, a data structure for symbols, and a data structure for the environment that supports recursion (thanks to Bruce Leban for pointing out off-list that this was an association list, not local variables on the stack), you can define everything else from that. AFAIK the public release of FORTRAN and the academic introduction of a Lisp interpreter were pretty much simultaneous.
As quoted above, "stack allocation" refers to the concept, not its use in FORTRAN. There are lots of concepts that existed for decades before being implemented in Fortran.[1] I was just curious whether this was one of them. I'll go see if the Dragon Book has anything to say about it. Footnotes: [1] Just as some concepts have waited for decades to be implemented in Python. I suspect "alias" is one that will have to wait for a lot more decades! Back on topic! Whee!
Stephen J. Turnbull wrote:
Define "start work on" :) At what point do idle musings about a possibility become actual work? According to McCarthy, early key ideas and experiments in Lisp occurred between 1956 and 1958, some of which using a Fortran-based back end (so I was wrong to say there was no connection -- McCarthy was certainly aware of Fortran and at least mildly influenced by its "formula translation" aspect). Between 1958 and 1962 Lisp was implemented and used for experiments in AI. http://www-formal.stanford.edu/jmc/history/lisp.ps In Fortran's case, I haven't been able to find when John Backus first started thinking about the idea, but he submitted a proposal to IBM in late 1953. A draft specification followed in 1954, followed by a manual in 1956 and finally a compiler in 1957. I guess the pace of computer software releases was slower back then, and people more forgiving of vapourware. <wink> -- Steven
Stephen J. Turnbull wrote:
If FORTRAN [sic] predated stack allocation, what did Lisp use to handle recursion?
According to Wikipedia, the first Lisp implementation was an interpreter written in machine code, not Fortran. However, even if an interpreter were written in Fortran, it wouldn't be constrained by Fortran's limitations, any more than CPython is contstrained by C's limitations. -- Greg
Peio Borthelle wrote:
I didn't say that there *is* no use-case, only that I have never found one. Perhaps you have misunderstood the English idiom "Without a convincing use-case...". This isn't meant to imply that there is no use-case, only that nobody has yet found one. The implication is that, if you wish to promote this change to Python's behaviour, showing a convincing use-case is a necessary first step. (But not the only step.) -- Steven
On Sep 1, 11:19 pm, Peio Borthelle <peio.borthe...@gmail.com> wrote:
While I think that Terry's suggestion of a frame object that takes care of the movement is the better approach, you can also use the package Trellis to keep object attributes in lockstep (amongst other features). http://pypi.python.org/pypi/Trellis
On Thu, Sep 1, 2011 at 6:19 AM, Peio Borthelle <peio.borthelle@gmail.com>wrote:
This little snippet is unsurprising and would be extremely surprising if it printed 6 instead.
If you don't see any other solution than you're not looking hard enough. What you're saying is you have objects in a gui which must be manipulated by simple variables rather than be encapsulated in a class. I don't buy it. How does this work with N objects which must lock together? I note that you say "relative to one another" so what you really mean is x2 locks to x1 + A and y2 locks to x1 + B. That's not a simple alias. Can I assign to x2? If you think assigning to x2 will change x1, you haven't thought it through. If you think it won't but instead will break the alias, then what is the advantage of not just writing x2()?? You save two characters (and a lambda somewhere else) at the expense of making the code much harder to understand. It's like a programmer building a spreadsheet app in Python saying this is the only way he can implement cell recalc. Fortran has a statement called COMMON which aliases variables. It's useful for reshaping arrays. Other than that, it's an easy way to confuse programmers and the compiler. --- Bruce
On 9/1/2011 11:38 AM, Bruce Leban wrote:
You put them in a frame so that their positions are relative to a frame rather than absolute pixel positions. Then you move the frame. Relative positioning is fundamental to computer graphics.
What you're saying is you have objects in a gui which must be manipulated by simple variables rather than be encapsulated in a class.
The position should be an attribute of a class and relative to something.
Fortran has a statement called COMMON which aliases variables.
This works because in Fortran a 'variable' is a block of memory. As I remember, COMMON says to reuse memory for different variables.
-- Terry Jan Reedy
Terry Reedy wrote:
This works because in Fortran a 'variable' is a block of memory. As I remember, COMMON says to reuse memory for different variables.
Also I think in early versions of Fortran it was the only way of sharing variables between subroutines, because there was no concept of a global namespace -- each subroutine was compiled independently, even if they were in the same source file. -- Greg
Stephen J. Turnbull wrote:
I don't see the connection. The first proposal for Fortran was 1953, with the first public release in 1957, while John McCarthy didn't start work on Lisp until 1958. I'm not sure when a Lisp compiler was first available, but there's no doubt that Fortran pre-dates Lisp. But even if it didn't, there's no logical inconsistency between Lisp using stack allocation and Fortran not. (There's no evidence that I can see that either language influenced the other directly.) -- Steven
Steven D'Aprano writes:
He didn't start work on Lisp the language, or Lisp the interpreter? The language existed for some time before it occurred to people to implement an interpreter, but implementing the interpreter was fairly quick once somebody thought of it as I understand it. After all, once you have the read-eval-print loop, lambda, cond, cons, car, cdr, a data structure for symbols, and a data structure for the environment that supports recursion (thanks to Bruce Leban for pointing out off-list that this was an association list, not local variables on the stack), you can define everything else from that. AFAIK the public release of FORTRAN and the academic introduction of a Lisp interpreter were pretty much simultaneous.
As quoted above, "stack allocation" refers to the concept, not its use in FORTRAN. There are lots of concepts that existed for decades before being implemented in Fortran.[1] I was just curious whether this was one of them. I'll go see if the Dragon Book has anything to say about it. Footnotes: [1] Just as some concepts have waited for decades to be implemented in Python. I suspect "alias" is one that will have to wait for a lot more decades! Back on topic! Whee!
Stephen J. Turnbull wrote:
Define "start work on" :) At what point do idle musings about a possibility become actual work? According to McCarthy, early key ideas and experiments in Lisp occurred between 1956 and 1958, some of which using a Fortran-based back end (so I was wrong to say there was no connection -- McCarthy was certainly aware of Fortran and at least mildly influenced by its "formula translation" aspect). Between 1958 and 1962 Lisp was implemented and used for experiments in AI. http://www-formal.stanford.edu/jmc/history/lisp.ps In Fortran's case, I haven't been able to find when John Backus first started thinking about the idea, but he submitted a proposal to IBM in late 1953. A draft specification followed in 1954, followed by a manual in 1956 and finally a compiler in 1957. I guess the pace of computer software releases was slower back then, and people more forgiving of vapourware. <wink> -- Steven
Stephen J. Turnbull wrote:
If FORTRAN [sic] predated stack allocation, what did Lisp use to handle recursion?
According to Wikipedia, the first Lisp implementation was an interpreter written in machine code, not Fortran. However, even if an interpreter were written in Fortran, it wouldn't be constrained by Fortran's limitations, any more than CPython is contstrained by C's limitations. -- Greg
Peio Borthelle wrote:
I didn't say that there *is* no use-case, only that I have never found one. Perhaps you have misunderstood the English idiom "Without a convincing use-case...". This isn't meant to imply that there is no use-case, only that nobody has yet found one. The implication is that, if you wish to promote this change to Python's behaviour, showing a convincing use-case is a necessary first step. (But not the only step.) -- Steven
On Sep 1, 11:19 pm, Peio Borthelle <peio.borthe...@gmail.com> wrote:
While I think that Terry's suggestion of a frame object that takes care of the movement is the better approach, you can also use the package Trellis to keep object attributes in lockstep (amongst other features). http://pypi.python.org/pypi/Trellis
participants (8)
-
alex23 -
Bruce Leban -
Greg Ewing -
MRAB -
Peio Borthelle -
Stephen J. Turnbull -
Steven D'Aprano -
Terry Reedy