Now, I'm left to wonder if this could have been used to better handle the Python 2-to-3 transition, e.g '# coding: six.python2' would adjust Python2 code to be valid Python3, or '# coding: six.python3' would adjust Python3 code to run under Python2 - e.g adding/removing the b"..." or u"..." prefixes!
It could help, but the parts it would help with are the easy parts. The challenges of py2 to py3 were the runtime behavior change: a Unicode and regular string containing ASCII were the same string in py2, as in you could use them as keys of a dict and they'd key the same entry. In py3 a bytes and str of the same ASCII would identify different entries in the same dict.
Some more nasty changes: various built ins like .keys() and .values() return lists in py2 but iterators in py3. Code gets very verbose if you use the six utilities or other workarounds to translate code safely - most times those are called they are used once, but every once in a while they are used twice.
Imo if you have such a tool that can rewrite at import time you should just commit the transformed code, and clean it up incrementally. The hard parts are the behavior changes that can cross long distances like the str v bytes behaving so different than py2 Unicode v str
Indeed — when you look at this from other engineering disciplines: having your train track built for "no downtime, ever" means that you have a third track available, with its dedicated platforms, so that you can work on one track while traffic goes on.
This might make sense for your inner city loop, with trains passing by every 30 seconds (and it's gonna help when one train inevitably breaks down).
However, it's a totally unreasonable cost for a station deep in the country where trains only stop 4 times a day.
A maintenance window doesn't necessarily have to mean downtime either, it could just mean time you can make changes where people are on hand to fix it if things go wrong.
To extend your analogy, it might be a terrible idea to start doing maintenance on a single line track that sees high usage in a holiday season just before those holidays where everyone wants to get away or get home as do your staff. So you might implement what is usually called a change freeze.
On the other hand you might have a different time where demand is low. Shutting down the line if it comes to that will annoy some people but not as many. So you plan your maintenance then and have people ready in case things go wrong.
Adopting metaphorical analogs of all the impediments of real engineers does not make us real engineers.
Software is cheap to produce and quick to change. Building a "third track" on the fly, as needed, is exactly the kind of thing we can do that actual engineers can't. They probably wish they had the ability to do things like that.
An interesting impact of this discussion is, for me: within my team at work, we're likely to forbid any use of Github co-pilot for our codebase, unless we can get a formal guarantee from Github that the generated code is actually valid for us to use.
By the way, code generated by Github co-pilot is likely incompatible with Microsoft's Contribution License Agreement [1]: "You represent that each of Your Submission is entirely Your original work".
This means that, for most open-source projects, code generated by Github co-pilot is, right now, NOT acceptable in the project.
I'd say that it depends on the license; for StackOverflow, it's CC-BY-SA 4.0 [1]. For sample code, that would depend on the license of the original documentation.
My point is: when I'm copying code from a source with an explicit license, I know whether I'm allowed to copy it. If I pick code from co-pilot, I have no idea (until tested by law in my jurisdiction) whether said code is public domain, AGPL, proprietary, infringing on some company's copyright.
> forbid any use of Github co-pilot for our codebase,
I have recommended as such to the CTO and other senior engineers at the startup I work at, pending some clear legal guidance about the specific licensing.
My casual read of Copilot suggests that certain outputs would be clear and visible derivatives of GPL code, which would be _very bad_ in court- probably? Some other company can have fun in court and make case law. We have stuff to build.
I'm not sure why I'm getting down voted?
"We'll forbid the use of copilot in our code base"
How????
How the fuck would anyone know how the code was written?
The only minor issue being that the materials used in fabricating the ASIC are likely more expensive (money and energy-wise) than those for a conventional heater!
I gather that this project targets internal constants.
Let's say you need to share the list of error codes between your backend API and your frontend: instead of having to maintain two lists, just share the constants between the two codebases...
The issue is kinda more complex: cryptography is also a hard dependency of pip, the official Python package installer.
And CPython itself seem to support PPC64 and s390x — which are Tier 2 targets for rust.
Hence, pip now depends on software that is not tested on some platforms officially supported by Python…
From what I understand, the issue with the previous behaviour is that, although it enabled you to bypass the issue of that specific package, it could also install conflicting versions you didn't know about.
For your specific use case, wouldn't it be better to have a flag `--override-constraints=` where you provide explicitly overridden constraints only for the packages you're interested in?
I think it's closer to "Celery is a great tool to get started, but as your product matures you'll end up falling back to a simple AMQP consumer stack":
- By default, task IDs are just pickled Python objects - if you want to change the location of a function, it might break;
- The whole process appears to be reloaded for each task - any heavy loading ends up being performed on each call;
- I couldn't find any "ops" documentation: how does it interact with RabbitMQ? How are deferred tasks implemented? What happens if a node crashes?
Although the API is nice, the product itself seems ill-suited for actual reliable, production use — at that point, it's sometimes easier to just deploy your own minimal API using the serialization format you've chosen to adopt (JSON, Protobuf, ASN.1, … ;)
I’ve found celery to be extremely useful and reliable at handling > 1MM daily async tasks with non deterministic latencies. The programming interface melds beautifully with Flask.
Celery has been pretty reliable when i have used it in the past. Admittedly I have newer done anything particularly fancy with it, just running some background tasks and sending out some emails.
I sometimes receive patches where the contributor just tried to shoehorn the feature they wanted in the codebase; they didn't understand the project architecture, just found a way to get it working.
And I may receive a bug report where the user bisected the history to find which commit introduced the bug, and provide me with all inputs to confirm the issue and reproduce it myself.
Even if the latter contribution doesn't fix the bug, it will end up being merged: they found an issue, dug to find it; but they don't how to fix it while keeping in line with the library's internals.
In other words: the more a contributor tries to understand your goals and design as a project maintainer, and respects them, the more valuable their contribution — be it bug reports, documentation improvements, blog posts, or patches.
It seems we agree eg, a paid dev's feature request is not comparable to the paid dev contributing the feature itself via discussion with the maintainer.
Nor is it comparable to the maintainer stopping what they are doing to sit there and provide the feature as if their time was worth less than that of the paid dev who wants to consume it.
Regardless of whether the contributor is paid, I think that feature requests and bug reports can be compared to feature implementations.
If the feature request includes, for example, technical architecture and product design analysis, and illustrates that it has considered various other options, it could be highly valuable.
A bug report could have involved significant debugging to identify approximate causes, affected versions, and potentially-related commits that introduced/regressed the bug.
All of the above applies to documentation and support commentary too. There is a spectrum with any contribution from 'minimal' to 'thorough', and there's not necessarily a causal link between high-value contributions and paid work.
A quick fix is a great way to describe a bug for the person that understands the system.
On many projects the mantainers ask way to much of the submitter in following some guidelines. I feel they think they should not "steal" the submit from the submitter or something becouse fixing stuff for them would equal the work of commenting it.
Now, I'm left to wonder if this could have been used to better handle the Python 2-to-3 transition, e.g '# coding: six.python2' would adjust Python2 code to be valid Python3, or '# coding: six.python3' would adjust Python3 code to run under Python2 - e.g adding/removing the b"..." or u"..." prefixes!