A 'Python like' language

[Mark Hahn]

> --Take advantage of iterators early on for return values to avoid
> things like having both dict.items() and dict.iteritems().

Interestiong idea.  Generators are fully supported so I could do this now.
So gens would have to be allowed absolutely everywhere lists are allowed (is
trhis possible?).  Or are you thinking the user should type
List(dict.items()) ?

> --Choose "{:}" syntax for empty dict creation to reserve "{}" for
> sets.  (Or: use "{}" for both, and do automatic "set-to-dict

Also cool.  Maybe <> for sets?  Prothon doesn't support <> as != so it is
free.

> --Functions that return multiple, but unique, values should return a
> set, not a list, to communicate same (ex: dict.keys(), dir(), etc.).

Also cool.

> --Dict should inherit from Set.

Also cool (I feel like the credits of Holy Grail saying Also wik).

> --No Dict.update(), since this is now identical with Set.__ior__()
> (i.e. d1 |= d2).
>

Cool.

... snipped ...

All cool.

> --With prothon's "immutability" bit and other considerations, does the
> language need both tuples AND lists?

I like this a lot.  Tuples are already implemented internally as lists.

... more good stuff snipped ...

> Off the cuff, but only two cents....

More like a few dollars.  This is really good stuff.  Can I talk you into
hanging out on the Prothon list now and then, at least until we get the core
language sorted out?


"Zipher" <average at moonman.com> wrote in message
news:30985729.0403291959.2dafe546 at posting.google.com...
> [Mark Hann]
> > Obviously Prothon is not Python compatible, so I have taken the liberty
of
> > implementing many changes that have been imagined for the almost
mythical
> > Python 3.0...
>
> Gee, my love of Python makes me feel a little guilty about looking at
> another language, but Prothon does look appealing.  Classes really do
> start looking archaic...  Would a threesome be out of the question?
>
> My Python3k suggestions for Prothon:
>
> --Take advantage of iterators early on for return values to avoid
> things like having both dict.items() and dict.iteritems().
> (Decorators add even larger possibilities for fresh syntax and other
> considerations.)
>
> --Choose "{:}" syntax for empty dict creation to reserve "{}" for
> sets.  (Or: use "{}" for both, and do automatic "set-to-dict
> promotion" upon encountering a (key, value) assignment.)
>
> --Functions that return multiple, but unique, values should return a
> set, not a list, to communicate same (ex: dict.keys(), dir(), etc.).
> (Consider iterator caveat above, however.)
>
> Such functions often have surprising uses for set operations anyway.
> Consider, for example, using set operations on dir() to answer
> questions like Which parent functions/variables get re-assigned in the
> child class? or What new fns/vars does this child add?
>
> --Dict should inherit from Set.
>
> --No Dict.update(), since this is now identical with Set.__ior__()
> (i.e. d1 |= d2).
>
> Could follow Python's behavior with regard to key collisions (a matter
> of contentious debate if I remember), OR perhaps even better:
>
> --Dict object could contain optional "collision function attribute"
> that is called to resolve values on key collisions.
>
> Consider, for example, an easy Bag(Dict) object with said attribute
> assigned to "operator.add" for the union method(s).  This would also
> maintain the >10x speed factor (in Python anyway) of using underlying
> C-implmentation rather that hand iteration through dicts.
>
> --With prothon's "immutability" bit and other considerations, does the
> language need both tuples AND lists?
>
> Also, perhaps this is an opportunity to address handling single vs.
> multiple element parameters.  That is, how to avoid things like both
> list.extend() and list.append() -- which one adds only a single
> element?  If the language had a way to indicate whether a parameter
> should be treated as an atom vs. a collection, it would reduce a lot
> of ambiguous (within an object) and inconsistent (across objects)
> method names and the unending debate that seems to occur each time.
>
> Perhaps Python's later enhancements (decorators?) could make this more
> natural, or maybe a new construct would be required...
>
> BTW, I vote in favor of character case being semantically meaningful.
> I like the language informing me (and enforcing) semantic meaning
> through syntax (much like Python's indention).  Ditto for bang-endings
> (ex. list.sorted!).
>
> Off the cuff, but only two cents....
>
> Zipher