Re: A 'Python like' language
[Mark Hann][color=blue]
> 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...[/color]
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.a dd" 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 "immutabili ty" 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
[Mark Hann][color=blue]
> 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...[/color]
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.a dd" 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 "immutabili ty" 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
Comment