I thought HRT was a Cpp shop? Is Python used in their main business applications, or more for quants / data scientists?
every quant shop has QR and QT people that can barely write passable python let alone cpp - then the QD people have to integrate that stuff with prod cpp pipelines.
HRT's Python fork: Leveraging PEP 690 for faster imports
41–50 of 103 posts
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#42While I see the usefulness of lazy imports, it always seemed a bit backward to me for the importer to ask for lazy import, especially if you make it an import keyword rather than a Python flag. Instead I'd expect the modules to declare (and maybe enforce) that they don't have side effects, that way you know they can be lazily imported, and it opens the door for more optimizations, like declaring the module immutable.…
Exactly this. There must be zero side effects at module import time, not just for load times, but because the order of such effects is 1) undefined, 2) heavily dependent on a import protocol implementation, and 3) poses safety and security nightmares that Python devs don't seem to care much about until bad things happen at the most inconvenient time possible.
> Of course that doesn't solve the overhead of finding the modules, but that could be optimized without lazy import, for example by having a way to pre-compute the module locations at install time.
1) opt for https://docs.python.org/3/reference/import.html#replacing-th...
2) pre-compute everything in CI by using a solution from (1) and doing universal toplevel import of the entire Python monorepo (safe, given no side effects).
3) This step can be used to scan all toplevel definitions too, to gather extra code meta useful for various dynamic dispatch at runtime without complex lookups. See for example: https://docs.pylonsproject.org/projects/venusian/en/latest/i...
3) put the result of (2) and (3) as a machine-readable dump, read by (1) as the alternative optimised loading branch.
4) deploy (3) together with your program.
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#43Earlier quoted context omitted.
>Python devs at HRT really know their stuff. Its a finance firm - i.e scam firm. "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could". Scammers are not tech people. And its pretty from their post. > In Python, imports occur at runtime. For each imported name, the interpreter must find, load, and evaluate the con…
> "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could". How they make $8B/y underperforming VOO? Reference: https://www.businessinsider.com/hudson-river-trading-hrt-8-b...
In case you are unaware - very single trading firm makes money on fees, not by outperforming the market. This goes for firms like Vanguard too.
Just think about it for a little bit - if you could reliably outperform the market by any % with an algorithm why even start a company? Just take out loans, invest, make money, repeat and become rich. No expenses to manage a company.
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#44Earlier quoted context omitted.
> "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could". How they make $8B/y underperforming VOO? Reference: https://www.businessinsider.com/hudson-river-trading-hrt-8-b...
Man from all these responses, so many people are unaware of the finance world, lol. Or just bots posting for HRT In case you are unaware - very single trading firm makes money on fees, not by outperforming the market. This goes for firms like Vanguard too. Just think about it for a little bit - if you could reliably outperform the market by any % with an algorithm why even start a company? Just take out loans, invest…
I really want to know what you think this company does, precisely
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#45Earlier quoted context omitted.
> "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could". How they make $8B/y underperforming VOO? Reference: https://www.businessinsider.com/hudson-river-trading-hrt-8-b...
Man from all these responses, so many people are unaware of the finance world, lol. Or just bots posting for HRT In case you are unaware - very single trading firm makes money on fees, not by outperforming the market. This goes for firms like Vanguard too. Just think about it for a little bit - if you could reliably outperform the market by any % with an algorithm why even start a company? Just take out loans, invest…
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#46Earlier quoted context omitted.
>Python devs at HRT really know their stuff. Its a finance firm - i.e scam firm. "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could". Scammers are not tech people. And its pretty from their post. > In Python, imports occur at runtime. For each imported name, the interpreter must find, load, and evaluate the con…
[flagged]
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#47Earlier quoted context omitted.
>Python devs at HRT really know their stuff. Its a finance firm - i.e scam firm. "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could". Scammers are not tech people. And its pretty from their post. > In Python, imports occur at runtime. For each imported name, the interpreter must find, load, and evaluate the con…
Runtime imports are a maintenance nightmare and can quickly fragment a codebase. Static analysis of imports is so desirable that it is almost always worth the initialization performance hit. Tradeoffs.
I agree, which is why you should design your modules correctly and import only the stuff you need.
I was pointing out that lazy imports vs runtime imports in functions are basically the same and lead to the same issues.
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#48Earlier quoted context omitted.
Man from all these responses, so many people are unaware of the finance world, lol. Or just bots posting for HRT In case you are unaware - very single trading firm makes money on fees, not by outperforming the market. This goes for firms like Vanguard too. Just think about it for a little bit - if you could reliably outperform the market by any % with an algorithm why even start a company? Just take out loans, invest…
> Because every single trading firm makes money on fees I really want to know what you think this company does, precisely
If a company has customers, and those customers buy a product, the company charges a price for that product.
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#49Earlier quoted context omitted.
> Because every single trading firm makes money on fees I really want to know what you think this company does, precisely
I can't tell if people don't understand how financial firms work or are you just being sarcastic. If a company has customers, and those customers buy a product, the company charges a price for that product.
They don't...
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#50Earlier quoted context omitted.
Runtime imports are a maintenance nightmare and can quickly fragment a codebase. Static analysis of imports is so desirable that it is almost always worth the initialization performance hit. Tradeoffs.
>Runtime imports are a maintenance nightmare and can quickly fragment a codebase I agree, which is why you should design your modules correctly and import only the stuff you need. I was pointing out that lazy imports vs runtime imports in functions are basically the same and lead to the same issues.
How do you achieve this without making gazillions of modules, where each module has just a few stuff?
Are you saying just use local import everywhere?