Thanks Alexander for the effort! With so many new features and improvements, I'd like to see a detailed documentation as the guideline or introduction to YAQL for developer or orchestrator , we can start with simple samples (maybe it have been covered in [1] for a little bit) and then advanced usage, since I could see little content in [2] currently .
what do you think? [1] https://pypi.python.org/pypi/yaql/1.0.0.0rc1 [2] https://yaql.readthedocs.org On Wed, Aug 5, 2015 at 10:47 AM, Dmitri Zimine <[email protected]> wrote: > Thank you Stan! > > On Aug 4, 2015, at 3:07 PM, Stan Lagun <[email protected]> wrote: > > Dmitry, this depends on how you're going to use yaql. yaql 1.0 has so > called legacy mode that is a layer on top of yaql that brings nearly full > backward compatibility including some of the things that were wrong in yaql > 0.2. Use this mode when backward compatibility is a must. Without it the > following changes may affect queries written for 0.2: > > 1. There are no more tuples. foo(a => b) will mean now f(a='b') instead of > foo(tuple('a', 'b')) as it was in yaql 0.2. However dict(key1 => value1, > key2 => value2) and several other functions with the same syntax work > exactly how they used to work in 0.2 > 2. Contradictory to the first point there are no more lists. Yaql works on > immutable structures (tuple, frozenset and yaql1 own FrozenDict). All > operations that seem to modify data in fact return modified copies. All > input data will be automatically converted to their immutable versions and > converted back upon completion. This has 2 side effects: a) if you have > custom yaql functions they should follow the same pattern b) even if your > input data were build from tuples etc output will still use lists (e.g. > JSON format) > 3. $dict.key will raise KeyError for missing keys instead of returning > None. Also key must be a valid keyword and cannot start with 2 underscores. > There are many other ways to retrieve dictionary value: $dict.get(value), > $dict.get(value, default), $dict[value], $dict[value, default] > 4. In yaql 0.2 every function could be called as a method. So $x.foo() was > the same as foo($x). In yaql 1.0 it is up to function to decide if it wants > to be a function (foo($x), method ($x.foo()) or extension method (both > syntax). Considering that yaql handles different function overloads > $x.foo() may be a valid expression and execute something completely > different from foo($x). > Most of type-specific functions are declared as a methods. So you no > longer can say toUpper(str) but only str.toUpper() > 5. yaql 0.2 had very few functions. yaql 1.0 has huge (~260 > functions/operators etc) standard library. However several of the 0.2 > functions now have different signature or name, replaced with better > alternative or just accept additional (optional) parameters > 6. $collection[$ > 0] doesn't work anymore. Use $collection.select($ > 0) > for that > > > > Sincerely yours, > Stan Lagun > Principal Software Engineer @ Mirantis > > <[email protected]> > > On Tue, Aug 4, 2015 at 9:57 PM, Dmitri Zimine <[email protected]> > wrote: > >> This is great news Alex, was looking forward to it, will be happy to >> migrate Mistral. >> >> Some heads-up on what syntactically changed would be much appreciated to >> pass on to our users; >> we likely will catch much of them with Mistral tests, but some may bubble >> up. >> >> DZ. >> >> On Jul 27, 2015, at 2:04 AM, Alexander Tivelkov <[email protected]> >> wrote: >> >> > Hi folks, >> > >> > We are finally ready to release the 1.0.0 version of YAQL. It is a >> > huge milestone: the language finally looks the way we initially wanted >> > it to look. The engine got completely rewritten, tons of new >> > capabilities have been added. Here is a brief (and incomplete) list of >> > new features and improvements: >> > >> > * Support for kwargs and keyword-only args (Py3) >> > * Optional function arguments >> > * Smart algorithm to find matching function overload without side >> effects >> > * Ability to organize functions into layers >> > * Configurable list of operators (left/right associative binary, >> > prefix/suffix unary with precedence) >> > * No global variables. There can be more than one parser with >> > different set of operators simultaneously >> > * List literals ([a, b]) >> > * Dictionary literals ({ a => b}) >> > * Handling of escape characters in string literals >> > * Verbatim strings (`...`) and double-quotes ("...") >> > * =~ and !~ operators in default configuration (similar to Perl) >> > * -> operator to pass context >> > * Alternate operator names (for example '*equal' instead of >> '#operator_=') >> > so that it will be possible to have different symbol for particular >> operator >> > without breaking standard library that expects operator to have well >> > known names >> > * Set operations >> > * Support for lists and dictionaries as a dictionary keys and set >> elements >> > * New framework to decorate functions >> > * Ability to distinguish between functions and methods >> > * Switchable naming conventions >> > * Unicode support >> > * Execution options available to all invoked functions >> > * Iterators limitation >> > * Ability to limit memory consumption >> > * Can work with custom context classes >> > * It is possible to extend both parser and set of expression classes >> > on user-side >> > * It is possible to create user-defined types (also can be used for >> > dependency injection) >> > * Legacy yaql 0.2.x backward compatibility mode >> > * Comprehensive standard library of functions >> > * High unit test coverage >> > * Delegate and lambda support, including higher order lambdas >> > >> > etc, etc. >> > >> > So, this is a big change. >> > >> > And as it always happens when moving from 0.something to 1.x the >> > breaking changes are inevitable. We have included the "backwards >> > compatibility mode", but it may not address all the possible concerns. >> > >> > So. >> > We have released a release candidate 1 of yaql 1.0.0 on pypi: [1] >> > It includes all the new functionality and is likely to be identical to >> > final release (that's why it is RC after all) and we strongly >> > encourage all the yaql users (Murano and Mistral first of all) to try >> > it and prepare "migration patches" to use it. When the final release >> > is out, we'll update the global requirements to yaql >= 1.0.0, which >> > is likely to break all your gate checks unless you quickly land a >> > migrating patch. >> > >> > Please email us any concerns or contact me (ativelkov) or Stan Lagun >> > (slagun) directly in IRC (#murano) if you need some quick help on yaql >> > 1.0 or migrating from 0.2.x >> > >> > Happy yaqling! >> > >> > >> > [1] https://pypi.python.org/pypi/yaql/1.0.0.0rc1 >> > >> > >> > -- >> > Regards, >> > Alexander Tivelkov >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> [email protected]?subject:unsubscribe >> <http://[email protected]/?subject:unsubscribe> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> <http://[email protected]/?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- *Regards!* *-----------------------------------* *Lingxian Kong*
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
