| 15 | | To fix this: it seems that a lot of the really bad magic (looking at module names etc.) is there for convenience (i.e., that a !FiniteSet is a Set with the Finite axiom). Most of that could be rewritten/ripped out at relatively low cost and inconvenience and would make the code a lot more maintainable and understandable for most non-original-authors, so when Nicholas looks at this (he's the only one who has a chance of being able to fix this stuff) I hope he will consider rewriting the more esotheric stuff. I think there are a lot of potential contributors who can appreciate if the fundamental infrastructure of Sage continues to read like python code if at all possible. The code here looks amazingly ingenious and smart, but unfortunately that is not a desirable trait for basic infrastructure that needs to be maintained for a long time and by many people. |
| | 15 | To fix this: it seems that a lot of magic (looking at module |
| | 16 | names etc.) is there for convenience (i.e., that a !FiniteSet is a Set with the |
| | 17 | Finite axiom). Perhaps it's worthwhile to consider coding these bits a little |
| | 18 | more conservatively, exchanging some convenience for enhanced maintainability. |
| 17 | | I think the bug/behaviour we're running into now illustrates why "smart" code is often not a good idea: as we see here, the behaviour is hard to predict. |
| | 20 | When Nicholas looks at this (he's the only one who has a chance of being able to |
| | 21 | fix this stuff) I hope he will reconsider some of the design decision. I think |
| | 22 | there are a lot of potential contributors who can appreciate if the fundamental |
| | 23 | infrastructure of Sage continues to read like a little more normal python code |
| | 24 | if at all possible. |
| | 25 | |
| | 26 | The code here looks amazingly ingenious and smart, but unfortunately that is not |
| | 27 | a desirable trait for basic infrastructure that needs to be maintained for a |
| | 28 | long time and by many people. |
| | 29 | |
| | 30 | I think the bug/behaviour we're running into now illustrates why "smart" code is |
| | 31 | often not a good idea: as we see here, the behaviour can be hard to predict. |
