python file API
For some time now, I've wanted to suggest a better abstraction for the type in Python. It currently uses an antiquated C-style interface for moving around in a file, with methods like tell() and seek(). But after attributes were introduced to Python, it seems it should be re-addressed. Let file-type have an attribute .pos for position. Now you can get rid of the seek() and tell() methods and manipulate the file pointer more easily with standard arithmetic operations. >>> file.pos = x0ae1 #move file pointer to an absolute address >>> file.pos +=1#increment the file pointer one byte >>> curr_pos = file.pos #read current file pointer You've now simplified the API by the removal of two obscure legacy methods and replaced them with a more basic one called "position". Thoughts? markj -- http://mail.python.org/mailman/listinfo/python-list
Re: python file API
You raise a valid point: that by abstracting the file pointer into a position attribute you risk "de-coupling" the conceptual link between the underlying file and your abstraction in the python interpreter, but I think the programmer can take responsibility for maintaining the abstraction. The key possible fault will be whether you can trap (OS-level) exceptions when assigning to the pos attribute beyond the bounds of the actual file on the system... markj -- http://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Sunday, May 10, 2015 at 11:44:36 AM UTC-5, Ian wrote: > On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen > wrote: > > Here's something that might be wrong in Python (tried on v2.7): > > > class int(str): pass > > This defines a new class named "int" that is a subclass of str. It has > no relation to the builtin class int. > > int(3) > > '3' > > This creates an instance of the above "int" class, which is basically > equivalent to calling "str(3)". > > Were you expecting a different result? Sorry, yes. If you're going to define a concept called "keywords", I don't think you should allow them to be shadowed by a class definition. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Sunday, May 10, 2015 at 7:20:13 PM UTC-5, Mark Lawrence wrote:
> On 11/05/2015 01:14, Mark Rosenblitt-Janssen wrote:
> > In case the example given at the start of the thread wasn't
> > interesting enough, it also works in the other direction:
> >
> class str(int): pass
> >
> str('2')
> > 2 #<- an integer!!!
> >
> > Mark
> >
>
> Thanks for this, I've not found anybody new for my dream team in months.
Sorry, I forgot I unsubscribed from the mailing list and didn't see any replies
and deduced that no one had noticed anything unexpected about the idea.
I guess everyone expects this behavior since Python implemented this idea of
"everything is an object", but I think this branch of OOP (on the branch of the
Tree of Programming Languages) has to be chopped off. The idea of everything
is an object is backwards (unless your in a LISP machine). Like I say, it's
trying to be too pure and not practical.
Whatever,
Mark
--
https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Sunday, May 10, 2015 at 3:43:25 PM UTC-5, Chris Seberino wrote: > Instead of learning only Scheme or only Python for a one semester intro > course, what about learning BOTH? Maybe that could somehow > get the benefits of both? > > I'm thinking that for the VERY beginning, Scheme is the fastest language > to get beginners up and running writing code due to the extremely minimal > simple syntax. > > I'm thinking half way into the semester, instead of moving into intermediate > Scheme, perhaps that is a good time to switch to Python? > > Would a little strong intro to 2 nice languages in one semester be > same/good/worse/better than just 1? No. LISP-like languages are very different beasts, requiring different mind-sets. It's like going from geometry to arithmetic. Or trying to teach OS/2 (which had great abstract ideas) and switching to Linux without covering the architecture and engineering underneath them. mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
> Huh? Python has plenty of keywords, and indeed, none of them can be > redefined or shadowed.But you would gain nothing (and lose a bit or > dynamic-language freedom) by making int a keyword. Okay. I apologize for thinking in C and believing "int" was a keyword. It isn't in Python as you remind me. However, this is where I'm arguing the purity has hammered practicality into the ground. Python is trying to be as elegant as LISP in trying to make everything an Object. It's not necessary, and it's trying to put lipstick on a pig instead of making BBQ. Python will be as elegant, but in a different direction of the axis. That difference is exactly like how Philosophy is different from Math -- both require logic, but go in different directions with it. Python makes classes, when LISP tries to make classes to try to be like C++ it also looks equally stupid. So don't do it. Let them be different specializations. mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
> > Instead of learning only Scheme or only Python for a one semester intro > > course, what about learning BOTH? Maybe that could somehow > > get the benefits of both? > > No. LISP-like languages are very different beasts, requiring different > mind-sets. It's like going from geometry to arithmetic. > > Or trying to teach OS/2 (which had great abstract ideas) and switching to > Linux without covering the architecture and engineering underneath them. Another point. You're allowing Church`s Thesis to misinform you. While, in theory, every programming language could be made into any other, the architecture in which to do so is completely different, so it misleads the programmer. To fit LISP into a Turing Machine architecture (what most every procedural programming language and most every computer sold is/utilizes) requires a very obscene translation table in the TM. I'm not even sure that it's been analyzed, because the TM has no concept of a stack. Any PhD's know of who's actually make a stack on the TM? Usually the tape itself holds the stack, but with LISP architecture, this isn't the natural fit. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: code blocks
> 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. > > My suggestion would be to use triple double-quoted strings. Hmmm. Would be interesting to do this: >>> codestr = decode(SomeClass) ...and have it return a triple-quoted string of the perhaps-reduced source for the class. It's like serialization of code objects, but the serialization is just the source string w/LFs that would re-make the object. Similarly, you'd want: >>> encode(codestr) to instantiate all objects in the codestr. You can't do this with eval, because it doesn't allow assignment (eval(n=2) returns "InvalidSyntax"). mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Confessions of a Python fanboy
> > 3.) true OOP > > Now before you go and get all "huffy" over this statement, hear me > > out. Python is the best language in the world. But it damn sure has > > some warts! "len(this)" instead of "obj.length" max(that) instead of > > [1,2,3,4,5].max(). > > As the Zen says: '[P]racticality beats purity'. Personally, I'm not > sure how a handful of convenient built-in functions make a language in > which _everything is an object_ somehow "false" OO. > > If you're really that concerned with writing "true" OO (for some > wildly variable value of "true"), there's nothing stopping you from > doing so now: > > obj.__len__() The issue is that Python currently blurs a very powerful conceptual boundary in CS -- between the abstract space where objects and variables are held and the concrete underlying machine. By having methods like len() in your built-in namespace when it's really only relevant to objects that are types of containers, you blur one primary component of OOP: encapsulation. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
> > Okay. I apologize for thinking in C and believing "int" was a keyword. It
> > isn't in Python as you remind me. However, this is where I'm arguing the
> > purity has hammered practicality into the ground.
> >
> > Python is trying to be as elegant as LISP in trying to make everything an
> > Object. It's not necessary, and it's trying to put lipstick on a pig
> > instead of making BBQ. Python will be as elegant, but in a different
> > direction of the axis.
>
> How is it a problem for an integer to be an object?
It's not any more of a problem than trying to put lipstick on a pig, but at
some point the pig might complain. In this case, it has to be faced that an
integer is a very concrete type -- because we're not running on a Symbolics
Machine.
Once again, Church's Thesis is misinforming people -- it doesn't matter that
you can do everything on everything -- at some point the rubber has to hit the
road and in Python, when I use an int, I expect some guarantee of O(log n)
behavior, because I assume the dev team hasn't done something stupid, like
implement bigints in LISP.
> In Python, I can
> put together a generic handler for a generic list and depend on
> everything being an object:
>
> lst = ["asdf", 2, lambda x: x+1, re.compile("q[a-tv-z]"), 3.14159]
Okay, Chris, now you've made a pig out of lipstick. The lipstick is lambda
expressions. We already know the BDFL opinion of them. The pig is whatever
that toy problem you just concocted is supposed to do.
> In Java, I would have to box up that integer 2 and that float 3.14159
> (and maybe the string too?) to make it possible to put them into a
> generic collection, because integers and objects are fundamentally
> different things.
No. Yes!? I mean no! They are different, but it's a type, even though (in this
thought experiment) it's not an object. And types can be put into collections
(hey just like C++!).
> In Python, ints and floats and strings all follow
> the same rules as other objects: they can be passed around, stored in
> collections, turned into strings with str() or repr(), etc, etc, etc.
But Chris, you are forgetting: Python could do all this before the type/class
unification.
> They have methods, they react to operators, everything is done
> according to a simple set of rules. This does not harm practicality -
> it's extremely helpful in a number of situations.
But you are infected with script-mind. Scriptmind is a disease, where no one
worries about the underlying architecture or the effects on machine
performance. This is fine for the web, but not for CPython. Many lost souls
have gone the way of Javascript and been infected. Perhaps you are one of them.
> And I still don't see how this has anything to do with your confusion
> about shadowing the name 'int'. As I see it, attempting to redefine
> int to be a null subclass of str should have one of two results:
> either it's a straight-up error, or it does exactly what happens in
> Python - calling 'int' now calls a subclass of 'str'.
It just blurs conceptual boundaries, something I call "SeparabilityOfDomains".
Mark
--
https://mail.python.org/mailman/listinfo/python-list
Re: Confessions of a Python fanboy
> Please take care of your quoting. You just quoted two other posts, and > I have no idea who said things without going and digging in the > archive. I'm sorry. I've been sleeping on the beach, away from civilization, a little too long, and didn't see that this was a post from 6 years ago. Feel free to disregard. Mark -- https://mail.python.org/mailman/listinfo/python-list
OFFTOPIC, WAS Re: Confessions of a Python fanboy
On Sunday, May 10, 2015 at 9:18:55 PM UTC-5, Chris Angelico wrote: > On Mon, May 11, 2015 at 12:11 PM, zipher wrote: > >> Please take care of your quoting. You just quoted two other posts, and > >> I have no idea who said things without going and digging in the > >> archive. > > > > I'm sorry. I've been sleeping on the beach, away from civilization, a > > little too long, and didn't see that this was a post from 6 years ago. > > > > Feel free to disregard. > > That actually has nothing to do with it. You're still quoting without > citation. Well, I replied right at the point of my correspondent (Alex23). If googlegroups isn't tracking that fact, it shouldn't put a reply button at every single message, but only at the end of the thread. > This is why Google Groups has such a bad reputation. I think it's time > for me to *plonk* you. I see. Someone should inform google not to put a reply after every post, but only at the end of a thread so users don't assume that it's tracking thread hierarchies. So you're point is apropos, if that's the case. In which case, my reply was to Alex23 who was replying to the OP's first post who goes by the name "r". Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday, May 11, 2015 at 1:11:26 AM UTC-5, Steven D'Aprano wrote: > On Monday 11 May 2015 10:57, zipher wrote: > > I guess everyone expects this behavior since Python implemented this idea > > of "everything is an object", but I think this branch of OOP (on the > > branch of the Tree of Programming Languages) has to be chopped off. The > > idea of everything is an object is backwards (unless your in a LISP > > machine). Like I say, it's trying to be too pure and not practical. > > Python is in production use in hundreds of thousands of organisations. It > has been heavily used for over twenty years, in everything from quick and > dirty one line scripts to hundred-thousand LOC applications. Yeah, so was COBOL. Boom. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday, May 11, 2015 at 9:03:43 AM UTC-5, Marko Rauhamaa wrote: > Antoon Pardon : > > > The point is that all too often someone wants to defend a specific > > choice the developers have made and cites some general rule or > > principle in support, ignoring the fact that python breaks that > > rule/principle in other area's. > > Granted, but you have set the trap for them by demanding a justification > when no justification was required. Every language has their cute > idiosyncrasies and arbitrary design choices. No. Here's where I must disagree. I think one can infer a goal for particular programming languages, even if it is subconscious. For example, with LISP it could be "generality". For C, it could be "staying as close to the machine as possible while maximizing the use to humans" -- contradiction that works because they've limited their architecture to VonNeumann (stackless) machines. I think the subconscious goal of OOP languages is to create a data ecosystem, starting with a unified data model under the realization that ultimately: all data relates to other data -- that my database of wind speed and direction from 2012 is relatable, by some finite number of hops, to your data on population growth in Chicago. Call it the "seven degrees of data" and remember the exabytes of data out there. Python is creating the perfect system for that because it has an interpreter environment with which to manipulate objects that could be retrieved on the net and sent back out. It has docstrings so that your foreign object can self-document, and doctests, so that I can be confident that your code works as *I* expect. There are reasons to have limits on programming freedom. It puts order to chaos. It guides the wily programmers into a particular train of thought. You don't override "True" because you'd be breaking one of the [explicit] goals of the language: readability. If there were no constraints, life itself could not exist. I don't think shadowing built-in types was a design choice but simply never got exercised because most people are used to handling such things, *subconsciously*, like C. To Mr. Gatti, my point was not an insult, it is a theoretical postulate in the domain of Computer Science. One that has not really been studied. OOP is still far from it's goal, so the field is still answering questions within it. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday, May 11, 2015 at 9:52:16 AM UTC-5, Skip Montanaro wrote: > Steven> Python is in production use in hundreds of thousands of > organisations. It > Steven> has been heavily used for over twenty years, in everything > from quick and > Steven> dirty one line scripts to hundred-thousand LOC applications. > > Mark> Yeah, so was COBOL. Boom. > > Your point being? That a billion lines of code doesn't equate to practicality. > The software development landscape has changed so much since the days > when COBOL was king of data processing that its popularity then had > less to do with some sort of software natural selection than IBM's > utter domination of the computing landscape in the 1960s. Yes, and I would argue that the OOP landscape has changed since the 1990s (with the rise of very high level languages like Python). The idea of "everything is an object" is an exploration of PL design that I'm claiming is not appropriate for whatever language will create this data ecosystem that I say is as inevitable as a single language being used on the Internet -- it's simply a chaotic attractor that is irresistible for it's sheer utility. I also bought the idea of everything as an object, it has a unbeatable purity to it. But we won't ever get to the point were OOP is like the purity of math because the greatest utility of OOP is working with real-world data. And that real-world puts bounds on the otherwise abstract purity in which a language is theoretically capable. Mark P.S. As Mr. Reedy said, please remove pydev from the To: line. This is the proper general rule when a discussion goes into abstractions, rather than practicality of development. -- https://mail.python.org/mailman/listinfo/python-list
Re: code blocks
On Sunday, May 10, 2015 at 10:32:07 PM UTC-5, Ian wrote:
> On Sun, May 10, 2015 at 7:39 PM, zipher wrote:
> > Similarly, you'd want:
> >
> >>>> encode(codestr)
> >
> > to instantiate all objects in the codestr. You can't do this with eval,
> > because it doesn't allow assignment (eval(n=2) returns "InvalidSyntax").
>
> Is exec what you're looking for?
>
> >>> exec('n = 2')
> >>> print(n)
> 2
Ah, yeah, I guess that does it. But (shame) it looks like you've gone past the
BDFL. Try:
>>> help(exec)
^
SyntaxError: invalid syntax
Better
Mark
--
https://mail.python.org/mailman/listinfo/python-list
Re: code blocks
On Monday, May 11, 2015 at 10:22:15 AM UTC-5, zipher wrote: > Ah, yeah, I guess that does it. But (shame) it looks like you've gone past > the BDFL. Try: > [...] > Better Oops, omit word "better". Sent before reading over it again... m -- https://mail.python.org/mailman/listinfo/python-list
Re: How to properly apply OOP in the bouncing ball code
On Friday, May 8, 2015 at 10:40:46 AM UTC-5, Tommy C wrote: > I'm trying to apply OOP in this bouncing ball code in order to have multiple > balls bouncing around the screen. The objective of this code is to create a > method called settings, which controls all the settings for the screen and > the bouncing behaviour of multiple balls, under the class Ball. However, I > keep on getting errors related to attributes (e.g., speed). I'm new to OOP in > Python so your help will be much appreciated. Thanks in advance. You are making a error that few in the programming community have caught up to. OOP design for *data abstraction* is a completely different beast that OOP for *simulation*. The confusion is around the use of the word "object" which both denotes a physical world item and a virtual one detached from reality. I would say that Python might not be the right fit, but instead a language dedicated to simulation. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote: > On 2015-05-11, Skip Montanaro wrote: > >> Python is in production use in hundreds of thousands of > >> organisations. It has been heavily used for over twenty years, in > >> everything from quick and dirty one line scripts to hundred-thousand > >> LOC applications. > > > > Mark> Yeah, so was COBOL. Boom. > > > > Your point being? > > That Python, like COBOL, is an eminently practical language. LOL! Good one. mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday, May 11, 2015 at 10:44:51 AM UTC-5, Steven D'Aprano wrote: > On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote: > > > The point is that all too often someone wants to defend a specific choice > > the developers have made and cites some general rule or principle in > > support, ignoring the fact that python breaks that rule/principle in other > > area's. > > "It's a free country, you can do what you like." > > "No I can't, I'm not allowed to kill people." > > Just because there are exceptions to a rule doesn't mean it isn't a general > rule. A few exceptions are just exceptions, they don't invalidate the fact > that "consenting adults" is a basic design principle of Python. The solution to this is to find an overarching maxim that encompasses both. This was already solved (in your example) with the Age they called the Enlightenment (and perhaps arguably with Kant). The solution was that your liberty extends to the point another's begins -- a more scalable maxim than "freedom". With OOP, the solution is not to slide by having sloppy design goals, it's to find a noble purpose. OOP by itself has no goal other than to try to make a system of re-usable objects. By itself it's like having a bow and arrow with no target. I'm suggesting there's a target: a data ecosystem for the exabytes of data that exists with the Internet -- not simulating graphical objects on the screen or trying to re-make the real-world in the virtual world. These are missteps that perhaps can be explored in languages specially tailored for it (Simula, POV-ray, Erlang, etc.). Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Monday, May 11, 2015 at 10:49:01 AM UTC-5, Skip Montanaro wrote: > On Mon, May 11, 2015 at 10:11 AM, zipher wrote: > > I also bought the idea of everything as an object, it has a unbeatable > > purity to it. But we won't ever get to the point were OOP is like the > > purity of math because the greatest utility of OOP is working with > > real-world data. And that real-world puts bounds on the otherwise abstract > > purity in which a language is theoretically capable. > > Did someone here say it would? Sure, OOP isn't as pure as math, but > most object-oriented languages aren't pure OO languages, either. SKip, it's fine to have a loose definition of things in a language when you're not sure where you want it to go. I think taking Python into the land of "everything is an object" was a neat exploration. I even supported it. But, now that I want to create a data ecosystem, sloppiness in design criteria or inadequacies in implementation gets exercised. Perhaps it won't be Python's goals, but I would argue that it's the best direction for Python. These aren't failings of the dev-team either -- no one's done this before. There are some attempts like CORBA, but either they remained in proprietary domains or they simply weren't capable of scaling to every kind of data. I've, in fact, had to invent a new data structure to do it, a data structure I'm implementing in Python and where the issue of the *nature* of OOP came to the fore. For example, have you ever contemplated this: class WeightedVertex(vertex_common(Vertex(dict))): """test class""" That currently isn't valid Python code, but the idea is that I'm making composite objects that expand one upon the other -- another basic idea in the realm of theoretical OOP that this boneheaded community couldn't wrap it's head around. Anyway, I'm also saying that it's better to have real design goals when such noble goals can be made, rather than be content with a sloppy flexibility. > The practicality side of things suggests that even though > everything-is-an-object isn't perfect, it may be good enough. > People/projects/companies generally can't afford to follow every > change that blows through their environment. True. Which is why theoretical CS exists -- to find deeper and better abstractions to encompass everything you want to do. It started with variables, then linked lists, then trees, then graphs and I'm taking that trajectory to it's end point. It's real Computer Science. Most people here haven't seemed to understand the power of Graphs yet, or perhaps they just can't agree upon an API so leave out such a powerful data structure. I'm currently refactoring my own implementation, so that it could be considered for inclusion in the collections module. Mark P.S. Sorry for the "boneheaded" insult -- I get called anything from a troll to a drug addict around here. -- https://mail.python.org/mailman/listinfo/python-list
Re: code blocks
On Monday, May 11, 2015 at 11:08:14 AM UTC-5, Chris Angelico wrote: > On Tue, May 12, 2015 at 2:01 AM, Peter Otten <[email protected]> wrote: > > Though interestingly, my Py2 doesn't have any help > >> on exec: > >> > > help('exec') > >> no documentation found for 'exec' > >> > >> Not sure why that is. > > > > Path confusion? You may accidentally be importing Python 3's topics. > > Try > > > from pydoc_data import topics > topics.__file__ > > '/usr/lib/python2.7/pydoc_data/topics.pyc' > "exec" in topics.topics > > True > > Peculiar. > > $ python > Python 2.7.3 (default, Mar 13 2014, 11:03:55) > [GCC 4.7.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> from pydoc_data import topics > >>> topics.__file__ > '/usr/lib/python2.7/pydoc_data/topics.pyc' > >>> "exec" in topics.topics > False > >>> topics.topics.keys() > ['conversions', 'debugger', 'attribute-access', 'augassign', > 'numeric-types', 'context-managers', 'bitwise', 'global', 'numbers', > 'customization', 'in', 'floating', 'integers', 'naming', 'if', > 'binary', 'raise', 'for', 'typesmapping', 'subscriptions', > 'specialnames', 'typesseq', 'dynamic-features', 'bltin-code-objects', > 'continue', 'dict', 'bltin-type-objects', 'import', 'typesmethods', > 'pass', 'atom-literals', 'slicings', 'function', 'typesseq-mutable', > 'bltin-ellipsis-object', 'execmodel', 'return', 'exprlists', 'power', > 'booleans', 'string-methods', 'assignment', 'callable-types', 'yield', > 'lists', 'else', 'assert', 'formatstrings', 'objects', 'shifting', > 'unary', 'compound', 'typesfunctions', 'imaginary', 'specialattrs', > 'with', 'class', 'types', 'break', 'calls', 'try', 'identifiers', > 'atom-identifiers', 'id-classes', 'bltin-null-object', 'while', > 'attribute-references', 'del', 'truth', 'sequence-types', > 'exceptions', 'comparisons', 'operator-summary', 'typesmodules', > 'strings', 'lambda'] > > Whatever. I've made a few messes on this system, maybe I broke > something somewhere. In any case, help('exec') is what's needed for > help on keywords, even if one particular installation doesn't have one > particular keyword-help. > > ChrisA It's strange, help(eval) works but help(exec) creates a SyntaxError, even though they would seem to be the same semantically -- both imperative verbs. You nailed it by calling "exec" a keyword, but still it's a strange distinction. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: How to properly apply OOP in the bouncing ball code
On Monday, May 11, 2015 at 7:25:09 PM UTC-5, Dennis Lee Bieber wrote: > On Mon, 11 May 2015 08:33:56 -0700 (PDT), zipher > declaimed the following: > >You are making a error that few in the programming community have caught up > >to. OOP design for *data abstraction* is a completely different beast that > >OOP for *simulation*. The confusion is around the use of the word "object" > >which both denotes a physical world item and a virtual one detached from > >reality. > > > >I would say that Python might not be the right fit, but instead a language > >dedicated to simulation. > > The danger there is that a "language dedicated to simulation" might > mean "discrete event" simulation -- which would be an even worse fit to a > problem of particle motion simulation. Huh? VPython successfully models particle motion simulation with discrete events. I don't see how you're going to update a variable non-discretely. Tensors? Good luck. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Monday, May 11, 2015 at 9:04:24 PM UTC-5, Steven D'Aprano wrote: > On Tue, 12 May 2015 05:01 am, [email protected] wrote: > > > Yale has taken the unusual step of outsourcing its introductory CS class > > to Harvard, which uses C as the main language in its CS50 class. > > And another generation of new programmers will be irreversibly damaged by > exposure to C... Come on, C is perfect for computer engineering students. For CS students, it's of mixed value. -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 4:16:31 AM UTC-5, Rustom Mody wrote: > On Tuesday, May 12, 2015 at 12:27:44 PM UTC+5:30, Chris Angelico wrote: > > On Tue, May 12, 2015 at 4:42 PM, Rustom Mody wrote: > > > And related to that (and one reason a pure functional language is good for > > > pedagogy): NO PRINT statement > > > It may seem trivial but beginning students have a real hard writing clean > > > structured code. Tabooing prints helps get there faster > > > And working in the interpreter makes a print-taboo a viable option > > > > I firmly disagree. > > Yes we know that! > > As it happens you also disagree with ACM's latest CS curriculum: I/O is an essential part of computing in the West. (I'll leave Symbolics out of of that category.) It started with switches and lights, so what kind of bullshit is saying that you should get rid of PRINT? ACM must have gotten confused or steamrolled by one of its members. mark Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Tuesday, May 12, 2015 at 8:56:32 AM UTC-5, Steven D'Aprano wrote: > The consensus among the core developers is: > * in general, the harm and inconvenience from accidentally > shadowing built-ins is not great, and it usually easy to > spot, debug and prevent; Where is that the consensus? Please cite examples. > * when it comes to built-in functions (e.g. sum, map, pow) > and types (e.g. int, str, list) there are significant and > important use-cases for allowing shadowing; Name one "significant and important" use case for shadowing built-in types. Functions, I don't have a problem with, but types are more fundamental than functions. > The general principle here is of consenting adults: Python allows you to > shadow built-ins because sometimes it is useful, and the good outweighs the > potential harm. I think you'll have to give examples, either from the developer community or some significant use cases to be believable. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 12:57:48 PM UTC-5, Rustom Mody wrote: > On Tuesday, May 12, 2015 at 10:45:39 PM UTC+5:30, Stefan Ram wrote: > > Rob Gaddi writes: > > >Is that a true array or a linked list? "It's a high level language, > > >that's just an implementation detail." Yes, but it's an implementation > > >detail that determines whether even the simple act of looking up element > > >n is O(1) or O(n). > > > > The complexity is given in the documentation of high-level languages. > > > > For example, from the documentation of the Java standard library: > > > > »This implementation provides constant-time performance > > for the basic operations (get and put),« (java.util.HashMap) > > > > C++: > > > > Section 23.2.1 specifies the complexity, such as »compile time«, > > »constant«, »linear« for container operations. > > > > But the abstraction mechanisms (templates, polymorphism) > > often allow one to change the implementation quite easily. > > This is regarded in some circles as one of the big open problems in CS > https://existentialtype.wordpress.com/2014/09/28/structure-and-efficiency-of-computer-programs/ > [and the position paper therein] > viz how to integrate the elegance of high-level languages > with the precision of complexity analysis of machine language The answer is you don't. You *don't* because you can't. And you *can't* because you don't know what you want to do yet. That is why you have very high-level languages that allow you to rapidly prototype ideas, test them, and then, depending all the other constraints, move them to lower-level language implementations. So don't try it. Everyone gets it wrong and now we have a plethora of languages which all do the same thing, without really knowing what they want as an overarching design or purpose. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 8:15:07 PM UTC-5, Steven D'Aprano wrote: > On Wed, 13 May 2015 02:05 am, Chris Angelico wrote: > > > So if you're writing a library function, it probably shouldn't use > > print()... but your application is most welcome to. You usually know > > which one you're writing at any given time. > > You might be, but beginners are not. > > I'm not sure I accept Rustom's fix for the problem (I think that his cure is > worse than the disease), but it is *hard* to get some beginners to use > return instead of print: > > def add_twice(x, y): > """Add twice y to x.""" > print x + 2*y > > > sort of thing. > > Personally, I think that banning print is only useful if you wish to > encourage cargo-cult programming: > > "Don't use print!" > "Why not?" > "My CS lecture said not to use it! I dunno, maybe it has a virus or > something." No, no, no. There's a very simple reason that you don't put extraneous I/O into your functions: you want your functions to be as general as possible for the given focus for re-usability. Otherwise, why write as a separate function? It's called separability of domains. See Hacking with the Tao: http://wiki.hackerspaces.org/Hacking_with_the_Tao. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 1:22:55 PM UTC-5, Mark Lawrence wrote: > On 12/05/2015 18:35, Rustom Mody wrote: > > On Tuesday, May 12, 2015 at 8:48:13 PM UTC+5:30, zipher wrote: > >> > >> I/O is an essential part of computing in the West. (I'll leave Symbolics > >> out of of that category.) It started with switches and lights, so what > >> kind of bullshit is saying that you should get rid of PRINT? ACM must > >> have gotten confused or steamrolled by one of its members. > > > > In the West? WEST?? > > Did I hear that right? > > > > I prefer this[1] > [1]https://mail.python.org/pipermail/python-ideas/2013-March/019979.html > Mark Lawrence I was trying to differentiate models of computing. Perhaps you don't know the concept. I'll refer you to http://c2.com/cgi/wiki?ModelsOfComputation. One might think that they ALL originated from Western Civ, but not quite. Yes, I was sounding little too enthusiastic in that post. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 5:24:34 PM UTC-5, Marko Rauhamaa wrote: > zipher : > > > That is why you have very high-level languages that allow you to > > rapidly prototype ideas, test them, and then, depending all the other > > constraints, move them to lower-level language implementations. > > Finally an argument to tackle. That rapid prototyping role is often > mentioned as a strong point of high-level languages. However, I can't > remember personally doing that. Rather, you want to use the right > programming language for any given role. I know. That's because most people have fallen off the path (http://c2.com/cgi/wiki?OneTruePath). You haven't done it because either others have done it for you (NumPy) or you simply aren't perfecting anything that needs to scale; i.e. you don't really need to minimize memory or CPU consumption because you're working with toy problems relative to the power of most hardware these days. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 9:30:50 PM UTC-5, Steven D'Aprano wrote: > On Wed, 13 May 2015 08:00 am, zipher wrote: > > > Everyone gets it wrong and now we have a plethora of languages which all > > do the same thing, without really knowing what they want as an overarching > > design or purpose. > > > Why must a language be designed with some "overarching design or purpose"? Because it's considerable work. Why re-invent the wheel? After all, there are plenty of Turing-complete languages out there. No, you make one because you have an implicit or explicit goal. > Why can't a language be designed with a *practical and concrete* need in > mind? As far as I know, only one language designed from theoretical first > principles has had any measure of mainstream success, Lisp, Yes, and that was a stellar achievement. Many language makers still compare to such a gold standard. Even Python. Yet it has also misled us -- it is based on a fundamentally different model of computation. An elegant model of computation, that many high-level languages seem to try to adopt, yet they fail because they can't re-produce the elegance without becoming LISP. So why, then, are there other programming languages that specifically try NOT to be LISP? Because the model of computation for most hardware is iterative. This is also why the design goal of "everything should be an object" needs to be revisited. It doesn't align with any model of computation. That's fine for small problems, but when you're trying to make a p2p data model that can scale to the Internet, it becomes an issue. > "I want to do numerical calculations" lead to Fortran. > > "I want to control telescopes" lead to Forth. > > "I want to teach beginners programming" lead to BASIC. You can stop there. You are proving my point, that there are goals to a given programming language. If those goals are strong or noble enough, it differentiates from existing languages. "I want to do numerical calculations" led to Fortran, which led to C because people wanted to do such calculations on many platforms. And C syntax had the more elegant syntax ultimately (I think the increment++ operator ultimately ran Fortran over, because it was directly implementable on CPU architectures in 1 clock cycle). "I want to control telescopes" could morph into the more general goal of "I want to make a controller programming language" and Boom, you'd have an elegant programming language for all controllers. "I want to teach beginners programming" started at BASIC, but then led to Pascal as the limitations of BASIC became clear, but then became Python. These are all decent design goals for a language. Python has superceded BASIC in almost every way. Anyway, having a design goal guides the process and helps everyone who wants to contribute know how to do so. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
On Tuesday, May 12, 2015 at 10:43:44 AM UTC-5, Chris Angelico wrote:
> On Wed, May 13, 2015 at 1:34 AM, zipher wrote:
> > Name one "significant and important" use case for shadowing built-in types.
> > Functions, I don't have a problem with, but types are more fundamental
> > than functions.
>
> Please tell me what, precisely, is the difference between a type and a
> function.
A type is something that settles matters for the machine. A function
calculates on the machine. You can have a type without a function, but you
generally can't have a function without types. If a distorted example like
function f(): {} has an implicit return of an int in ANSI C.
> Once you've settled that, please explain to me what the
> built-in name 'int' is in all versions of Python.
'int' is a type that also has a function synonymous with it. But they should
not be considered the same. They could, for example, be decoupled. So that
'int' was the type and 'integer' was the function.
Mark
> ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote: > On Wednesday, May 13, 2015 at 8:00:50 AM UTC+5:30, Steven D'Aprano wrote: > > Why can't a language be designed with a *practical and concrete* need in > > mind? As far as I know, only one language designed from theoretical first > > principles has had any measure of mainstream success, Lisp, and that was > > probably because there weren't that many decent alternatives at the time. > > How history U-turns!! > Lisp actually got every major/fundamental thing wrong > - variables scopes were dynamic by mistake > - lambdas were non-first class because the locution 'first-class' was still 8 > years in the future I think you're confused. LISP doesn't have variables. It's a lambda calculus with an entirely different model computation than other programming languages which use variables all the time. To the extent that it DOES have variables, it's to accomidate those coming over from iterative programming. And the idea of lambdas were already encoded by the use of special expressions, set-off by parenthesis. So they practically *defined* the concept of lambdas. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 10:47:48 PM UTC-5, Ian wrote: > On Tue, May 12, 2015 at 9:11 PM, zipher wrote: > > I know. That's because most people have fallen off the path > > (http://c2.com/cgi/wiki?OneTruePath). > > You wrote that, didn't you? I recognize that combination of delusional > narcissism and curious obsession with Turing machines. Damn straight. But to call the reference to Turing machines delusional, means you've already been captured by the first enemy on the Path. (cf. Javascript!) > > You haven't done it because either others have done it for you (NumPy) or > > you simply aren't perfecting anything that needs to scale; i.e. you don't > > really need to minimize memory or CPU consumption because you're working > > with toy problems relative to the power of most hardware these days. > > There is such a thing as over-optimization. Given unlimited programmer > time, sure, everything might be made to run using the minimum possible > time and space. You don't need to teach me these basics. If you had read the document, you would have seen that I already had assimilated the lessons of [Master] Jon Bentley. I know about over-optimization, however, if you had followed my other posts, you would also know that I'm attempting something that will require some interest in the underlying hardware at some point. Or, perhaps let's say, it's just my personal (unique?) preference not to create bloatware. mark -- https://mail.python.org/mailman/listinfo/python-list
Re: anomaly
[Mr. Lawrence spaketh:] > Do we really have to feed this guy, he's worse than the RUE? While it may seem like an impossible goal, is it unworthy? Is there something *better* for high-level, interpreted languages to be good for? The truth is, that all the theory is worked out, as well as the heavy math that will be required to visualize it (thanks VPython!). So it's only a matter of people being interested. I, personally, give up on many occasions, not because of *its* impossibility but the stubborness of People`s. mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 10:27:23 AM UTC-5, Ian wrote: > I don't know why I'm replying to this... Because you're trying to get an answer to a question that even Academia hasn't answered or understood. > On Wed, May 13, 2015 at 8:44 AM, zipher wrote: > > On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote: > >> How history U-turns!! > >> Lisp actually got every major/fundamental thing wrong > >> - variables scopes were dynamic by mistake > >> - lambdas were non-first class because the locution 'first-class' was > >> still 8 > >> years in the future > > > > I think you're confused. LISP doesn't have variables. > > Yes, it does. No, Common LISP does, but as the website says Common LISP is a "multi-paradigm" langauge. It's trying to be everything to everybody, just like Python tried to do in the other direction, making "everything an object". Python was trying to be too pure, while LISP was trying to be too universal: be everything to everyone -- you might say "batteries included". True LISP, doesn't need a 'let' statement for example. To understand true LISP you have to understand the modus operandi of the "lambda the ultimate" crowd. Very few do from academic computer science. MIT understands it. You think you understand it, but you don't. It's only abstractions, like math. It's purpose is to output a final result, that is all. It's not at all to make commercial applications. It's rather like Asimov's computer in the Last Question. It's a whole different model of computation. Instead of a Turing Tape or VonNeumann stream, you have hierarchies of expressions all evaluating... ...well I would say all at the same time, but since I have to constrain my description to a common set of reality that is shared with you, then I'd say "on the stack frame". It's why they had specialized machines to run true LISP. > > It's a lambda calculus > > No, it isn't. Lambda calculus is a formal system of mathematics. LISP > is a programming language. It may draw inspiration and borrow notation > from lambda calculus, but these are different things with different > uses and purposes. Again, you're speaking of "Common LISP". Such a lisp also wants to do OOP, but it's like lipstick on a pig. > > with an entirely different model computation than other programming > > languages which use variables all the time. To the extent that it DOES > > have variables, it's to accommodate those coming over from iterative > > programming. > > What is "iterative programming"? If you mean "writing programs that > work iteratively", then this describes both functional and procedural > styles alike. Yes, and LISP is neither. Although LISP is a functional style, that is only by appearance. It's completely different from Haskell, which I would describe as a true functional language. The difference is how the program is lexed in the mind or on the machine. But that's too difficult to explain on this thread. > The opposite of "iterative programming" would then be a style where > the program can't ever repeat anything. That would be a very limited > language and would *not* be equivalent to a Turing machine. The "opposite" of iterative programming is recursive programming. It's not limited, except that it has an entirely different relationship to data, one orthogonal to iterative computation. > > And the idea of lambdas were already encoded by the use of special > > expressions, set-off by parenthesis. So they practically *defined* the > > concept of lambdas. > > LISP is also the reason why we're cursed with the terrible name > "lambda" for anonymous functions rather than something more mnemonic > (like "function"). No, you haven't understood, padawan. Lambda *is* the function, not it's definition. Perhaps you will understand what I mean by that, perhaps you won't. It's subtle. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 4:39:52 PM UTC-5, Ian wrote: > On Wed, May 13, 2015 at 12:07 PM, zipher wrote: > > On Wednesday, May 13, 2015 at 10:27:23 AM UTC-5, Ian wrote: > >> I don't know why I'm replying to this... > > > > Because you're trying to get an answer to a question that even Academia > > hasn't answered or understood. > > > >> On Wed, May 13, 2015 at 8:44 AM, zipher wrote: > >> > On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote: > >> >> How history U-turns!! > >> >> Lisp actually got every major/fundamental thing wrong > >> >> - variables scopes were dynamic by mistake > >> >> - lambdas were non-first class because the locution 'first-class' was > >> >> still 8 > >> >> years in the future > >> > > >> > I think you're confused. LISP doesn't have variables. > >> > >> Yes, it does. > > > > No, Common LISP does, but as the website says Common LISP is a > > "multi-paradigm" langauge. It's trying to be everything to everybody, > > just like Python tried to do in the other direction, making "everything an > > object". Python was trying to be too pure, while LISP was trying to be too > > universal: be everything to everyone -- you might say "batteries included". > > > > True LISP, doesn't need a 'let' statement for example. To understand true > > LISP you have to understand the modus operandi of the "lambda the ultimate" > > crowd. Very few do from academic computer science. MIT understands it. > > You think you understand it, but you don't. > > By "true LISP" are you referring to the original specification by John > McCarthy? Here's an example lambda S-expression from McCarthy's > original paper: > > (LABEL, SUBST, (LAMBDA, (X, Y, Z), (COND ((ATOM, Z), (COND, (EQ, Y, > Z), X), ((QUOTE, T), Z))), ((QUOTE, T), (CONS, (SUBST, X, Y, (CAR Z)), > (SUBST, X, Y, (CDR, Z))) > > Ugh, what a mess. But ignoring that, tell us how many variables you > see there. I'll give you a hint: I count more than two. LoL, it's an interesting example you've thrown up there. It's more than just a mess though. The problem is the use of the quote. I was hoping you wouldn't include it. The problem is that its a compromise to interact with your mental-visual lexer. It's like Javascript which runs on no virtual machine anyone's heard of. It's too magical. > Sure. Lisp machines never, ever ran computer graphics applications. Or > medical image processing. Nope, never, because that would be > commercial and dirty and a hideous perversion of the idol of computer > science created by the prophet McCarthy. Text editors? Heavens to > Betsy, now you're just trying to shock me, aren't you! CLISP =/= LISP. > > Yes, and LISP is neither. Although LISP is a functional style, that is > > only by appearance. It's completely different from Haskell, which I would > > describe as a true functional language. The difference is how the program > > is lexed in the mind or on the machine. But that's too difficult to > > explain on this thread. > > And Fermat had a truly marvelous proof, which you would think > wonderful, if only he had enough room in that infamous margin. Ha, you know, I actually think I found the proof he alleges. You have to visualize the problem geometrically. > Iteration is a type of recursion. Specifically, it's the type of > recursion that doesn't require keeping a stack of values from each > higher-up repetition in the evaluation. > Also known as "linear > recursion" or "tail recursion". You are so confused, it boggles. Can anyone else assert this? Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
> > No, Common LISP does, but as the website says Common LISP is a > > "multi-paradigm" langauge. It's trying to be everything to everybody, > > just like Python tried to do in the other direction, making "everything an > > object". Python was trying to be too pure, while LISP was trying to be > > too universal: be everything to everyone -- you might say "batteries > > included". > > > > True LISP [...] > > Ah, the "No True Scotsman" fallacy. You know that Lisp compiler you're > using? That's not *true* Lisp, because *true* Lisp doesn't have [insert > feature here]. While schools use the term "variable" and there are letters like x, y, z. These should not be considered variables in any sense that you know. They (generally) are not assigned to. They are placeholders holding state. They don't change once the program starts running. > > Again, you're speaking of "Common LISP". Such a lisp also wants to do > > OOP, but it's like lipstick on a pig. > > You really love that metaphor, don't you? You keep using it, and variations > like "a pig made of lipstick". I suggest you don't understand the metaphor. My apologies. I thought better after I posted the message. It's more like putting lipstick on a *boy*. LISP, indeed, is not a pig. > > Yes, and LISP is neither. Although LISP is a functional style, that is > > only by appearance. It's completely different from Haskell, which I would > > describe as a true functional language. The difference is how the program > > is lexed in the mind or on the machine. But that's too difficult to > > explain on this thread. > > Just because something is difficult to explain doesn't make it correct. It's > difficult to explain how the Atlantic Ocean merely looks, tastes and feels > like salt water while actually being filled with strawberry yoghurt. That > doesn't make it true. > > Something which is difficult to explain might be deeply profound, but is far > more likely to be rubbish. That's all fine and good, Steven. But the academically and politically correct thing to do in that case, is withhold judgement. Perhaps you don't know what to do with yourself if I'm right, so your remaining recourse is to defences rather than inquiry. > > The "opposite" of iterative programming is recursive programming. > > No it isn't. Iteration and recursion are, in a very deep sense, actually the > same thing, they're certainly not opposites. That is a fact which genuinely > is profound. My God, you and Lawrence have gone off the deep end. What you're telling me is that you've never programmed something on digital hardware. That, fucking C, you've never even counted on your FINGERS!! > >> > And the idea of lambdas were already encoded by the use of special > >> > expressions, set-off by parenthesis. So they practically *defined* the > >> > concept of lambdas. > >> > >> LISP is also the reason why we're cursed with the terrible name > >> "lambda" for anonymous functions rather than something more mnemonic > >> (like "function"). > > > > No, you haven't understood, padawan. Lambda *is* the function, not it's > > definition. Perhaps you will understand what I mean by that, perhaps you > > won't. It's subtle. > > Subtle like a kick to the head. Well, at least you got the kick. It's only be understanding your error, can you then proceed to a greater truth. More concretely, programming in an iterative language is like programming f(x, y, z...), where f is the idea your wanting to implement and x,y,z are inputs. Since the are input by user interaction, they are VARIABLE. A type of interactive program (not a Turing tape, either I might add). A program in LISP is simply f, or more to their nomemclature: lambda. It's like the difference of saying f(x) = x + 1, or saying f = /x.x+1 (where "/" is the Greek lambda character). Do you see the subtle difference? They both appear to have variables, but they are not the same. To repeat myself from two years ago: Here endeth the lesson. You may be seated. > If you wish to change our minds, you're going to have to demonstrate > objective, verifiable facts and not just allude to how your ideas are too > subtle and clever for us. Hopefully that helps. But if I thought my ideas were too subtle or clever for you I wouldn't keep responding to you. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote: > On 14/05/2015 02:40, Steven D'Aprano wrote: > > On Thu, 14 May 2015 04:07 am, zipher wrote: > > > >> > >> No, you haven't understood, padawan. Lambda *is* the function, not it's > >> definition. Perhaps you will understand what I mean by that, perhaps you > >> won't. It's subtle. > > > > Subtle like a kick to the head. > > From the very first drivel that he posted on python ideas just over two > years ago, he's shown that he's incapable of any logical thought > relating to computing, in just the same way that the RUE has never > posted anything logical about the FSR. Please can we stop feeding him. The truth is quite the opposite. There is something very strange going on around the nets. People are very confused. Javascript has confused them. Tell me where is the lexer in Javascript? or the virtual machine? The point I'm making about LISP is that in LISP you don't define a function, it IS the function. Instead of f(x,y) = x+y, which is how you code a traditional program, you only show/program f itself. In the lambda calculus, it is expressed f = /(x,y).x+y where / is the lambda character, not f(x) or f OF x. Do you see why the difference is subtle? Java has a virtual machine. Python has a virtual machine. Do you think Chrome and these browsers include virtual machines to run on 50 different architectures? I'm actually curious if anyone has a non-magical answer to it. We all assume that computers can only act logically and have always acted such. But they way some people act and the way somethings are being done is making questions. Perhaps I'm the only one. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Friday, May 15, 2015 at 10:36:45 PM UTC-5, Rustom Mody wrote: > On Saturday, May 16, 2015 at 8:56:00 AM UTC+5:30, zipher wrote: > > On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote: > > > On 14/05/2015 02:40, Steven D'Aprano wrote: > > > > On Thu, 14 May 2015 04:07 am, zipher wrote: > > > > > > > >> > > > >> No, you haven't understood, padawan. Lambda *is* the function, not > > > >> it's > > > >> definition. Perhaps you will understand what I mean by that, perhaps > > > >> you > > > >> won't. It's subtle. > > > > > > > > Subtle like a kick to the head. > > > > > > From the very first drivel that he posted on python ideas just over two > > > years ago, he's shown that he's incapable of any logical thought > > > relating to computing, in just the same way that the RUE has never > > > posted anything logical about the FSR. Please can we stop feeding him. > > > > The truth is quite the opposite. There is something very strange going on > > around the nets. People are very confused. Javascript has confused them. > > Tell me where is the lexer in Javascript? or the virtual machine? > > > > The point I'm making about LISP is that in LISP you don't define a > > function, it IS the function. Instead of f(x,y) = x+y, which is how you > > code a traditional program, you only show/program f itself. In the lambda > > calculus, it is expressed f = /(x,y).x+y where / is the lambda character, > > not f(x) or f OF x. Do you see why the difference is subtle? > > > > Java has a virtual machine. Python has a virtual machine. Do you think > > Chrome and these browsers include virtual machines to run on 50 different > > architectures? I'm actually curious if anyone has a non-magical answer to > > it. We all assume that computers can only act logically and have always > > acted such. But they way some people act and the way somethings are being > > done is making questions. Perhaps I'm the only one. > > > > As for chrome and its specific VM > http://en.wikipedia.org/wiki/V8_%28JavaScript_engine%29 > > As for the rest... > We are as confused by your confusions as you are > > [Your continual assertions about everyone everywhere being totally confused > reminds me of my first trip to N America where I was unnerved to find everyone > driving on the wrong side of the road] Thanks for that note, actually, it's quite apropos. I'm a space cowboy who's trying to tell people what I've seen from "outside the fishbowl". To those in the fishbowl, they don't think that they're in water, because they've never been outside of it--the concept doesn't exist. But I left the orthodoxy (without throwing it away) and saw from the outside. Zen is one of the nodal points of that outside. And from that view, I can tell you that Python has abandoned much of it`s Zen to the point that is now only held by the programmers who still believe in it like some lost ancient tablet that they keep in their pocket. It can come back easily, though. One conversation in person with a whiteboard would do it. I'm starting to see why I'm seen as such an iconoclast: I've been outside of it for a long time and have taken it for granted -- I couldn't see my own "water". Oh well. Maybe the relationship will be mended with the community, or maybe not. My psychological states go from one extreme to another, so that's my "thing" in case anyone was wondering what my issue is--it's happened ever since getting tazered. It sucked. Mark -- https://mail.python.org/mailman/listinfo/python-list
different types of inheritence...
Still considering distinguishing between different types of inheritance.
Apart from object composition or mix-in style, I want to illustrate something
regarding the "arrow" of inheritance.
class super_dict(dict):
def __init__(self, init={}, default_value=0, collision_function=None):
*expands what dict can do*
def get_default(self): #stupid method to illustrate a point
return self._default_value
class specialized_dict(dict):
def update(self, other):
*change the behavior of how updates work*
def setdefault(self, key, value):
if key=sentinel:
self[key]=0
else:
self[key]=value
These look like the standard is-a inheritance, but they are very different.
The first goes upwards, making a super-class, the other drills downwards and
makes dict more specialized. The former expands on the capability and the API,
the latter keeps the exact API but modifies the method behaviors. The former
becomes a more general type, the latter becomes a more specific type.
Steven D'Aprano was arguing a couple of years ago that there is no difference,
one can simply turn the inheritance diagram upside-down. But here it can be
seen that that's not an option
Anyone else see the significance? Sorry to be a PITA...
Mark
--
https://mail.python.org/mailman/listinfo/python-list
Re: different types of inheritence...
> Apart from object composition or mix-in style, I want to illustrate something
> regarding the "arrow" of inheritance.
>
> class super_dict(dict):
>
> def __init__(self, init={}, default_value=0, collision_function=None):
>*expands what dict can do*
>
> def get_default(self): #stupid method to illustrate a point
>return self._default_value
>
> class specialized_dict(dict):
>
> def update(self, other):
> *change the behavior of how updates work*
>
> def setdefault(self, key, value):
> if key=sentinel:
> self[key]=0
> else:
> self[key]=value
Okay, perhaps I wasn't being clear
THESE OBJECTS HAVE THE SAME CLASS *SYNTAX*, BUT COMPLETELY DIFFERENT
*SEMANTICS*.
Comprende? I'm not trying to be cryptic here. This is a bit of OOP theory to
be discussed.
Mark
--
https://mail.python.org/mailman/listinfo/python-list
should "self" be changed?
Would it be prudent to rid the long-standing "argument" (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Something like: class MyClass(object): def __init__(@): @.dummy = None OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*. class MyClass(object): def __init__(): #takes no arguments! @.dummy = None #the @ invokes the class object's dictionary That would seem to be a nice solution to the problem, really. It doesn't become PERLish because you've made it into a genuine operator -- "self" was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched. Anyone else have any thoughts? --mark -- https://mail.python.org/mailman/listinfo/python-list
Re: should "self" be changed?
On Tuesday, May 26, 2015 at 12:28:31 PM UTC-5, Mark Lawrence wrote: > On 26/05/2015 17:37, zipher wrote: > > Would it be prudent to rid the long-standing "argument" (pun unintended) > > about self and the ulterior spellings of it, by changing it into a symbol > > rather than a name? > > Yes, how about you taking a permanent holiday rather than bother this > list with more of your nonsense? > > Mark Lawrence Mr. Lawrence, could you calm down with your sadism on the list. Our session last time ended with a lot of semen on your floor instead of in your mouth. Your bosom buddy, Mark Janssen -- https://mail.python.org/mailman/listinfo/python-list
Re: should "self" be changed?
On Tuesday, May 26, 2015 at 11:57:44 AM UTC-5, Laura Creighton wrote:
> In a message of Tue, 26 May 2015 09:37:29 -0700, zipher writes:
> >Would it be prudent to rid the long-standing "argument" (pun unintended)
> >about self and the ulterior spellings of it, by changing it into a symbol
> >rather than a name?
> >class MyClass(object):
> >
> >def __init__(@):
> >@.dummy = None
> >
> >OR, even better, getting *rid of it* in the parameter list, so it stops
> >confusing people about how many parameters a method needs, and transform it
> >into a true *operator*.
> >
> >class MyClass(object):
> >
> >def __init__(): #takes no arguments!
> >@.dummy = None #the @ invokes the class object's dictionary
> >
> >That would seem to be a nice solution to the problem, really. It doesn't
> >become PERLish because you've made it into a genuine operator -- "self" was
> >always a non-variable that looked like a variable and hence created an itch
> >that couldn't be scratched.
>
> Guido did. :)
> http://neopythonic.blogspot.se/2008/10/why-explicit-self-has-to-stay.html
Sweet link. I see now that my confusion surrounds the mistaken notion that
Python is lexing python source into *abstract syntax trees* (wikipedia
describes nicely), so that code inside a method knows what class it's in.
But GvR hasn't defined his language to the extent where the notion of "object"
even exists. He's only set aside a keyword called "class". So of course he
has to treat the method code, practically, like a [C] function. But that
limits the language, not to define what an object is inside the lexical
structure:
object ::= "class" identifier "(" inheritence_list ")" ":"
inheritence_list ::= [[et cetera]]
If he did this, then code inside the class could already know what class
they're in and all the objections in Laura's link would be moot.
Mark J
--
https://mail.python.org/mailman/listinfo/python-list
Re: should "self" be changed?
On Tuesday, May 26, 2015 at 9:48:25 PM UTC-5, zipher wrote: > On Tuesday, May 26, 2015 at 12:28:31 PM UTC-5, Mark Lawrence wrote: > > On 26/05/2015 17:37, zipher wrote: > > > Would it be prudent to rid the long-standing "argument" (pun unintended) > > > about self and the ulterior spellings of it, by changing it into a symbol > > > rather than a name? > > > > Yes, how about you taking a permanent holiday rather than bother this > > list with more of your nonsense? > > > > Mark Lawrence > > Mr. Lawrence, could you calm down with your sadism on the list. Our session > last time ended with a lot of semen on your floor instead of in your mouth. > > Your bosom buddy, > > Mark Janssen Arrgh. Sorry, that was meant privately... -m -- https://mail.python.org/mailman/listinfo/python-list
Re: should "self" be changed?
On Tuesday, May 26, 2015 at 11:57:44 AM UTC-5, Laura Creighton wrote: > In a message of Tue, 26 May 2015 09:37:29 -0700, zipher writes: > >Would it be prudent to rid the long-standing "argument" (pun unintended) > >about self and the ulterior spellings of it, by changing it into a symbol > >rather than a name? > > > >Something like: > > > >class MyClass(object): > > > >def __init__(@): > >@.dummy = None > > > >OR, even better, getting *rid of it* in the parameter list, so it stops > >confusing people about how many parameters a method needs, and transform it > >into a true *operator*. > > > >class MyClass(object): > > > >def __init__(): #takes no arguments! > >@.dummy = None #the @ invokes the class object's dictionary > > > >That would seem to be a nice solution to the problem, really. It doesn't > >become PERLish because you've made it into a genuine operator -- "self" was > >always a non-variable that looked like a variable and hence created an itch > >that couldn't be scratched. > > > >Anyone else have any thoughts? > > Guido did. :) > http://neopythonic.blogspot.se/2008/10/why-explicit-self-has-to-stay.html Nice link, thanks. I see the problem. I was under the false impression that Python's lexer built an *abstract syntax tree* (see wikipedia for a nice description) like C does so that lexical items like functions and objects are defined. As it stands now, Python doesn't even seem to know what an *expression* is. Guido hasn't defined his language so that an object is defined lexically, so he's cheating a little by requiring "self" to be passed in. If Python were to be defined more completely, all his points in reference to Bruce Eckel's suggestion would be moot. A method would automatically (not auto*magically*) know what class they are in. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: should "self" be changed?
On Wednesday, May 27, 2015 at 6:30:16 AM UTC-5, Ben Finney wrote: > Steven D'Aprano writes: > > > On Wednesday 27 May 2015 14:39, Ben Finney wrote: > > > > > That kind of homophobic slur is inappropriate from anyone in this > > > community. Kindly cut it out altogether. > > > > I look forward to the day when people would read the earlier insult > > and be perplexed as to why it is a slur at all. In the same way as > > "your mother wears army boots" has become a joke slur, not taken > > seriously. > > Yes, let's all work toward an end to the use of gender, sexuality, > ethnicity, and other inborn traits as the punchline of insults or jokes. Oh God, you people are being idiots. It's poop. And shall we all so look forward to the day, when people who eat poop are also welcome into the circle of humanity? Everyday, you let atrocity happen, and you're fighting for oppressed feltchers? If so, you dumbasses don't deserve much of a future. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: different types of inheritence...
On Tuesday, May 26, 2015 at 3:53:25 PM UTC-5, Michael Torrie wrote: > On 05/26/2015 08:57 AM, zipher wrote: > > Comprende? I'm not trying to be cryptic here. This is a bit of OOP > > theory to be discussed. > > No, sorry. Maybe an actual example (with use case) would spur discussion. In the first example, super_dict changes the behavior of *for the user*, expanding the API, but keeping all the prior method behaviors the same. In the second example, specialized_dict changes the behavior in the machine -- the API stays the same so the user of the code just gets new benefits from whatever the specialized_dict is improving internally *without changing his/her code*. It's a drop-in replacement. In other words, the second class changes the INTERNALS of . While the first class changes the *externals* of . Yet they both use the same class definition, but semantically are completely different. It's TWO different definition of IS-A relationship. Two definitions of the word "is". m -- https://mail.python.org/mailman/listinfo/python-list
Re: should "self" be changed?
On Tuesday, May 26, 2015 at 11:40:20 PM UTC-5, Ben Finney wrote: > zipher writes: > > > Arrgh. Sorry, that was meant privately... > > I'm glad we saw it publicly, so that we get more of an idea how you > treat people. Ben, he asked for it. Stop assuming. > That kind of homophobic slur is inappropriate from anyone in this > community. Kindly cut it out altogether. Ben that is so presumtuous of you! He and my acts were completely homo positive. I assure you. Perhaps you are hiding something? Mark P.S. You can respond privately. -- https://mail.python.org/mailman/listinfo/python-list
Re: should "self" be changed?
On Wednesday, May 27, 2015 at 12:48:02 AM UTC-5, Steven D'Aprano wrote: > On Wednesday 27 May 2015 14:39, Ben Finney wrote: > > > zipher writes: > > > >> Arrgh. Sorry, that was meant privately... > > > > I'm glad we saw it publicly, so that we get more of an idea how you > > treat people. > > > > That kind of homophobic slur is inappropriate from anyone in this > > community. Kindly cut it out altogether. > > I look forward to the day when people would read the earlier insult and be > perplexed as to why it is a slur at all. In the same way as "your mother > wears army boots" has become a joke slur, not taken seriously. Yes, and I look forward to the day when you *bend over* freely to take it all in without complaint. When such offerings are natural and aren't seen as an insult at all. You first. Mark > So long as it does nobody any harm, and all participants have consented, > what one adult chooses to take into their mouth is nobody else's business > and certainly no reason to look down on them. > > > > -- > Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: should "self" be changed?
On Wednesday, May 27, 2015 at 2:39:21 AM UTC-5, Marko Rauhamaa wrote: > Chris Angelico : > > > Using some other name in place of "self" should definitely remain > > *possible*, but not commonly done. > > You are effectively making the argument that Python has made a mistake > by not giving "self" a special, language-level status. I'm making that claim. Guido's arguments are based on a simple lexical definition of the language. If the lexical definition were sophisticated enough to feed into GCC as a front-end, for example, then it wouldn't have to be so abnormal. It's a short-cut for a less mature language. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: should "self" be changed?
On Wednesday, May 27, 2015 at 8:00:49 AM UTC-5, Todd wrote: > On Wed, May 27, 2015 at 2:40 PM, zipher wrote: > On Wednesday, May 27, 2015 at 6:30:16 AM UTC-5, Ben Finney wrote: > > > Steven D'Aprano writes: > > > > > > > On Wednesday 27 May 2015 14:39, Ben Finney wrote: > > > > > > > > > That kind of homophobic slur is inappropriate from anyone in this > > > > > community. Kindly cut it out altogether. > > > > > > > > I look forward to the day when people would read the earlier insult > > > > and be perplexed as to why it is a slur at all. In the same way as > > > > "your mother wears army boots" has become a joke slur, not taken > > > > seriously. > > > > > > Yes, let's all work toward an end to the use of gender, sexuality, > > > ethnicity, and other inborn traits as the punchline of insults or jokes. > > > > Oh God, you people are being idiots. It's poop. And shall we all so look > forward to the day, when people who eat poop are also welcome into the circle > of humanity? > > If your goal is to get people to stop calling you a troll, you are going > about it the wrong way. If it isn't, why are you even here? Please remember > the first rule of holes: if you find yourself in a hole, stop digging. Dude, I stopped digging into "holes" a long time ago, but then that was the issue wasn't it? And since my goal isn't that, let's go back to discussing the ins and outs (ahem) of creating a more complete lexical specification of the language, which would provide many other worthy side benefits, besides saving on typing characters. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: should "self" be changed?
On Thursday, May 28, 2015 at 11:59:36 AM UTC-5, Marko Rauhamaa wrote: > Ian Kelly : > > I think I would be more inclined to use enums. This has the advantages > > of not creating a new set of state classes for every connection > > instance and that each state is a singleton instance, allowing things > > like "if self.state is SMTPConnectionState.IDLE". It could look > > something like this: > > > > class SMTPConnectionState(Enum): > > > > class IDLE: > > @classmethod > > def handle_command(cls, conn, cmd): > > # ... > > > > class SPF_HELO: > > @classmethod > > def terminate(cls, conn): > > # ... > > Really, the main expressive choice is whether you use an inner class > (and get the advantages of a closure) or an outer class (and get > potential performance advantages). Can you tell me: What is the advantage of a closure here? Also: why wouldn't you simply put your state classes at the outer scope (i.e. module-level) of your module so that they are clear to anyone else who want to use the module? Presumably these classes are for making your SMTPServerConnection object more useable, not to hide these state-classes from the users. MarkJ -- https://mail.python.org/mailman/listinfo/python-list
Re: [LONG] docstring-driven testing
On Saturday, March 6, 1999 12:00:00 AM UTC-8, Tim Peters wrote: > If you're like me, you've been using Python since '91, and every scheme > you've come up with for testing basically sucked. Some observations: > > + Examples are priceless. > > + Examples that don't work are worse than worthless. > > + Examples that work eventually turn into examples that don't. > > + Docstrings too often don't get written. > > + Docstrings that do get written rarely contain those priceless examples. > > + The rare written docstrings that do contain priceless examples eventually > turn into rare docstrings with examples that don't work. I think this one > may follow from the above ... > > + Module unit tests too often don't get written. > > + The best Python testing gets done in interactive mode, esp. trying > endcases that almost never make it into a test suite because they're so > tedious to code up. > > + The endcases that were tested interactively-- but never coded up --also > fail to work after time. > > About a month ago, I tried something new: take those priceless interactive > testing sessions, paste them into docstrings, and write a module to do all > the rest by magic (find the examples, execute them, and verify they still > work exactly as advertised). > > Wow -- it turned out to be the only scheme I've ever really liked, and I > like it a lot! With almost no extra work beyond what I was doing before, > tests and docstrings get written now, and I'm certain the docstring examples > are accurate. It's also caught an amazing number of formerly-insidious > buglets in my modules, from accidental changes in endcase behavior, to hasty > but inconsistent renamings. > > doctest.py is attached, and it's the whole banana. Give it a try, if you > like. After another month or so of ignoring your groundless complaints, > I'll upload it to the python.org FTP contrib site. Note that it serves as > an example of its own use, albeit an artificially strained example. Doctests are so cool, I think it should be integrated into the interpreter environment with a test() built-in to encourage people documenting their code and Test-Driven-Development. A companion to help(). Oh wait, this thread is 14 years old... ;^) -- http://mail.python.org/mailman/listinfo/python-list
