A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2007-February/071154.html below:

[Python-Dev] Recent experience with the _ast module

[Python-Dev] Recent experience with the _ast moduleCollin Winter collinw at gmail.com
Thu Feb 15 05:40:19 CET 2007
On 2/14/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Collin Winter schrieb:
> > 2) It turned out that {BinOp, BoolOp,AugAssign,etc}.op were already
> > singleton instances of their respective classes. I've changed
> > asdl_c.py to no longer emit the *_singleton names and to use the
> > corresponding *_type types in their place, which will enable me to
> > write "node.op is _ast.Add", etc.
>
> I don't really like this - it's inconsistent. I'd rather prefer
> if the singletons where exposed under a name, e.g.
> _ast.Add.singleton, or _ast.add (if that doesn't cause conflicts).

What's inconsistent about it? That classes are being used for the
_ast.{Add,Sub,Mult,etc} names?

I don't see the need for both _ast.Add and _ast.Add.singleton or
_ast.add or however else it might be spelled. I'd be perfectly happy
doing something like "_ast.Add = object()" (when initializing the _ast
module), so long as I can write "node.op is _ast.Add", "node.op ==
_ast.Add", or something equally brief and to-the-point.

Collin Winter
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4