Re: [openstack-dev] [murano] [mistral] [yaql] Prepare to Yaql 1.0 release
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
wrote:
> Thank you Stan!
>
> On Aug 4, 2015, at 3:07 PM, Stan Lagun 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
>
>
>
> On Tue, Aug 4, 2015 at 9:57 PM, Dmitri Zimine
> 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
>> 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
Re: [openstack-dev] [murano] [mistral] [yaql] Prepare to Yaql 1.0 release
Thank you Stan!
On Aug 4, 2015, at 3:07 PM, Stan Lagun 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
>
>
> On Tue, Aug 4, 2015 at 9:57 PM, Dmitri Zimine 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
> 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
Re: [openstack-dev] [murano] [mistral] [yaql] Prepare to Yaql 1.0 release
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
On Tue, Aug 4, 2015 at 9:57 PM, Dmitri Zimine
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
> 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
> > brea
Re: [openstack-dev] [murano] [mistral] [yaql] Prepare to Yaql 1.0 release
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 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [murano] [mistral] [yaql] Prepare to Yaql 1.0 release
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
