Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
pansa2
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
49 ms
·
901.
▲
by
pansa2
6y ago
> I am in love with every part of 11ty except the documentation. Interesting. One of the reasons I chose Eleventy over Hugo was because I felt its documentation was much better.
902.
▲
by
pansa2
6y ago
Yes, except dispatch happens at runtime, not compile time. It takes into account the dynamic type of each argument, not just their static types.
903.
▲
by
pansa2
6y ago
> Would I need to write a PEP? Only if you want to change the language itself, AFAIK. Optimisations that don’t change behaviour shouldn’t require a PEP.
904.
▲
by
pansa2
6y ago
See also the PEPs: https://www.python.org/dev/peps/pep-0634/#abstract
905.
▲
by
pansa2
6y ago
PEP 622 has been superseded by 634, 635 and 636.
906.
▲
by
pansa2
6y ago
It’s interesting that the old parser had the same problem. Although it did the parsing using an LL(1) algorithm, it never actually verified that the grammar was LL(1) before doing so. [ https://discuss.python.org/t/shoul
907.
▲
by
pansa2
6y ago
> Shows you why your code is slow! Because you wrote it in Python. Seriously, Python is probably the slowest mainstream language of all. If you’re building something where performance matters, you should be using a different language.
908.
▲
by
pansa2
6y ago
Sounds like the thought process was along the lines of: “LL(1) makes it too hard to add complex new features to the language, we must change to something else; PEG is something else; therefore we must change to PEG”.
909.
▲
by
pansa2
6y ago
> Mainly making it easier to do syntax extensions... Yes, AFAICT the main reason for the parser change is to enable the pattern matching feature [0] that’s likely coming in 3.10. [0] https://www.python.org/dev/peps&#
910.
▲
by
pansa2
6y ago
Apparently they didn’t even consider it: “We did not seriously consider alternative ways to implement the new parser, but here's a brief discussion of LALR(1). [...] Other variants of LR were not considered, nor was LL (e.g. ANTLR).” [
911.
▲
by
pansa2
6y ago
Yes, read the comments or the source code. Or the documentation. Or `help(square)`. Or just try `square(Matrix([1, 2], [3, 4]))` in the REPL. How would you use type annotations to show that `square` accepts a matrix (as well as an int, floa
912.
▲
by
pansa2
6y ago
How can I pass whatever I want into that function at runtime , while still satisfying the type checker?
913.
▲
by
pansa2
6y ago
> There is a numbers.Number for that That won't help if I want to square a matrix, or a polynomial. > typing_extensions.Protocol helps support the general duck typing "any object that has method x" Even if there's
914.
▲
by
pansa2
6y ago
> squaring an imaginary number results in a real number However, in general, squaring a complex number results in another complex number.
915.
▲
by
pansa2
6y ago
> Interface typing > duck typing. Duck typing has been fundamental to Python for a long time. Do you think we're seeing a shift away from it? In the future, do you think "Pythonic" code will include significant use of e
916.
▲
by
pansa2
6y ago
> You can pass whatever you want into that function Not really. Doing so won't cause an error at runtime, but it will produce an error when you run the type checker.
917.
▲
by
pansa2
6y ago
Python's LL(1) parser isn't particularly fast. It's not a recursive-descent parser custom-made for Python's grammar, but a data-driven general-purpose design. What's more, it's not driven by a simple LL(1) tabl
918.
▲
by
pansa2
6y ago
This example demonstrates why I don't understand Python's type annotations. They seem to be incompatible with the language's core principle of duck typing. Why would you constrain a function like `square` to only accept `int`
919.
▲
by
pansa2
6y ago
> being able to write large swathes of code without actually running it and being 100% confident that it's all _valid_ (not bug-free of course) just takes a huge load off my mind. I've heard similar things before, e.g. "st
920.
▲
Python Enhancement Proposal 638 – Syntactic Macros
(python.org)
5 points
by
pansa2
6y ago
|
3 comments
921.
▲
by
pansa2
6y ago
> escaped opening parens as identifiers for string templates Do you mean the use of “\(variable)” for string interpolation? What’s wrong with that?
922.
▲
by
pansa2
6y ago
> They could of course just limit the run time It seems as though this would be more robust than limiting the number of bytecode instructions. I wonder if that’s true and if so, why it’s not more commonly recommended.
923.
▲
by
pansa2
6y ago
Yes. `string.find` is implemented in C. Invoking it (no matter how complex its arguments) requires just a few bytecode instructions.
924.
▲
by
pansa2
6y ago
> Investigation of a "typed Lua" for compilation is something on the roadmap. That is the approach that the main Lua project is taking to compete with LuaJIT on performance. I haven't heard anything about an official &qu
925.
▲
by
pansa2
6y ago
> Scripts should not be able to crash the system, run indefinitely, or corrupt other parts of the system. To ensure that, Lunatik uses the Lua VM facilities for sandboxing the scripts so that they run in a safe execution environment [..
926.
▲
by
pansa2
6y ago
> Luckily, one can make the grammar LL(1)-parser-friendly by rewriting all the left recursions in the grammar rules as right recursions. The problem with this is that it changes all the left-associative operators to be right-associative.
927.
▲
by
pansa2
6y ago
Yes. There’s a reason both companies kept their prices secret until so close to release, and we heard nothing until a leak forced Microsoft’s hand.
928.
▲
by
pansa2
6y ago
As long as you never assign to it, `nill == nil`!
929.
▲
by
pansa2
6y ago
Sorry, I meant that Python 3 code can’t use dependencies that are written in Python 2. Therefore a library couldn’t upgrade to Python 3 until all its dependencies had upgraded.
930.
▲
by
pansa2
6y ago
This is the worst part. 12 years to change the language’s Unicode model and, after all that, the new model turns out to be a bad design because in the meantime, everyone else has standardised on UTF-8.
More ›