Bug Fix: Do not alter python run-time types

This fixes a bug discovered by Haoran and Callum - if you ask for two different typed collections one after the other, the type propagation system gets very confused because I was accidentally modifying a Python runtime type. This fixes that.

What's Changed

• Do not alter runtime types by @gordonwatts in #120

Full Changelog: 3.2.3...3.2.4

Do not alter python runtime types at... runtime

Testing the fix for runtime type alterations.

Full Changelog: 3.2.2...3.2.4b1

Use function names as clues for parsing

This is a bug-fix release to address a regression. The following should have parsed correctly but was failing with a "multiple-lambdas on one line" error:

• ds.Where(lambda e: e.met > 10).Select(lambda e: e.met)

What's Changed

• Use Function Names as Clues Parsing Lambda's by @gordonwatts in #116

Full Changelog: 3.2.2...3.2.3

Update package metadata

Minor updates to incorrect package metadata for pypi.

Full Changes

Full Changelog: 3.2...3.2.2

Release

There is something very broken about the last release, trying again.

Lambda Parsing Bug Fix

The engine that finds lambda's for translation in source code has received a major upgrade/change. It now uses the builtin python tokenize module.

• This makes it much more robust when dealing with comments, new lines, and other oddities.
• More safely checks are built in to catch mistakes in matching lambda expressions to the intended code.

There is one regression - which is caused because this code is more rigorous in how it treats the source code: Using the python \ continuation character means that the line is really treated as a single line. This was not the case with the previous version of the parser. This may cause some expressions that work now to fail upon upgrade. You can just change the argument name, use ( and ) around the whole expression to get rid of the continuation characters, etc. to get your code quickly working again. You'll get an exception if this happens suggesting one of these two approaches if your code is affected.

What's Changed

• Spelling update and flake8 control by @gordonwatts in #112
• Use builtin Python tokenizer to find lambdas by @gordonwatts in #114

Full Changelog: 3.1.2...3.2

Lambda Parsing Upgrade

Moving to a new tokenizer (the builtin one!!) for finding where lambda' expressions are!

What's Changed

• Spelling update and flake8 control by @gordonwatts in #112

Full Changelog: 3.1.2...3.2b1

Lambda Parsing Bug Fix

Found a black inspired reformat that tickled a bug in the func_adl parser. Updated.

What's Changed

• Infinite loop if this lambda is parsed in Jupyter by @gordonwatts in #111

Full Changelog: 3.1.1...3.1.2

Lambda Parsing Upgrade

Correctly parse a lambda formatting that black will often impose:

    my_obj().do_it(
        lambda e: e.Jets("AntiKt4EMTopoJets").do_it(
            lambda j: j.Jets("AntiKt4EMTopoJets").do_it(
                lambda j1: j1.pt() / 1000.0
            )
        )
    )

Lambda Parsing Upgrade

This point release is focused on correctly parsing lambda's - increasing the range of styles of code we can correctly detect inside a Select, SelectMany and Where statement.

For example, the following two statements now work (and didn't properly work before):

    my_obj().Select(lambda x: x
                   + 1
                   + 2
                   + 20
                   )

and

    my_obj().do_it(lambda event: event + 1
                   ).do_it(lambda event: event)

Since this is using heuristics, likely there are cases we've missed. Please do not hesitate to submit a bug report (or PR).

What's Changed

• Support multi-line lambda functions which are valid before complete by @gordonwatts in #103
• Test to make sure multi-line lambda with funny breaks works by @gordonwatts in #105
• Add as_awkward and as_pandas, etc by @gordonwatts in #106
• Python 3.11 support by @gordonwatts in #107

Full Changelog: 3.0...3.1