automatic static types (metaclass), attribute-order extraction = python instead of XML-likes - and some RequestsForEnhancements
svilen
sdobrev at sistechnology.com
Thu Mar 18 15:50:38 EST 2004
hello again.
i'm now into using python instead of another language(s) for
describing structures of data, including names, structure,
type-checks, conversions, value-validations, metadata etc. And i have
things to offer, and to request.
And a lot of ideas, but who needs them....
here's an example (from type_struct.py):
[this is still in progress. it would be used for direct generating of
(ordered) byte structures as well. And user interface forms...]
> from statictype2 import StaticTyper, StaticType
>
> class Record( StaticTyper) :
> def _validator_ID( v):
> if v<=0: raise ValueError, 'value must be positive int, not %r' % v
> return v
> def _validator_Date( v):
> if isinstance( v, tuple) and len(v)==2:
> v = '.'.join([ str(x) for x in v] )
> elif not isinstance( v, str):
> raise TypeError, 'expect str or tuple( str,str), not %r of type %s' % (v,type(v))
> return v
>
> ID = StaticType( int, auto_convert=True, validator=_validator_ID )
> Date = StaticType( None, validator= _validator_Date)
> Count= StaticType( int)
> Key = StaticType( str, default_value= 'empty/key/used')
>
> class Input_Record( Record):
> Checksum = Tchecksum
>
> class Output_Head( StaticTyper):
> timestamp = StaticType( str, default_value= 'none')
>
> class Output_Record( Output_Head, Record):
> pass
> ....
> r = Input_Record()
> r.ID = '357'
> r.Date = (10,'03')
> r.Count = 2
> ....
here's output of `python2.3 type_struct.py`:
<module '__main__' from 'test_struct.py'>:
- order:
['Tchecksum', 'r', 'a', 'v']
<class '__main__.Record'>:
- order:
['ID', 'Date', 'Count', 'Key']
- flattened order:
ID = <property object at 0x401795a4>
Date = <property object at 0x4017993c>
Count = <property object at 0x40179554>
Key = <property object at 0x401799b4>
<class '__main__.Input_Record'>:
- order:
['Checksum']
- flattened order:
ID = <property object at 0x401795a4>
Date = <property object at 0x4017993c>
Count = <property object at 0x40179554>
Key = <property object at 0x401799b4>
Checksum = <property object at 0x40179694>
<class '__main__.Output_Head'>:
- order:
['timestamp']
- flattened order:
timestamp = <property object at 0x40179be4>
<class '__main__.Output_Record'>:
- order:
[]
- flattened order:
timestamp = <property object at 0x40179be4>
ID = <property object at 0x401795a4>
Date = <property object at 0x4017993c>
Count = <property object at 0x40179554>
Key = <property object at 0x401799b4>
['ID', 'Date', 'Count', 'Key', 'Checksum']
<__main__.Input_Record object at 0x40433bec>
ID 357
Date 10.03
Count 2
Key empty/key/used
Checksum 52bf113125e445e072387820ccd0a983
==================
static_type1 is if using const BaseTypes as templates for actual classes.
static_type2 is more powerful as stuff goes direct in the actual class.
you can run each (execpt the statictype_base), they have more tests
and examples in them.
each set/get for these fields in the instances are captured as
properties.
StaticType's supports exact type checks and automatic conversion,
default_value lazy setting, and a validator than can add value checks
and/or replace type/auto_conv if needed. Probably more can be added,
when needed (e.g. things about representation / formatting, naming, UI
etc)
there's also a method .test_validator() to test your validators
_before_ using them as that can be nasty.
------
you don't need anything around assignemt_order.py unless u need the
order of the fields to follow the order they are written in the python
file (Which is the best place IMO. WYSIWYG - What You See Is What You
Get.)
my previous post about extracting the order of assignments in
module/class namespaces didn't get much response, well, i wrote the
damned thing.
This assignment_order.py hack (parsing the source again to get the
order) would not be needed IF any of the following was available:
- order of variable assignments in class namespace was given to the
__metaclass__, as separate argument or if the dict argument is not
dict-mapping but iterable of (key,value) tuples, it is so easy to turn
it into dictionary - just dict(iterable)
- at very low-level, internal frame object's f_locals() could return
iterable of key,value tuples instead of plain dict.
The order is there in the execution frame, it just not reachable from
python.
-------
thes can go well as examples:
the static_types could go with Demo/newmetaclass/
the assignement_order could go with Demo/parser/
==============================================================================
now, about the requests. i want to see python more symmetrical and
consistent. this way it could be advertised/marketed easier to places
with serious portability AND maintainability thinking, over other
pure-procedural languages. Is anyone is interested in that?
- i want the documentation to be fully interlinked (in current
hierarchy) and to have another alternative hierarchy - from
usage-point of view - if i say list, ALL about lists should be there,
and not separated in 3+ different places, so either a lot bookmarks
are to be kept, or 10+ clicks to get the next piece of info. Same goes
for most data/execution things. it can be done as simple
links-only-layer - i dont mind. Probably data-model and execution
model are best to follow as template.
- order of variable assignments in class namespace to be
offered/passed to the metaclass, as separate argument or the (now
dict) namespace argument to be properly ordered iterable (moving the
dict creation from C into python metaclass - well, if any.
type(name,bases,dictiterable) can still do it in C). Order can be
safely ignored if not needed.
- i want somehow to turn the { MY order of dict values here } syntax
into as-is-ordered thing! Could be even with some pragma switch that
would create my dictOrder (or some builtin one) instead of internal
hashed mapping! This is equivalent to above, but for plain value dicts
(and not the attribute namespaces, represented as dicts). Function
keyword args can be another thing to keep order of - if required. (a
sort of execution-namespace control pragma)
- the notion of iterators/ generators, and notion of interfaces are so
powerful but so poorly advertised - and used. Now there is itertools -
PERFECT! but i have to import it while waster things like map() are
still sitting at plain view - hence - from lamer's point of view -
easier to use.
- what about try: finally: over generators? PEP288. gee, 50 lines of
iterator class instead of 5 with yield just becasue i _have_ to close
a file...
- all builtin functions that do not add value to the language as
language should move into separate module (e.g. map, zip, sum etc...
vs callable, isinstance, builtin type-constructors) and not be so
over-emphasized.
- all interfaces (not types!) - e.g. containers (__get/set/delitem) -
should be named 'interfaces' - now this is vaguely called 'customization'.
- how do i check if x is iterable?
- (i see this goes in python2.4, PEP289) The perfect idea of in-place
generators - which is now used for filling lists and maybe dicts in
future, should be allowed everywhere where iterables can be. e.g. i want
my_method_with_iterator( (k, 2*k, keys[k]) for k in [a,b,c] )
to work without need of intermediate list/dict/whatever.
- IMO most funcs now needing a list or dict should be happy with
proper iterable. ( Eventualy funcs needing only iterable over single
values may have *args instead, and for key-balue tuples **kargs
instead. but this isnt that important.)
- i would like to be able to control somehow what constructors are
available for example to eval() - so i can patch them (operator *) -
so things like
eval( '[ 1,2,3 ] * 500000000')
or
eval( ' "abcdef" * 500000000')
could not bomb the machine, and give syntax error or else.
which means safer if not safe expressions. (again a sort of
execution-namespace control)
- i want the list head/tail notation:
a, b, *c = somelisthere
apart of all else, it helps future maintenance and readability of
the program, and this IS important if python is to be used for serios
things in serios places. ah, i might like simmetrical thing for dicts
but you will not like it:
'a':var1, 'b':var2, **rest = dictionaryhere
- uh there were more, but i keep forgetting...
if i can help to do something of these or others, or you want ideas of
how/when/why something can be implemented for the python, call ...
there's plenty of experience in a lot of languages and languages in
general, as well human-machine related things, even psychology. And i
DO want to support and make better the good thing what python is.
just in case this newserver of mine dies (and it does often), do CC to
me mail.
[btw, anyone interested in very thin framework for UI-via-html-forms?
all is in python, even the form description, html etc.
it's 75%-done, with most things showable.
]
ciao
svilenD
=================
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: statictype_base.py
URL: <http://mail.python.org/pipermail/python-list/attachments/20040318/6bd9c6f3/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: statictype2.py
URL: <http://mail.python.org/pipermail/python-list/attachments/20040318/6bd9c6f3/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: statictype1.py
URL: <http://mail.python.org/pipermail/python-list/attachments/20040318/6bd9c6f3/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: assignment_order.py
URL: <http://mail.python.org/pipermail/python-list/attachments/20040318/6bd9c6f3/attachment-0003.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_struct.py
URL: <http://mail.python.org/pipermail/python-list/attachments/20040318/6bd9c6f3/attachment-0004.ksh>
More information about the Python-list
mailing list