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!
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.
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.
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.
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 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.
- With Dynamic Linking, it's the job of the system admin (typically a distribution maintainer) to ensure that the system-provided library and application are compatible — and add patches if needed;
- With Static Linking, the package developer takes control of the whole experience; they deem more important to deliver a working application to the end user than to ensure compatibility with an OS.
This makes sense for isolated applications, e.g. video games.
For a system's core stack (coretools, X11, etc.), the end user expects to receive security fixes in a timely manner. From the distribution's point of view, it seems simpler to have a single library to patch, recompile and push, than to have the maintainer of each package statically linked against said library release an updated version...
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!