[Python-Dev] Heads up: `make` in Doc now creates a venv

2021-08-04 Thread Petr Viktorin 

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 directory, not Doc) will build docs for you:

 sphinx-build Doc Doc/build/

The issue that added this is: https://bugs.python.org/issue44756
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/MGPNI7OSA7UXNOTVDVW2I2GUMXV25FRS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Heads up: `make` in Doc now creates a venv

2021-08-04 Thread Miro Hrončok 

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 following command (in the CPython 
directory, not Doc) will build docs for you:

  sphinx-build Doc Doc/build/

The issue that added this is: https://bugs.python.org/issue44756


For what it's worth, I think that:

 - changes in the workflow should be discussed first
 - changes like this should not happen this late in the release cycle
 - a documented/supported way to build the docs with make without venv should
   exist (currently, running `mkdir venv` before `make ...` kinda works)

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ZY5IFBLAKXHXRJNFLTSQYCBEOXMQ2XNE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Heads up: `make` in Doc now creates a venv

2021-08-04 Thread Pablo Galindo Salgado 
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 republish the tarball without the venv.

Pablo

On Wed, 4 Aug 2021 at 10:53, Miro Hrončok  wrote:

> 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 following command (in the
> CPython
> > directory, not Doc) will build docs for you:
> >   sphinx-build Doc Doc/build/
> >
> > The issue that added this is: https://bugs.python.org/issue44756
>
> For what it's worth, I think that:
>
>   - changes in the workflow should be discussed first
>   - changes like this should not happen this late in the release cycle
>   - a documented/supported way to build the docs with make without venv
> should
> exist (currently, running `mkdir venv` before `make ...` kinda works)
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/ZY5IFBLAKXHXRJNFLTSQYCBEOXMQ2XNE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/KMJOS5K2674ADFJTGJSE27WECPY3MBFH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.10.0rc1 is available

2021-08-04 Thread Pablo Galindo Salgado 
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
releases.

If you had any problem building docs with the previous release artifacts
for 3.10.0rc1, please try again.

Regards from cloudy London,

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower

On Tue, 3 Aug 2021 at 17:31, Pablo Galindo Salgado 
wrote:

> Python 3.10.0 is almost ready. This release, 3.10.0rc1, is the
> penultimate release preview. You can get it here:
>
> https://www.python.org/downloads/release/python-3100rc1/
>
>
> *This is the first release candidate of Python 3.10*
> This release, **3.10.0rc1**, is the penultimate release preview.  Entering
> the release candidate phase, only reviewed code changes which are
> clear bug fixes are allowed between this release candidate and the final
> release. The second candidate and the last planned release preview is
> currently planned for 2021-09-06 while the official release is planned for
> 2021-10-04.
>
> There will be no ABI changes from this point forward in the 3.10 series
> and the goal is that there will be as few code changes as possible.
>
> *Call to action*
> Core developers: all eyes on the docs now
>
>- Are all your changes properly documented?
>- Did you notice other changes you know of to have insufficient
>documentation?
>
> Community members
>
> We strongly encourage maintainers of third-party Python projects to
> prepare their projects for 3.10 compatibilities during this phase. As
> always, report any issues to the Python bug tracker
> .
> Please keep in mind that this is a preview release and its use is **not**
> recommended for production environments.
>
> *And now for something completely different*
>
> In theoretical physics, quantum chromodynamics (QCD) is the theory of the
> strong interaction between quarks and gluons, the fundamental particles
> that make up composite hadrons such as the proton, neutron, and pion. The
> QCD analog of electric charge is a property called color. Gluons are the
> force carrier of the theory, just as photons are for the electromagnetic
> force in quantum electrodynamics. There are three kinds of charge in QCD
> (as opposed to one in quantum electrodynamics or QED) that are usually
> referred to as "color charge" by loose analogy to the three kinds of color
> (red, green and blue) perceived by humans. Other than this nomenclature,
> the quantum parameter "color" is completely unrelated to the everyday,
> familiar phenomenon of color.
>
>
> *We hope you enjoy those new releases!*
> Thanks to all of the many volunteers who help make Python Development and
> these releases possible! Please consider supporting our efforts by
> volunteering yourself or through organization contributions to the Python
> Software Foundation.
>
> Regards from cloudy London,
>
> Your friendly release team,
> Pablo Galindo @pablogsal
> Ned Deily @nad
> Steve Dower @steve.dower
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/DJTNV6AO4HJDLKL5FY3MQECC5BVFVZSB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 467 feedback from the Steering Council

2021-08-04 Thread Victor Stinner 
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 bytes.getbyte(). I cannot find "int"
in the name of other bytes methods.

>some_var = bytearray(bchr(65))
> vs
>some_var = bytearray.from_int(65)

bytearray(bchr(65)) sounds less efficient.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/KBVVBJL2PHI55Y26Z4FMSCJPER242LFA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Windows buildbots may be broken

2021-08-04 Thread Victor Stinner 
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
an incremental build.

https://github.com/python/buildmaster-config/commit/f83c0a321dac8bb7d0df2e3098e7d36862f0b18a
https://github.com/python/buildmaster-config/pull/255
---

See https://docs.buildbot.net/latest/manual/configuration/steps/source_git.html
documentation.

I made this change to fix the following issue:
https://mail.python.org/archives/list/[email protected]/thread/Z27NUT4OY7IGUNQXCTMO4GGSR7RWVB4J/

setup.py failed with: "RuntimeError: subprocess not supported for
isolated subinterpreters". It seems like aarch64 Fedora Rawhide 3.x
doesn't use a fresh build, but incremental build. I get such error
when I use incremental build.

Victor

On Fri, Jul 30, 2021 at 5:53 PM Jason R. Coombs  wrote:
>
> Jeremy informed me that due to a race condition on a test file and the 
> CPython repo configuration for newline conversion, build bots on Windows may 
> now be failing.
>
> If you run such a buildbot, please consider running this command on your repo 
> to bypass the issue:
>
> git rm -r :/ ; git checkout HEAD -- :/
>
>
> You may want to consider adding this command after every update to the repo 
> to avoid the stale state.
>
>
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/EZPAFN3BSVDBZC7CRAJEFIQVM6JOSGU5/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/7UDB2PHSBI66WDTVRA6D5NMJLO734ZNZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)

2021-08-04 Thread Victor Stinner 
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 accepted in Python 3.6.

As soon as LOAD_GLOBAL and LOAD_ATTR optimizations are not lost, I'm
perfectly fine with removing the dictionary version. As it was said in
other messages, there is now a per-key version which can be used
instead, if I understand correctly.

Victor

On Thu, Jul 29, 2021 at 12:41 PM Mark Shannon  wrote:
>
> Hi everyone,
>
> I would like to repeal PEP 509. We don't really have a process for
> repealing a PEP. Presumably I would just write another PEP.
>
> Before I do so, I would like to know if anyone thinks we should keep
> PEP 509.
>
> The dictionary version number is currently unused in CPython and just
> wastes memory. I am not claiming that we will never need it, just that
> we shouldn't be required to have it. It should be an internal
> implementation detail that we can add or remove depending on requirements.
>
> Thoughts?
>
> Cheers,
> Mark.
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/GV4CW3T7SUTJOYSCP6IJMV4AHDNNZIPV/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/J6GMNVLSLBBZB766ZNTJO3FU3ORJ75NN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python3 OSF/1 support?

2021-08-04 Thread Victor Stinner 
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 longer produced and OSF/1 doesn't seem to
be maintained anymore, I'm not excited by maintaining new changes in
Python for this outdated platform. Even if the newly added code is
seen as "dead code" (unused), it has a cost. Future readers will have
to dig into the mailing list archive and the Internet to understand
why it's there, if it's still correct, if it should be removed or not,
etc.

As Brett wrote, I would prefer to first clarify the rules (PEP 11) to
support or not a new platform in Python.

> Admitted, I haven't figured out what is happening with the posixsubprocess 
> module.

Spawning processes is not stricly required, but it's highly
recommended to use Python. Many stdlib modules use subprocess directly
or indirectly. It's ok if your platform doesn't support it or now.

Anyway, it's cool to support Python on old platforms, happy hacking!

Victor

On Wed, Jul 14, 2021 at 6:34 AM Jay K  wrote:
>
> Hi. I have an Alpha/OSF machine up and running.
> It is little slow, but it works ok.
>
> I would like to run Python3 on it.
>
> I have it "compiling and working". It was easy enough so far.
>   https://github.com/python/cpython/pull/27063
>
> Admitted, I haven't figured out what is happening with the posixsubprocess 
> module.
>
> Yes? No? Maybe?
>
> I can possibly provide ongoing "support" (I don't expect it will be much) and 
> a buildbot (if really required),
> if I can get it working a bit more, if this is approved, etc. I haven't 
> looked yet at what buildbot involves.
>
> Thank you,
>  - Jay
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/NK6ER7SIFQDEZ2W7OANZNGNFPO3FV7HW/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/TEJGMQLHULIYYJKXU2BYRMSCH5ZWCPT5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 467 feedback from the Steering Council

2021-08-04 Thread Barry Warsaw 
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 namespace as small
> as possible.

The Steering Council is also pretty adamantly against adding a new bchr() 
built-in.

> bytes.byte() name is similar to bytes.getbyte(). I cannot find "int"
> in the name of other bytes methods.

.byte() seems fine to me too.  I’m not a fan of smushedwords but .fromint() 
seemed better than .fromord().

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/CPZTRWIWLRKTBHQS6UPY63BEZCV3FDZZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Devguide document on PEG parser

2021-08-04 Thread Pablo Galindo Salgado 
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 for everyone that wants to deal with the
grammar or the parser.

Hope that you find it useful :)

P.S. Thanks to everyone that helped with the review!

Regards from cloudy London,
Pablo Galindo Salgado
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/WNPUUAPUZEQ6UY3DEJE2JAYT2FZZXWE3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 467 feedback from the Steering Council

2021-08-04 Thread Christopher Barker 
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 integer value be called bchr()? (short for "byte character",
presumably)

There are fewer and fewer people having to translate their code (or their
brains) from py2 to py3.

bytes.fromint() is just fine.

-CHB

BTW -- I really love the rest of the PEP -- it's been too awkward to work
with bytes for too long.



On Wed, Aug 4, 2021 at 9:43 AM Barry Warsaw  wrote:

> 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 namespace as small
> > as possible.
>
> The Steering Council is also pretty adamantly against adding a new bchr()
> built-in.
>
> > bytes.byte() name is similar to bytes.getbyte(). I cannot find "int"
> > in the name of other bytes methods.
>
> .byte() seems fine to me too.  I’m not a fan of smushedwords but
> .fromint() seemed better than .fromord().
>
> -Barry
>
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/CPZTRWIWLRKTBHQS6UPY63BEZCV3FDZZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/XPJUILIFBTYMAEQYJVDBQMC3GJI6XX6M/
Code of Conduct: http://python.org/psf/codeofconduct/