I see in the PEP:
"the bchr builtin is to recreate the ord/chr/unichr trio from Python 2
under a different naming scheme"
Why recreate that trio? Shouldn't we be moving away from the
bytes-is-a-string concept here?
A byte is not a character -- why would the function that creates a byte
from an
Hi,
After some effort, I just finished a new extensive document in the devguide
regarding how
to use the new PEG parser and the PEG grammar:
https://devguide.python.org/parser/
The document contains descriptions, backgrounds, references, guides, and
tips. Ideally,
this will make it a bit easier
On Aug 4, 2021, at 07:31, Victor Stinner wrote:
>
> On Tue, Aug 3, 2021 at 7:54 PM Ethan Furman wrote:
>> I would rather keep `bchr` and lose the `.fromint()` methods.
>
> I would prefer to only have a bytes.byte(65) method, no bchr()
> built-in function. I would prefer to keep builtins
Hi,
I suggest you to start by forking the python/cpython repository and
keep your changes in a branch. You can share it on a website, maybe
with a tarball including your patches. If it gets enough popularity,
maybe we can consider later to include these changes.
Since Alpha hardware is not
Hi,
I wrote the PEP 509 as part of my abandonned "FAT Python" project
which was a ahead-of-time optimizer using runtime guards to deoptimize
code. I planed to abandon this PEP as well, but the dictionary version
was used by LOAD_GLOBAL opcode cache which made the version useful and
so the PEP was
Hi Jason,
One month ago, I changed the Buildbot configuration:
---
Use Git "fresh" method
Git "clean" method keeps most files created by a previous build. Use
Git "fresh" method instead to ignores .gitignore rules and so remove
all generated files (like ".o" files): run a fresh build rather than
On Tue, Aug 3, 2021 at 7:54 PM Ethan Furman wrote:
> I would rather keep `bchr` and lose the `.fromint()` methods.
I would prefer to only have a bytes.byte(65) method, no bchr()
built-in function. I would prefer to keep builtins namespace as small
as possible.
bytes.byte() name is similar to
Hi,
Unfortunately, due to a problem that I was not aware of caused by
https://bugs.python.org/issue44756, the
release artifacts for Linux contained a "venv" folder in the "Docs"
directory.
I have uploaded a new version of the artifacts that fixed this problem and
I have corrected this for future
One of the most important things is that I was **not informed** about how
this affects the release
process and we ended up with a venv packaged in the tarball, unfortunately.
I agree that these changes should be notified to the release manager,
precisely to avoid these situations.
I am trying to
On 04. 08. 21 11:28, Petr Viktorin wrote:
Hi,
A recent change "make html" in the Doc directory create a venv if one wasn't
there before. If you don't want to download sphinx and other dependencies from
PyPI, you'll need to adjust your workflow.
If you already have all the dependencies, the
Hi,
A recent change "make html" in the Doc directory create a venv if one
wasn't there before. If you don't want to download sphinx and other
dependencies from PyPI, you'll need to adjust your workflow.
If you already have all the dependencies, the following command (in the
CPython
11 matches
Mail list logo
