Subject: Re: Immutable lists (was: Re: Type annotations: annotating generators) - msg#00670

Previous Message by Date: click to view message preview

Re: Immutable lists (was: Re: Type annotations: annotating generators)

On May 22, 2006, at 4:24 PM, Collin Winter wrote: > The main use case I'm thinking of is parameterizing mapping types. Say > I wanted a set of Number lists: in Python 2, I'd just convert the > lists to tuples before adding them to the set. However, in Python 3, > converting the lists to tuples will cause any annotations like > set[list[Number]] to reject the candidate set. I'd like to avoid > having annotations like set[tuple & EveryElementIs(Number)]. Also, > before anyone proposes it, I don't think "just remove the offending > annotations" is a viable solution. > How about tuple[T] then? tuple[T,] can represent a 1-tuple. -Tony

Next Message by Date: click to view message preview

Re: Fwd: proposal: disambiguating type

tomer filiba wrote: > i suggest splitting this overloaded meaning into two separate builtins: > * type(name, bases, dict) - a factory for types > * typeof(obj) - returns the type of the object Or just drop the function usage altogether and make __class__ the one obvious way to find out something's class/type. -- Greg

Previous Message by Thread: click to view message preview

Re: Immutable lists

> On 5/25/06, Nick Coghlan <ncoghlan@xxxxxxxxx> wrote: > >>Yes - I'm saying tuple[T1, T2] should describe an arbitrary length tuple whose >>elements are 2-tuples, *instead* of being equivalent to (T1, T2). Ah, I see. Yes, that would work, although it would make tuple somewhat special in that some parameterisations of it would not be expressible as typename[params]. -- Greg

Next Message by Thread: click to view message preview

Fwd: proposal: disambiguating type

forwarded from c.l.p -- they said it is better suited for python3k as itbreak things-----typing "help(type)" gives the following documentation:    >>> help(type)     Help on class type in module __builtin__:    class type(object)     |  type(object) -> the object's type     |  type(name, bases, dict) -> a new type"type" behaves both as a function, that reports the type of an object, and as a factory type for creating types, as used mainly withmetaclasses.calling the constructor of types, like lists, etc., is expected tocreate a new instance of that type -- list() is a factory for lists, dict() is a factory for dicts, etc.but type() breaks this assumption. it behaves like a factory whencalled with 3 params, but as a function when called with one param.i find this overloading quite ugly and unnecessary. more over, it can cause abominations like>>> class mymetaclass(type):...     pass...>>> mymetaclass(1)<type 'int'>or>>> list.__class__(1)<type 'int'> i suggest splitting this overloaded meaning into two separate builtins:* type(name, bases, dict) - a factory for types* typeof(obj) - returns the type of the objectthis way, "type" retains its meaning as the base-class for all types, and as a factory for types, while typeof() reports the object's type.it's also more intuitive that typeof(1) returns, well, the *type of*the object 1.no new keywords are needed, and code is always allowed to override builtin functions, so there's no need for "from __future__ import blah" kind of stuff.---notes on compatibility: it would be easy to write an external toolthat mechanically replaces "type(obj)" with "typeof(obj)"... which also proves the point type(obj) and type(n, b, d) are fundamentally different and shouldn't share the same overloaded name.comments?-tomer