Path: ...!3.eu.feeder.erje.net!feeder.erje.net!fu-berlin.de!uni-berlin.de!not-for-mail From: ram@zedat.fu-berlin.de (Stefan Ram) Newsgroups: comp.lang.python Subject: Re: Lists in Python versus other languages Date: 24 Jun 2024 11:25:13 GMT Organization: Stefan Ram Lines: 64 Expires: 1 Feb 2025 11:59:58 GMT Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: news.uni-berlin.de kWhC4lGr6mf1aHlEHXJ+3QTtqnrxgW5ikEvwNV3gu0/Cot Cancel-Lock: sha1:xyQbQo5qAJ4EVm8kgkqPvVKqsXo= sha256:uGEWXJ3ahmiREEpMSO4+Sq0yIbXf/AZtfZme8WutTho= X-Copyright: (C) Copyright 2024 Stefan Ram. All rights reserved. Distribution through any means other than regular usenet channels is forbidden. It is forbidden to publish this article in the Web, to change URIs of this article into links, and to transfer the body without this notice, but quotations of parts in other Usenet posts are allowed. X-No-Archive: Yes Archive: no X-No-Archive-Readme: "X-No-Archive" is set, because this prevents some services to mirror the article in the web. But the article may be kept on a Usenet archive server with only NNTP access. X-No-Html: yes Content-Language: en-US Bytes: 3471 Sebastian Wells wrote or quoted: >The thing that makes Python tuples different >from Python lists is that tuples are >immutable. Lisp doesn't have a type that >is "a list (or array) but it's immutable." Yeah, I was thinking about the mathematical term "tuple" here. In math, one doesn't really have just "tuples," but rather "2-tuples," "3-tuples," and so on. The number is a fixed part of the tuple's type. So, if one's dealing with a tuple representation made of dotted pairs in LISP, one'd need to know how many components are in it to interpret it correctly. While a list in LISP (with something like "replace CDR") can be dynamically extended, one can't extend a tuple because its size is fixed. In that sense, a LISP tuple (in the sense suggested by me) is more static than a LISP list. >It doesn't yield actual lists or tuples, so you can't use it the >way OP was suggesting, that is, the way you'd use the corresponding >Lisp feature. If one wants to parse Python code, like a tuple, the ast module does all the heavy lifting to set up an AST. Turning that into a real Python tuple takes just a bit of postprocessing. main.py import ast as _ast source = r''' ( 0, 1,( 2, 3 )) '''[ 1: -1 ] def postprocess( parse_result ): if isinstance( parse_result, _ast.Module ): return postprocess( parse_result.body[ 0 ] ) elif isinstance( parse_result, _ast.Expr ): return postprocess( parse_result.value ) elif isinstance( parse_result, _ast.Tuple ): return \ tuple( postprocess( element )for element in parse_result.elts ) elif isinstance( parse_result, _ast.Constant ): return parse_result.value print( postprocess( _ast.parse( source ))) stdout (0, 1, (2, 3)) In the case of simple tuples (with no calls or something), one can just use "literal_eval". main.py import ast print( ast.literal_eval( '( 0, 1,( 2, 3 ))' )) stdout (0, 1, (2, 3)) .