[Python-ideas] Adding "Typed" collections/iterators to Python

[Joshua Landau]

On 19 December 2011 22:28, Nathan Rice <nathan.alexander.rice at gmail.com>wrote:

> On Mon, Dec 19, 2011 at 3:37 PM, Joshua Landau
> <joshua.landau.ws at gmail.com> wrote:
> > ...or we could just extend Pep 225 (deferred) with "~." so we have "['a',
> > 'b', 'c']~.upper()" [syntax debatable]. You don't get the type-checking
> but
> > that seemed more of a problem to me, as I'm not a real duck.
>
> That does run into some of the same problems w.r.t duck typing, and
> solutions to problems with overloaded operators are hard to google
> for.  If the method calls were aliased, google searches would be
> easier and less experienced users wouldn't have to worry about
> wrestling with operator overloading.


The thing is, "listofstrings.method()" is less obviously elementwise than
"listofstrings~.method()", *especially* if "~" becomes the default
elementwise character. So I have to disagree. Additionally,
"listofstrings~.method()" is easy to paste into an interpreter, and should
quickly yield enlightenment. I don't see that as a valid argument.


> That being said, I think
> elementwise operators are a great idea in a numeric/scientific
> context.
>

But not always in the same case as your broadcasting idea? The elementwise
operator is far more general, so I'd say it has a more general use-case in
response. Only a fraction of my code is of the "numeric/scientific" type,
and I'd lap up elementwise operators.


> There are of course both pros and cons to having type declarations.  I
> know that people do not like to be limited by a lack of foresight in
> their predecessors; I have run into unreasonable interface/type
> specifications and annoyances with  private/protected variables in
> Java and I would never want to see that infiltrate Python.  I think
> what I am trying to sell here is more akin to metadata than static
> types.  People should be able to basically keep doing what they are
> already doing, but have a reasonable mechanism to provide additional
> object metadata in a standard way that is easily accessible by
> downstream consumers.  That gives you a lot of the upsides of type
> declarations while staying Pythonic.
>

The thing is... what? This isn't a criticism. I'm genuinely lost as to what
you mean. I lost you on the "metadata" part. In what way is this metadata,
and in turn not typing? Can you do:
foo = "a b".split()
foo[1] = 1

If you can, then this whole idea should really be generalised more,
preferably to the elementwise operator level, as it's got no real type
constraints. If you can't, then how is it not typing? Again, this is a
genuine question. I'm home-taught, so please don't expect me to know the
lingo :P.

I actually love the idea of typing when done well. I've just started
Haskell (quite a shock to my Python'd brain) and I've
thoroughly enjoyed its type system. I just think that it has no place in
python. It only works in Haskell because Haskell is built on it, and types
can't go a-changin' (nor can values, for that matter). In python, this sort
of system will mean that typed code/arrays/iterators will severely grind
with untyped code/values/arrays/iterators.

Someone defines a 'typed collection or iterator', to paraphrase the title.
Someone else makes a goose-that-looks-like-a-duck, but doesn't have a beak.
With an untyped system - such as the current method or an elementwise
operator - that's fine as you just want it swim, but with your typed
container something has to go wrong! Either it crashed, which is
anti-duck-typing, or it falls back down, in which case you end up reverting
everything to the old method anyway.

Haskell gets around this by having both types and 'things that implement
things' and so could do this because it knows what everything implements.
But in python we don't know, and won't until all our dusty code is
rewritten. I apologise for using a language I've just started to learn as a
reference, but that's the best reference I've had.

*I really should check this, but it's late and I'm tired. If I've said the
same thing twice or rambled on about hexagonal motorised paintings for too
long, blame my cat...*

 Maybe a better option than having a "type contract" base for
> homogeneous collections is to give objects a metadata namespace with a
> loose schema, and declare it there?  As long as you could provide the
> metadata at object creation time you would still get all the same
> benefits, and it would avoid potentially overworking the class/mixin
> concept.
>
> > Your example:
> > my_string.split("\n").capitalize().join_items("\n")
> > to
> > "\n".join(my_string.split("\n")~.capitalize())
> >
> > And personally I like "string.join(lst)" over "lst.join_with(string)"...
>
> Of course, everyone has their own preferences; having a very small set
> of internally consistent ways to do something rather than just one way
> is good for this reason.
>
>
> Nathan
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>

Before anyone gets too many ideas about what is and isn't:
 >>> str.capitalize("ABCDEFGH")
'Abcdefgh'

Remember that these are predominantly lowercasing actions :P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111220/7ff500af/attachment.html>