Implications of Rewriting a Browser Component in Rust

Re:Implications of Rewriting a Browser Component in Rust by FreeFull on Thursday February 28, 2019 @12:54PM (#19273345)

Python will actually give you an error for `print foo` as soon as it parses the file. But there definitely are other scenarios where you'll only get the error in the middle of execution (such as passing the wrong type of thing as an argument to a function)

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by wyldfire on Thursday February 28, 2019 @01:33PM (#19273748)

Agreed but Python lazy-loads & parses files as packages are imported. By convention these are all at file scope and at the top of the files, so it's often confined to an initialization phase. But...sometimes developers use clever fallback behavior by catching ImportError.

So the scenario described is possible to escape simple tests, I suppose.

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by marmaduke on Thursday February 28, 2019 @01:38PM (#19273806)

Doesn’t the print raise a SyntaxError not ImportError?

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by wyldfire on Thursday February 28, 2019 @03:34PM (#19274911)

Yes, sorry if that was confusing -- perhaps I shouldn't have brought up ImportError. The point was that uncovering SyntaxError could possibly be as challenging as other feature tests.

    try:
        import collections
    except ImportError:
        # fallback impl of collections:
        import something_that_uses_print_statement

[ Parent | on HN ]