[openstack-dev] [murano] [mistral] [yaql] Prepare to Yaql 1.0 release
Lingxian Kong
anlin.kong at gmail.com
Thu Aug 6 15:24:48 UTC 2015
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 <dzimine at stackstorm.com>
wrote:
> Thank you Stan!
>
> On Aug 4, 2015, at 3:07 PM, Stan Lagun <slagun at mirantis.com> 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
>
> <slagun at mirantis.com>
>
> On Tue, Aug 4, 2015 at 9:57 PM, Dmitri Zimine <dzimine at stackstorm.com>
> 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 <ativelkov at mirantis.com>
>> 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:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
*Regards!*
*-----------------------------------*
*Lingxian Kong*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150806/e7b71ca5/attachment.html>
More information about the OpenStack-dev
mailing list