Re: Goto (Posting On Python-List Prohibited)
Sorry, delete string "n't". I mean that you would strcuture your code with that architecture. Hate that. marxos On 1/1/18, John Q Hacker wrote: >>> I don’t use gotos in C code. Why should it be “harder” in a higher-level >>> language? >> >> Good for you. >> >> Looking at 14 million lines of Linux kernel sources, which are in C, >> over 100,000 of them use 'goto'. About one every 120 lines. > > Most use of goto's implies a lack of understanding of the unseen > architecture of the problem domain itself (otherwise, you wouldn't > have structured your program with that architecture). The only > remaining use is optimization, and most of that is probably premature, > as use of gotos *can* make things hard to understand, but using labels > is a pretty happy medium. > > Marxos > -- https://mail.python.org/mailman/listinfo/python-list
Re: Goto (Posting On Python-List Prohibited)
>> I don’t use gotos in C code. Why should it be “harder” in a higher-level >> language? > > Good for you. > > Looking at 14 million lines of Linux kernel sources, which are in C, > over 100,000 of them use 'goto'. About one every 120 lines. Most use of goto's implies a lack of understanding of the unseen architecture of the problem domain itself (otherwise, you wouldn't have structured your program with that architecture). The only remaining use is optimization, and most of that is probably premature, as use of gotos *can* make things hard to understand, but using labels is a pretty happy medium. Marxos -- https://mail.python.org/mailman/listinfo/python-list
code blocks
Hello, I'm thinking how interesting it would be to add code blocks to Python, so that arbitrary strings of code can be passed around. It would open up some interesting possibilities for self-modifying code and generic programming. Since Python has already a plethora of ambiguous string designations, one of them could be set aside specificially for code blocks: """for i in n: print i""" For any variables, like "n", it would access the scope in which it was running. When you tried to print a triple-double-quoted code block, perhaps it could invoke the code. My suggestion would be to use triple double-quoted strings. You probably already know that Ruby has code blocks. zipher -- https://mail.python.org/mailman/listinfo/python-list
mix-in classes
The post on "different types of inheritence..." brought up a thought. Let's say, I'm adding flexibility to a module by letting users change class behaviors by adding different mix-in classes. What should happen when there's a name collision on method names between mix-ins? Since they're mix-ins, it's not presumed that there is any parent class to decide. The proper thing would seem to call each method in the order that they are written within the parent class definition. I suppose one can create a method in the parent class, that runs the mixin methods in the same order as in the inheritance list, but would there be a better way for Python to enforce such a practice so as not to create class anarchy? (A problem for another topic.) zipher -- https://mail.python.org/mailman/listinfo/python-list
Re: mix-in classes
On Sun, May 24, 2015 at 6:11 AM, Steven D'Aprano wrote: > On Sun, 24 May 2015 11:53 am, Dr. John Q. Hacker wrote: > But, frankly, what you describe is more likely to be a weakness of multiple > inheritance and mixins, one which should be avoided. One attempt to avoid > this problem is with traits, an alternative to mixins which explicitly > deals with the problem of mixin conflicts. > > http://www.artima.com/weblogs/viewpost.jsp?thread=246488 > Interesting. This brings up an issue another poster brought up: In my usage of the term "parent", I use it to mean the class that is a product of object composition: class Parent(child1, child2): pass I figure that it is this "Parent" class which must manage the methods that it is inheriting with child1 and child2 -- mixins or otherwise. In this usage, super() should be called "delegate" as whatever I don't accomplish in my specialized Parent class, I will get the child classes to do. Python automagically delegates any methods that I don't define in Parent to methods found in child1 and child2. It seems the issues that everyone encounters with multiple inheritance, mixins, and such has more to do with terminology (and proper implementation) than in actuality. zipher -- https://mail.python.org/mailman/listinfo/python-list
