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/2002-May/024317.html below:

[Python-Dev] the nature of the symbols in types

[Python-Dev] the nature of the symbols in types [Python-Dev] the nature of the symbols in typesGuido van Rossum guido@python.org
Thu, 23 May 2002 10:18:30 -0400
> I suspect most of these uses could be replaced fairly easily by the
> authors of code that uses them, though it wouldn't be quite as
> automatic as for the common symbols.  Some could probably just be
> deleted.  anything that can just be gotten by calling type() might
> be a candidate.  For some, it should be fairly straightforward to
> add appropriate symbols to builtins.  'buffer', 'slice' and 'xrange'
> could be replaced by a callable type.  Others could be just
> non-callable objects that expose the various type objects.  Adding
> the obvious symbol for 'class' to builtins obviously wouldn't work.

Now these are things for which I'd like to see patches!  (And the
'string' common basetype.)

--Guido van Rossum (home page: http://www.python.org/~guido/)




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