Re: Python and Lisp : car and cdr
* 2011-06-19T12:20:32-04:00 * Terry Reedy wrote: > On 6/19/2011 9:24 AM, Steven D'Aprano wrote: >> No. Each cell in a Lisp-style linked list has exactly two elements, >> and in Python are usually implemented as nested tuples: >> >> (head, tail) # Annoyingly, this is also known as (car, cdr). >> >> where head is the data value and tail is either another Lisp-style >> list or a marker for empty (such as the empty tuple () or None). > It should be noted that the head element of any 'list' can also be a > list' (as with Python lists), Both the head and tail elements of a cons cell can refer to any Lisp objects. Cons cell is a general-purpose primitive data type but it is _often_ used to build lists and trees so the tail element often refers to another cons cell (or nil that terminates the list). Let's not forget that Lisp's program code itself is built on such trees of cons cells. Lisp code itself is represented in this primitive Lisp data type. That's why Lisp is so powerful in meta programming. It's trivial to use Lisp functions to create Lisp code. -- http://mail.python.org/mailman/listinfo/python-list
Re: The end to all language wars and the great unity API to come!
* 2011-07-06T06:41:52-07:00 * wrote: > I am using a user defined spec as an argument to the cmp function. > That spec then modifies the body of the compare function and creates a > user defined control structure. You can argue all day that it is not a > user defined control structure but no one is going to believe you. I won't argue all day, I'll just show you an example of a user defined control structure. This is like the standard (DOTIMES (VAR COUNT) BODY) macro expect that it executes BODY forms first forwards and then backwards. The iterator variable VAR goes first up from 0 and then down to 0. (defmacro ping-pong-iterator ((var count &optional result) &body body) `(progn (loop for ,var from 0 below ,count do (progn ,@body)) (loop for ,var from (1- ,count) downto 0 do (progn ,@(reverse body)) finally (return ,result CL-USER> (ping-pong-iterator (i 3 "ready") (format t "form 1: ~A~%" i) (format t "form 2: ~A~%" i) (format t "form 3: ~A~%" i) (format t "~%")) form 1: 0 form 2: 0 form 3: 0 form 1: 1 form 2: 1 form 3: 1 form 1: 2 form 2: 2 form 3: 2 form 3: 2 form 2: 2 form 1: 2 form 3: 1 form 2: 1 form 1: 1 form 3: 0 form 2: 0 form 1: 0 => "ready" -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
* 2001-01-01T14:11:11-05:00 * Terry Reedy wrote: > As a side note, the same principle of expressions matching operations > in symmetry suggest that majority of up are quite sensible and not > dumb idiots for preferring 'f(x)' to the '(f x)' of Lisp. In a > function call, the function has a different role than the arguments, > so it is appropriate that it have a different role in the expression. Please don't forget that the whole point of Lisps' (f x) syntax is that code is also Lisp data. It's not just a function call with arguments. First, it's literal data (two linked cons cells and symbols) and then the Lisp evaluating model makes it a function call in certain situations. Lisp is CL-USER> (let ((lisp (cons 'programmable nil))) (setf (rest lisp) lisp)) #1=(PROGRAMMABLE . #1#) programming language and it's totally irrelevant and pointless to say "which syntax someone prefers" because this feature (code being data) is very fundamental principle of the language. You know, it's easy to write programs that write programs. If we remove this feature (i.e., don't talk about Lisp at all) then it's perhaps relevant to discuss about such choices in syntax. You wouldn't want Python arrays have a read and print format "a[b, c]", that is, the first item of the array printed outside []'s. It would be silly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
* 2011-07-13T10:34:41-04:00 * Terry Reedy wrote: > On 7/13/2011 4:29 AM, Teemu Likonen wrote: >> Please don't forget that the whole point of Lisps' (f x) syntax is >> that code is also Lisp data. > > Thank you for clarifying that. Some Lispers appear to promote the > simple, uniform syntax' as a end in itself (making code=data a side > effect) rather than as a means to accomplish a deeper end. Perhaps, yes. We can't really speak of Lisp's syntax in the same sense as syntax in other languages. >> CL-USER> (let ((lisp (cons 'programmable nil))) >> (setf (rest lisp) lisp)) > > This much looks like Lisp > >> #1=(PROGRAMMABLE . #1#) > > This must be some of the new-fangled Common LIsp stuff I never learned > ;=). It's a way for the Lisp printer to show circular structures. In this case it shows a cons cell. Its first part is the symbol PROGRAMMABLE and the second part is a pointer back to the cons cell itself. So, it's a kind of infinite linked list with the same item PROGRAMMABLE all the time. With Lisp printer settings (setf *print-circle* nil *print-length* 5) the same thing would be printed this way: (PROGRAMMABLE PROGRAMMABLE PROGRAMMABLE PROGRAMMABLE PROGRAMMABLE ...) -- http://mail.python.org/mailman/listinfo/python-list
Re: None versus MISSING sentinel -- request for design feedback
* 2011-07-15T15:28:41+10:00 * Steven D'Aprano wrote: > I'm designing an API for some lightweight calculator-like statistics > functions, such as mean, standard deviation, etc., and I want to > support missing values. Missing values should be just ignored. E.g.: > > mean([1, 2, MISSING, 3]) => 6/3 = 2 rather than 6/4 or raising an > error. > > My question is, should I accept None as the missing value, or a > dedicated singleton? How about accepting anything but ignoring all non-numbers? -- http://mail.python.org/mailman/listinfo/python-list
Re: None versus MISSING sentinel -- request for design feedback
* 2011-07-15T03:02:11-07:00 * bruno wrote: > On Jul 15, 10:28 am, Teemu Likonen wrote: >> How about accepting anything but ignoring all non-numbers? > > Totally unpythonic. Better to be explicit about what you expect and > crash as loudly as possible when you get anything unexpected. Sure, but sometimes an API can be "accept anything" if any kind of trash is expected. But it seems that not in this case, so you're right. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* 2011-07-18T10:54:40+10:00 * Steven D'Aprano wrote: > Back in 2007, a n00b calling himself "TheFlyingDutchman" who I am > *reasonably* sure was Rick decided to fork Python: > > http://mail.python.org/pipermail/python-list/2007-September/1127123.html I don't know if they are the same person but quite recently "TheFlyingDutchman" tried to understand symbols, variables' scope, bindings as well as function and variable namespaces in Common Lisp. It resulted in a long thread, some of it was quite interesting. http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/36000a1f37ebb052/5683597dd587fa87 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: os.path needs immediate attention!
* 2011-07-29T10:22:04-07:00 * wrote: > * New path module will ONLY support one path sep! There is NO reason > to support more than one. Pathnames and the separator for pathname components should be abstracted away, to a pathname object. This pathname object could have a "path" or "directory" slot which is a list of directory components (strings). Then there would be method like "to_namestring" which converts a pathname object to native pathname string. It takes care of any platform-specific stuff like pathname component separators. Of course "to_pathname" method is needed too. It converts system's native pathname string to a pathname object. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: os.path needs immediate attention!
* 2011-07-30T10:57:29+10:00 * Steven D'Aprano wrote: > Teemu Likonen wrote: >> Pathnames and the separator for pathname components should be >> abstracted away, to a pathname object. > > Been there, done that, floundered on the inability of people to work > out the details. > > http://www.python.org/dev/peps/pep-0355/ I'm very much a Lisp person and obviously got the idea of pathname objects from Common Lisp. Lazily I'm also learning Python too but at the moment I can't comment on the details of that PEP. Yet, generally I think that's the way to improve pathnames, not the "rantinrick's". -- http://mail.python.org/mailman/listinfo/python-list
Re: Early binding as an option
* 2011-08-02T11:03:24-07:00 * Chris Rebert wrote: > Smart enough JITers can infer that late binding is not being exploited > for certain variables and thus optimize them accordingly. Look how > fast some of the JavaScript VMs are, despite JavaScript also being > highly dynamic. Or Common Lisp. It has "packages" (namespaces for symbols). All the standard symbols are in the COMMON-LISP (CL) package which is locked and can't be modified. When the Lisp reader is parsing the source code character stream it knows which package symbols belong to. So, for example, at compile time there is the information that symbol + refers to the standard CL:+ add function. There's no need to be smart. The CL package is static and set to stone but programmer is free to control symbols in other packages. For example, in some other package programmer can import all symbols from the standard CL package except shadow the CL:+ symbol. Then she can write her own extended version of + function (which possibly falls back to CL:+ in some situations). The dynamic effect with symbols is achieved through namespace tricks and yet the compiler can always trust the symbols of the CL package. I'm too much a beginner to tell if similar symbol concept is applicable to Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
* 2011-08-14T09:34:26+01:00 * Chris Angelico wrote: > Some day, I'd like to play around with a language where everything's > an expression and yet it doesn't look like LISP - just for the fun of > it. It probably won't be any more useful for real world coding, but > it'd be fun to tinker with. Of course it's a useful feature. Basically you can put any Lisp code in the world in the place of a Lisp expression. (setf variable (handler-case (some-code) (foo-error () "value 1") (bar-error () "value 2"))) is something like variable = try: return some_code() except FooError: return "value 1" except BarError: return "value 2" Sure, it's not a necessary feature. All we need is the machine language, but other than that there are differences in how languages let programmers express themselves. The above example emphasizes that "'variable' is being assigned". The "how" part gets less weight. If we put the assignment inside the handler-case or try-except forms we get the same result technically but the variable assignment becomes more hidden and is repeated, possibly several times. I understand that Python philosophy does not value freedom of expression that much. It values a general Pythonic rule which must obeyed and is called "readability". Other languages give too little or too much freedom. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
* 2011-08-14T01:44:05-07:00 * Chris Rebert wrote: > I've heard that Dylan is supposedly Lisp, sans parens. > http://en.wikipedia.org/wiki/Dylan_(programming_language) It has copied/derived many features from Lisps but it's not a dialect of Lisp because of the syntax and its consequences. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
* 2011-04-12T10:27:55+10:00 * James Mills wrote: > On Tue, Apr 12, 2011 at 9:17 AM, zildjohn01 wrote: >> This is an idea I've had bouncing around in my head for a long time >> now. I propose the following syntax: > > Maybe this is more appropriare for the python-ideas list ? > >> return? expr > > This syntax does not fit well within python ideology. I'm a simple Lisp guy who wonders if it is be possible to add some kind of macros to the language. Then features like this could be added by anybody. Lisp people do this all the time and there is no need for feature requests or any discussions. (with-returns ;; some code (return-if foo) ;; more code (return-if bar)) -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
* 2011-04-12T13:26:48-07:00 * Chris Rebert wrote: > I think Ben "Yahtzee" Croshaw's comments on open-world sandbox video > games (of all things) have a lot of applicability to why allowing > full-on macros can be a bad idea. > IOW, a language is usually better for having such discussions and > having a fairly coherent worldview enforced by the existence of a > managing authority. Thanks for the info. That's a strange view, and I must disagree. Lisp people certainly love the power they have. But different language, different philosophy, I guess. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
* 2011-04-19T00:40:09+10:00 * Alec Taylor wrote: > Please continue recommending Emacs. * 2011-04-19T02:41:11+10:00 * Alec Taylor wrote: > Please continue suggesting Python IDEs and/or fixes for the above > Cons. Emacs. * 2011-04-19T13:44:29+10:00 * Alec Taylor wrote: > Please continue with your recommendations. Emacs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
* 2011-04-18T21:17:17-07:00 * Westley Martínez wrote: > On Tue, 2011-04-19 at 06:51 +0300, Teemu Likonen wrote: >> * 2011-04-19T00:40:09+10:00 * Alec Taylor wrote: >>> Please continue recommending >> >> Vim. >> >> * 2011-04-19T02:41:11+10:00 * Alec Taylor wrote: >>> Please continue suggesting Python IDEs and/or fixes for the above >>> Cons. >> >> Vim. >> >> * 2011-04-19T13:44:29+10:00 * Alec Taylor wrote: >>> Please continue with your recommendations. >> >> Vim. > > /trollface.jpg You can recommend Vim, and I think that's an excellent option, but please don't edit the contents of other people's text. Quotes are quotes. This didn't cause any real harm but it's the principle. -- http://mail.python.org/mailman/listinfo/python-list
Development time vs. runtime performance (was: Fibonacci series recursion error)
* 2011-05-08T12:59:02Z * Steven D'Aprano wrote: > On Sun, 08 May 2011 01:44:13 -0400, Robert Brown wrote: >> I don't understand why you place Lisp and Forth in the same category >> as Pascal, C, and Java. Lisp and Forth generally have highly >> interactive development environments, while the other languages >> generally require an edit, compile, run it again debugging cycle. > > Good point. Perhaps I need to rethink where Lisp and Forth sit in the > development vs runtime trade-off continuum. > >> Python requires me to rewrite the slow bits of my program in C to get >> good performance. > > Python doesn't require you to re-write anything in C. If you want to > make a different trade-off (faster runtime, slower development time) > then you use a language that has made the appropriate trade-off. I believe that Robert Brown wanted to imply that Common Lisp is quite optimal on both sides. It supports dynamic interactive development and yet it has implementations with very efficient compilers. The trade-off is not necessarily between the two. But of course "development time" is a nicely vague concept. Depending on the argument it can include just the features of language and implementation. Other times it could include all the available resources such as documentation, library archives and community mailing lists. All these can reduce development time. -- http://mail.python.org/mailman/listinfo/python-list
Learning new languages (was: checking if a list is empty)
* 2011-05-11T20:26:48+01:00 * Hans Georg Schaathun wrote: > On Wed, 11 May 2011 14:44:37 -0400, Prasad, Ramit >wrote: >> I claim to be able to program (Java/Python), but would be absolutely >> lost programming in Lisp. It is more than just "learning the syntax", >> it includes a thought paradigm as well. > > OK. I should written 'how to program imperatively' ... 'new imperative > language'. Or substitute functional/logical/whatever for imperative. Common Lisp is an imperative language. It is also functional and object-oriented language. It does not force any paradigm but supports many. Thus, it is called a multi-paradigm language. I understand that Lisp can be scary, though. Lisp code looks weird and it seems that the myth that it's a functional language can't be busted. Anyway, I agree with this: * 2011-05-11T19:05:31+01:00 * Hans Georg Schaathun wrote: > Someone who knows how to program is never clueless starting a new > language. Newbie, may be, but he knows most of the constructions > and semantic principles to look for; most of it is learning the > syntax. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
* 2011-05-24T06:05:35-04:00 * D'Arcy J. M. Cain wrote: > On Tue, 24 May 2011 09:00:14 +0300 > "Octavian Rasnita" wrote: >> %d = @l; >> >> Please tell me if Python has a syntax which is more clear than this >> for doing this thing. > > How is that clear? "Shorter" != "clearer." A Python programmer looking > at that sees line noise. I'm a Lisp programmer who sees (some) Python code as line noise. >> I am just defending a language which has a clearer syntax for doing >> some things, and a shorter code for other > > Are Perl programmers aware of some imminent worldwide shortage of > electrons that Python programmers are not? Why is there this obsession > with shortness? I don't know but from the point of view of a Lisp programmer Python has the same obsession. Not trolling, I just wanted to point out that these are just point of views. I don't actually care that much about these things. -- http://mail.python.org/mailman/listinfo/python-list
Condition signals and restarts, resumable exceptions (was: Comparison with False - something I don't understand)
* 2010-12-06 00:14 (-0800), Paul Rubin wrote: > You know, I've heard the story from language designers several times > over, that they tried putting resumable exceptions into their > languages and it turned out to be a big mess, so they went to > termination exceptions that fixed the issue. Are there any languages > out there with resumable exceptions? As some people have pointer out Common Lisp is one of those languages. I don't know anything about language design, I'm just a hobbyist programmer, but I think Common Lisp's condition system and its restarts are straight-forward and easy to understand from programmer's point of view. Here's the relevant chapter in Peter Seibel's Practical Common Lisp: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html -- http://mail.python.org/mailman/listinfo/python-list
Object-oriented (was: Is Python a functional programming language?)
* 2010-05-15 09:42 (-0700), travis wrote: > PS: Why do people call LISP object-oriented? Are they smoking crack? > No classes, no methods, no member variables... WTF? Maybe because Common Lisp has a strong support for object-oriented programming. Peter Seibel: Practical Common Lisp Generic functions and methods (chapter 16) http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html Classes (chapter 17) http://www.gigamonkeys.com/book/object-reorientation-classes.html Paul Graham: On Lisp Object-Oriented Lisp (chapter 25) http://www.bookshelf.jp/texi/onlisp/onlisp_26.html#SEC156 Wikipedia: Common Lisp Object System http://en.wikipedia.org/wiki/Common_Lisp_Object_System -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
* 2010-07-04 10:03 (+0200), Stefan Behnel wrote: > The main reason why Python is slow for arithmetic computations is its > integer type (int in Py3, int/long in Py2), which has arbitrary size > and is an immutable object. So it needs to be reallocated on each > computation. If it was easily mappable to a CPU integer, Python > implementations could just do that and be fast. But its arbitrary size > makes this impossible (or requires a noticeable overhead, at least). > The floating point type is less of a problem, e.g. Cython safely maps > that to a C double already. But the integer type is. You may be right. I'll just add that Common Lisp's integers are of arbitrary size too but programmer can declare them as fixnums. Such declarations kind of promise that the numbers really are between most-negative-fixnum and most-positive-fixnum. Compiler can then optimize the code to efficient machine instructions. I guess Python might have use for some sort of (defun foo (variable) (declare (type fixnum variable)) ...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Q for Emacs users: code-folding (hideshow)
* 2010-07-16 06:29 (-0700), ernest wrote:
> I tried the outline-mode and it seemed to work. It can collapse
> different blocks of code, such as functions, classes, etc.
>
> However, I never got used to it because of the bizarre key bindings.
I use outline-minor-mode and the code below to make key bindings fast
and easy. Alt + up/down arrow will go to previous/next heading or code
block. Alt + left/right will close or open one sublevel. And that's
about it. My code is slightly modified version of the code from
http://www.emacswiki.org/emacs/OutlineMinorMode
Note that on that page there is also a tip to use Vim-like manual fold
markers (like the Vim's default "{{{").
;; outline-mode-easy-bindings.el
;;
;; Installation: Store this file as outline-mode-easy-bindings.el
;; somewhere in your load-path and create hooks for outline modes to
;; load this automatically, for example:
;; (add-hook 'outline-mode-hook 'my-outline-easy-bindings)
;; (add-hook 'outline-minor-mode-hook 'my-outline-easy-bindings)
;;
;; (defun my-outline-easy-bindings ()
;; (require 'outline-mode-easy-bindings nil t))
(defun outline-body-p ()
(save-excursion
(outline-back-to-heading)
(outline-end-of-heading)
(and (not (eobp))
(progn (forward-char 1)
(not (outline-on-heading-p))
(defun outline-body-visible-p ()
(save-excursion
(outline-back-to-heading)
(outline-end-of-heading)
(not (outline-invisible-p
(defun outline-subheadings-p ()
(save-excursion
(outline-back-to-heading)
(let ((level (funcall outline-level)))
(outline-next-heading)
(and (not (eobp))
(< level (funcall outline-level))
(defun outline-subheadings-visible-p ()
(interactive)
(save-excursion
(outline-next-heading)
(not (outline-invisible-p
(defun outline-hide-more ()
(interactive)
(when (outline-on-heading-p)
(cond ((and (outline-body-p)
(outline-body-visible-p))
(hide-entry) (hide-leaves))
(t (hide-subtree)
(defun outline-show-more ()
(interactive)
(when (outline-on-heading-p)
(cond ((and (outline-subheadings-p)
(not (outline-subheadings-visible-p)))
(show-children))
((and (not (outline-subheadings-p))
(not (outline-body-visible-p)))
(show-subtree))
((and (outline-body-p)
(not (outline-body-visible-p)))
(show-entry))
(t (show-subtree)
(let ((major outline-mode-map)
(minor outline-minor-mode-map))
(define-key major (kbd "M-") 'outline-hide-more)
(define-key major (kbd "M-") 'outline-show-more)
(define-key major (kbd "M-") 'outline-previous-visible-heading)
(define-key major (kbd "M-") 'outline-next-visible-heading)
(define-key major (kbd "C-c J") 'outline-hide-more)
(define-key major (kbd "C-c L") 'outline-show-more)
(define-key major (kbd "C-c I") 'outline-previous-visible-heading)
(define-key major (kbd "C-c K") 'outline-next-visible-heading)
(define-key minor (kbd "M-") 'outline-hide-more)
(define-key minor (kbd "M-") 'outline-show-more)
(define-key minor (kbd "M-") 'outline-previous-visible-heading)
(define-key minor (kbd "M-") 'outline-next-visible-heading)
(define-key minor (kbd "C-c J") 'outline-hide-more)
(define-key minor (kbd "C-c L") 'outline-show-more)
(define-key minor (kbd "C-c I") 'outline-previous-visible-heading)
(define-key minor (kbd "C-c K") 'outline-next-visible-heading))
(provide 'outline-mode-easy-bindings)
--
http://mail.python.org/mailman/listinfo/python-list
Man pages and info pages (was: Python documentation too difficult for beginners)
* 2010-11-02 18:43 (UTC), Tim Harig wrote: > The manual format contains all of the information on one page that can > be easily searched whereas the info pages are split into sections that > must be viewed individually. With the man pages, you can almost always > find what you want with a quick search through the document. Info > pages are much harder to use because you have to try and figure out > which section the author decided to place the information that you are > looking for. There is also the problem that people are less familiar with info browsers than the usual "less" pager which is used by "man" command. With the text terminal info browser called "info" as well as Emacs' info browser you can use command "s" (stands for "search"). It prompts for a regexp pattern to search in the whole document, including subsections etc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Man pages and info pages
* 2010-11-02 19:36 (UTC), Tim Harig wrote: > On 2010-11-02, Teemu Likonen wrote: >> There is also the problem that people are less familiar with info >> browsers than the usual "less" pager which is used by "man" command. > > I thoroughly agree. The default info viewers are quite possibly the > most counterintuitive programs I have ever encountered. I never did > bother to learn how to use them. I instead installed the more > intuitive pinfo program. It seems that we only agree on the part that I explicitly wrote about: people are less familiar with info browsers than "less" pager. I didn't mean to imply any reasons why this might be the case. I think "info" browser is intuitive and easy to use. The basic commands: Enter Follow a link (down to node) u up node level h help (general how-to) ? help (commands) s search Arrow keys, page up, page down keys work as usual. What's counter-intuitive in it? >> With the text terminal info browser called "info" as well as Emacs' >> info browser you can use command "s" (stands for "search"). It >> prompts for a regexp pattern to search in the whole document, >> including subsections etc. > > Right, pinfo offers this as well; but, then you have to figure out > where in the nodes that the search has taken you and how to navigate > from that node to find additional information that you may need. I usually return to the top node with "t" command or go one or more levels up in the tree with "u" command. The first line in the window tells where I am. -- http://mail.python.org/mailman/listinfo/python-list
