[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

[Petr Viktorin]

On 28. 05. 21 6:55, Tim Peters wrote:

[Pablo]

Tim, check this out:


import re, gc
x = re.compile("x")
gc.get_referents(x.__class__)[-1]




Cool! So presumably this constructs a cycle involving a pattern object:

import re
p = re.compile("ab*c")
import _sre
_sre.WOWZA = p

Indeed, under the current main branch:


import gc
gc.get_referents(type(p))[-1].WOWZA is p

True

Then again, type objects are in cycles regardless:


type(p).__mro__[0] is type(p)

True

dict.__mro__[0] is dict

True

int.__mro__[0] is int

True

Etc.

I suppose I could ask why heap types were fiddled to point to their
module objects too - but that's really got nothing to do with getting
the release done, so I won't :-)


Not all heap types need to point to their module objects. Just the ones 
that need the module's state -- for example, if their method needs to 
raise a module-specific exception.

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/AVPNW4ADGV6VLOFPKYHDC7OTZFQLATGK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: status of smtpd

[Petr Viktorin]

On 23. 06. 21 15:21, Irit Katriel via python-committers wrote:



On Wed, Jun 23, 2021 at 1:58 PM Joannah Nanjekye 
mailto:nanjekyejoan...@gmail.com>> wrote:


Am not against removing dead batteries but Am still very skeptical
and disturbed about how the
decision to remove modules is made.i.e what goes and what remains?

For example, in the discussion section of PEP 594 , individuals kept
asking for some modules to remain and IIUC,
it's in the decision of the PEP to keep those modules on those
grounds that some people requested for those modules to remain.

For example, I now wonder how Andrew is different from those people?


asynchat and asyncore are deprecated since 3.6. Doesn't this mean that 
the decision to remove them was already taken?


"Deprecation" was much more vague in 3.6 than it is now.
I don't think the current process from [PEP-387] was followed with these 
modules -- I don't see any deprecation warnings being raised.



[PEP-387]: 
https://www.python.org/dev/peps/pep-0387/#making-incompatible-changes

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/DCW2OQM6IFR5GSOP5QEPQBXFVFML42RB/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Python 3.11.0a4 is blocked

[Petr Viktorin]

https://bugs.python.org/issue46006 


This one is due to a regression made in bpo-40521 "Make free lists and 
unicode caches per-interpreter".
It affects 3.10 as well, and hes broken a number of third-party 
libraries there (e.g. mod_wsgi and kodi).
It's not easy to revert: I think only one person understands the changes 
made for bpo-40521 (and the particular wider strategy behind it). I feel 
powerless to help here.


As Mark Dickinson said in bpo-40521, "It's feeling as though the normal 
Python development process is being bypassed here."
IMO, there should be a PEP for wide-reaching changes like bpo-40521, and 
the PEP should be actually *approved* before such changes are made.


In bpo-46006 itself, there are two proposed PRs, each corresponding to a 
slightly different vision of how subinterpreters should be isolated. I 
don't know which is right. If we had a PEP, I could read it and decide, 
but I can't -- the people driving this effort have different ideas of 
the big picture.


Victor, as the author of the breaking change, could you revert it?
Or do you have a different in mind (assuming your PR for bpo-46006 has 
an unacceptable performance impact, as Mark Shannon pointed out)?

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/4GDBGIJOPDVWHBRWSX2KNUPP2YDVVZTD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: list of core-devs, triagers, etc.

[Petr Viktorin]

On Mon, Feb 14, 2022 at 4:16 AM Ethan Furman  wrote:
>
> Greetings!
>
> Is there a list somewhere of the core developers and triagers?
>
> I'm looking to prune the core-mentorship subscriber list as I'm confident 
> 90%+ are folks that wanted help learning
> Python, not folks wanting help to develop Python itself.  Towards that end I 
> want to unsubscribe anyone who has not been
> active in the last six months, excepting core-devs and triagers.

Why do you want to do that?
If people feel the list is not for them, they can unsubscribe themselves.
Unsubscrbing inactive people seems unlikely to reduce unwanted
messages from those that subscribed to the wrong list -- don't those
tend to be sent just after someone subscribes?
Is there another reason?
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/ASD2HO5JMY3OPFQFO3SW57TNZWYI6RQB/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: list of core-devs, triagers, etc.

[Petr Viktorin]

On 17. 02. 22 20:05, Ethan Furman wrote:

On 2/17/22 10:47 AM, Senthil Kumaran wrote:

 > If the utility value of the list has faded way, archiving the list, 
and pointing the subgroup to

 > other active places seems like better idea to me.

The list is useful, just for a very small set of people -- namely, those 
that want to contribute but need a friendly, supportive, and 
non-judgemental area to get started.  At this point, we don't have any 
other place like that.


I still don't quite see how inactive subscribers make the list worse. 
Could you elaborate on that?



We should probably give the list a shout-out on the other lists once a 
quarter or so to encourage active membership.


--
~Ethan~
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/FN2RLEILITLM6E3TFEX6ELCLYZMNA5YV/ 


Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/OGL7SQVLK7XX6SC53CYNW5THJ3EHCGJO/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Petr Viktorin]

On 11. 03. 22 0:35, Brett Cannon wrote:
I brought this up on python-dev at 
https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ 
 
, and the feedback seemed supportive. As such, I am bringing a draft of 
what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders 
for people to help me fill in to see how this will look overall.


For any platform(s) you support, please reply with any relevant details 
that should be added to the relevant tables below. Once I have these 
details I will loop back with the proposed update to PEP 11 and make 
sure everyone is still on board with the proposal.


=
Tiers
=

Tier 1
==

- `Test suite failures 
>`__ 
block releases.
- Changes which would break the ``main`` branch are not allowed to be 
merged;

   any breakage may be reverted immediately.
- All core developers are responsible to keep these platforms working.


What does this mean?
I can not merge a change if it doesn't pass macOS CI, but I don't have a 
macOS system, so I can't really diagnose and fix macOS bugs.



- Promotion of this tier requires consensus/SC approval.

=== =
Target Triple       Notes
=== =
i686-windows-msvc


What's the supported version of Windows?


x86_64-windows-msvc
x86_64-apple-darwin macOS 11
x86_64-linux-gnu    glibc 2.31 |ubuntu-20_01|_


Would it be better to say “whatever GitHub Actions has” in the long-term 
docs, and put the specific version in the docs rather than in the PEP?




[...]> All other platforms

===

- Only code which either supports a higher-tier platform or is a general 
improvement may be checked in.


I'm worried about going from this to tier 3.
How do you get to a platform's buildbot being stable if you can't merge 
code for it?


___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/XY2HMEEM46R5QI6C3A3NL4ICQ7LVYC2W/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Petr Viktorin]

On 11. 03. 22 19:30, Brett Cannon wrote:



On Fri, Mar 11, 2022 at 1:26 AM Petr Viktorin <mailto:encu...@gmail.com>> wrote:


On 11. 03. 22 0:35, Brett Cannon wrote:
 > I brought this up on python-dev at
 >

https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/

<https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/>

 >

<https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/

<https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/>>

 > , and the feedback seemed supportive. As such, I am bringing a
draft of
 > what I'm thinking will go into PEP 11 with a bunch of `XXX`
placeholders
 > for people to help me fill in to see how this will look overall.
 >
 > For any platform(s) you support, please reply with any relevant
details
 > that should be added to the relevant tables below. Once I have these
 > details I will loop back with the proposed update to PEP 11 and make
 > sure everyone is still on board with the proposal.
 >
 > =
 > Tiers
 > =
 >
 > Tier 1
 > ==
 >
 > - `Test suite failures
 >

<https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted

<https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>

 >

<https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted

<https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>>>`__

 > block releases.
 > - Changes which would break the ``main`` branch are not allowed
to be
 > merged;
 >    any breakage may be reverted immediately.
 > - All core developers are responsible to keep these platforms
working.

What does this mean?
I can not merge a change if it doesn't pass macOS CI, but I don't
have a
macOS system, so I can't really diagnose and fix macOS bugs.


Do you merge PRs today that don't pass CI on macOS?


 > - Promotion of this tier requires consensus/SC approval.
 >
 > === =
 > Target Triple       Notes
 > === =
 > i686-windows-msvc

What's the supported version of Windows?

 > x86_64-windows-msvc
 > x86_64-apple-darwin macOS 11
 > x86_64-linux-gnu    glibc 2.31 |ubuntu-20_01|_

Would it be better to say “whatever GitHub Actions has” in the
long-term
docs, and put the specific version in the docs rather than in the PEP?


Perhaps; I was tempted to do that, but Christian requested the triples.


The triples are fine, but the "glibc 2.31" is too specific. Especially 
in the Tier 2 list.







[...]> All other platforms
 > ===
 >
 > - Only code which either supports a higher-tier platform or is a
general
 > improvement may be checked in.

I'm worried about going from this to tier 3.
How do you get to a platform's buildbot being stable if you can't merge
code for it?



You could develop code outside of the CPython repo until the platform is 
ready to be supported.


Would you propose to drop the Buildbot requirement for tier 3 or 
introduce a tier 4?


I think the other thread in the conversation makes this moot, but I'd 
drop the Buildbot requirement for tier 3. It's enough that there's a 
core dev interested in bringing a platform like WASM or Android up to speed.


___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YJKH5BNRXCSWPKLBEAFDBHZU4SACNNE4/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Petr Viktorin]

On 25. 03. 22 11:43, Victor Stinner wrote:

You wrote that you want at least 2 core devs responsible for each tier
1 platform. I didn't understand if this requirement is also for Tier
2.

Who are these core devs? Is there a list?


The list will be in the PEP. Add yourself at 
https://github.com/python/peps/pull/2442 as a review suggestion.

That PR also has the current text of the proposal.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/LW3IDZMHWNOMKCGADU5KBA3WNR5FRCHT/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Petr Viktorin]

On Fri, Mar 25, 2022 at 8:32 PM Brett Cannon  wrote:
>
> Thanks to Petr, and Victor, the platforms that are still looking for a total 
> of two maintainers over at https://github.com/python/peps/pull/2442/files are:
>
> arch64-apple-darwin clang
> aarch64-linux-gnu glibc, clang (Victor is already listed)
> aarch64-windows-msvc
> powerpcle-linux-gnu glibc, clang
> s390x-linux-gnu glibc, gcc
> s390x-linux-gnu glibc, clang

FWIW, I'm not listing myself for s390x. While fixing Python for
mainframes is part of my job at Red Hat, I don't have immediate access
to such machines and can't promise timely fixes.
When I (or Victor or someone else) comes up with a fix, we'll of
course want to contribute it to CPython, but I think Tier 3 is fine
for that. Usually these fixes *make Python conform better to the C
standard*, e.g. avoiding endianness/bit-pattern assumptions. I assume
such fixes should be welcome regardless of platform. But, if we don't
have a big-endian arch in the 2 tiers, endian-specific code does
“cause a maintenance burden or obstruct general improvements”. Same
for e.g. code that relies on “common” implementation details in malloc
or something like that.

Should the PEP explicitly say that fixing deviations from standard C
is welcome, even if they don't manifest on the tiered arches?
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/MNQ6GMM2Z7DPCKYHNTBZB4F2DU64WM6R/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1

[Petr Viktorin]

On 08. 04. 22 9:51, Inada Naoki wrote:

Thank you, Victor.

I had considered dropping (a) from the PEP. But I keep them because:

* I rushed to write PEP, before 3.11 beta.
* In the "Backward compatibility" section in the PEP, I want to
mention `locale.getencoding()` and `encoding="locale"`
* But they are not fixed in the main branch yet. So I need to include
what needs to be fixed in 3.11 in the PEP.

But for now, we are close to merge `locale.getencoding()`.
And I am afraid merging it before the PEP accepted even though it is
documented in the PEP...

Now I think the best way is:

* Withdraw the PEP submission temporarily.
* Implement `locale.getencoding()` and fix `encoding="locale"` in the
main branch.
* Remove them from the PEP.
* Resubmit the PEP.


That shouldn't be necessary. If you're making these changes anyway, you 
can just add a note to the SC request that the 3.11 changes are being 
merged now. (I'll just do that myself now!)
Then update the PEP to say "This API was added in Python 3.11" instead 
of "will be added".



The SC did ask people to not submit PEPs that still have planned 
changes. I think that's because discussing the old version is 
essentially a waste of time, and if the change comes as a surprise it's 
frustrating.
But if the SC knows about the planned changes, it can adapt -- either 
delay its discussions, or just decide to discuss it anyway.


“Don't make *surprise* changes” is the main point, as I see it.

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/2SYJFQUAQH7BU2LOJG6UKRMWZZZELPXG/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Automerge bot deployed

[Petr Viktorin]

On Wed, Sep 12, 2018, 23:30 Victor Stinner  wrote:

> Today I created a PR with a description containing "type.__format__()". To
> display it properly, I chose to edit the description and write
> "type.\_\_format\_\_()". I guess that the bot will merge a description like
> that unchanged, right? So we should also be careful of description using
> Markdown syntax.
>

Use `type.__format__`, with backticks, for code. That looks OK in plain
text.
Or edit before merging :)


> Victor
>
> Le mer. 12 sept. 2018 à 18:52, Mariatta Wijaya 
> a écrit :
>
>> Update to the automerge bot:
>>
>> It will not merge unless there is "CLA signed" label, and no
>> "DO-NOT-MERGE" label.
>>
>> Again, please edit the PR title and description before adding the `🤖
>> automerge` label.
>> The PR title and description will be used as the squashed commit message.
>>
>> Mariattaᐧ
>> ᐧ
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Python 4.0 or Python 3.10?

[Petr Viktorin]

On 9/25/18 9:30 PM, Yury Selivanov wrote:

What's the current plan for what version of Python we release after 3.9?

The reason I'm asking this is because I frequently need to refer to
*that version* of Python in the documentation, especially when I'm
deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
implying that 4.0 will be released right after 3.9.

I've heard multiple opinions on this subject. One of them is that we
should release 4.0 when we have a major new change, like removal of
the GIL or introduction of a JIT compiler.  On the other hand, we have
no estimate when we have such a change. We also don't want Python 4.0
to be backwards incompatible with Python 3.0 (at least not at the
scale of 2 vs 3).  So to me, it seems logical that we simply release
Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
drastically different from 3.0 and from 2.7.  It sounds better. :)

Finally, I'm not sure we need a new governance in place to make this
decision or maybe we can make it now. That's why I'm posting this to
python-committers to see if core devs already have a consensus on
this.

Yury


As someone who's still fighting every day to make people switch from 
"python2" (or "python") to "python3", I'd be very, very happy if I 
didn't have to start telling them to use "python4" instead now. Or 
explaining that the way to launch Python 4 is "python3".

Same story with Python 2020 instead of Python 4.

(And unfortunately, a "py" launcher is not an answer here -- it won't be 
very useful unless it is everywhere, and that will take years in the 
best case.)


I'd much, much rather explain that `sys.version[2]` is not correct, and 
solve the "python310" < "python39" problem.

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

[Petr Viktorin]

On 12/23/18 2:08 AM, Nick Coghlan wrote:
On Thu., 20 Dec. 2018, 3:46 am Brett Cannon <mailto:br...@python.org> wrote:



On Wed, 19 Dec 2018 at 06:01, Victor Stinner mailto:vstin...@redhat.com>> wrote:


For example, supporting a version means to
have a working CI (Travis CI, AppVeyor, VSTS, buildbots). I would
suggest to only support a very few platforms for the LTS. I
propose to
restrict to Linux. It doesn't mean to break other platforms on
purpose, just to restrict CI to the bare minimum. If Microsoft is
interested, we can also support Windows as well.


But that doesn't help someone like me who isn't working on Linux, so
it's still work to support just Linux compared to Windows or macOS.
Plus supporting just Linux in CI and such is still not free either.


RHEL 7 is based on Python 2.7.5 which has been released in 2013 (5
years ago) and there are 150 patches on top of it: it means that
around 30 patches are added per year. I would suggest to have a very
strict policy on which changes are backported into 3.6: only the
most
critical bugfixes, but all security fixes obviously.

If we extend Python 3.6 lifetime, do we need a new release manager
when the initial lifetime (usually 5 years) ends? Benjamin Peterson
accepted to be the Python 2.7 release manager for 10 years
(instead of
5 years initially). We could ask Ned Deily about Python 3.6 LTS
:-) We
would need a group of people reviewing individual 3.6 pull
requests to
decide to pick them or not. I would volunteer to review these
PRs and
merge them.

The idea isn't new, Nick Coghlan proposed a "ELPython" last year:

https://github.com/elpython/elpython-meta


Was that when


If the unfinished question there is "... when Nick was still working for 
Red Hat?", then yeah, it was.


I knew RHEL 8 was coming with Py3.6 as the system Python, and wanted a 
way to avoid the anchoring effects that Alex Gaynor and I talked about a 
few years back in 
https://alexgaynor.net/2015/mar/30/red-hat-open-source-community/ and 
https://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html


I still think ELPython is a good idea, as it should solve a bunch of the 
problems that Alex raised on the community side, while also helping 
commercial distributors (including Red Hat) provide the explicitly in 
demand commercial service of compatible *feature* backports to LTS 
releases (go look at the system Python 2.6 install in RHEL 6, for 
example - it includes a number of 2.7 features, such as 
collections.OrderedDict).


Red Hat's provided that service for years for their Linux kernels, and 
it's one of the capabilities that their customers most value.


The community benefit of allowing such backports to take place in a 
cross-vendor collaborative project is that it would allow popular 
backwards compatible features to be adopted by library authors more 
quickly, as they'd have the option of switching to relying on the EL 
variant of a release for a feature they wanted, rather than having to 
drop that release stream entirely.


However, I also deliberately designed the proposal to make it clear it 
was only going to happen as a *paid* activity, with a bright line for 
contributions where the only reason for a volunteer to take their change 
across that line would be because they wanted the new behaviour in the 
EL version themselves.


Thus the notion of a separate GitHub org, source-only releases, 
different runtime identification metadata, etc.


Actually pursuing that project would still need a PEP to spell out the 
relationship between CPython and the ELPython derivative, though.


Pursuing the project would also need credible commitments from 
redistributors to actually adopt the variant - the technical design in 
the README is explicitly constructed so it would work as a drop-in 
replacement for the RHEL 8 system Python, but at the time I left RH, 
Petr Viktorin and I didn't have agreement from management yet that that 
was a path the company wanted to go down (and it was only recently, when 
the RHEL 8 public beta dropped, that we gained the ability to discuss 
the commercial motivation for the idea with the upstream community).


(with my RH hat on; despite my personal address:)

If anyone wants to collaborate, I'd be happy go push the EL Python idea 
further. But, so far, we haven't found other organizations that would 
want to join the effort. (BTW, I think Victor asking CPython devs 
themselves was a very long shot, but at least it confirmed that the 
answer is "no".)


So it looks like we'll keep the status quo – Red Hat's patches to 3.6 
will be available in Red Hat & CentOS repos.

[python-committers] Re: Please avoid non-bugfix changes during the beta phase

[Petr Viktorin]

On 2020-07-07 21:35, Barry Warsaw wrote:

It’s true that as releases get closer to final, more people will start 
exercising them.  However, you really don’t have to wait.  I maintain 
“official” Linux (Ubuntu) Docker images that contain all the latest releases 
(including alphas and betas), and the git head of the development branch at the 
time of the image builds.

https://gitlab.com/python-devs/ci-images/-/tree/master

I keep these up-to-date on every new maintenance release, alpha, beta, rc, and 
final, for Python 2.7, and 3.4 through 3.10.  I use this image in my own open 
source code’s CI, and you can too!  Unfortunately, we can’t do the same with 
Windows, but I’ve cracked the nut to get pretty good coverage for Windows 
releases too.  Here for example is flufl.lock’s .gitlab-ci.yml file:

https://gitlab.com/warsaw/flufl.lock/-/blob/master/.gitlab-ci.yml

I need to extend that to 3.9 pre-releases, via python.org downloads rather than 
nuget.

So, it’s entirely possible to test your stuff against pre-release versions, and 
I highly encourage it.


Many of these also get into Fedora (all alphas/betas/RCs go into Rawhide 
rather fast; 3.X.0 alphas/betas/RCs go into stable Fedora updates).
And we do our best to build almost 4000 packages with the 3.X.0 
alpha/beta/RCs, with many of the builds running test suites.


Unfortunately, "test your stuff" tends to only find regressions. New 
features aren't too useful if you need to support stable Python 
releases, so they're not tested very much with the betas/RCs.

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/3JMRLPUHXKEQVYETL6NZEX6SHAQSEYPG/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Publish better than md5sums of Python builds?

[Petr Viktorin]

On 16. 03. 21 21:16, Gregory P. Smith wrote:
On Tue, Mar 16, 2021 at 9:42 AM Christian Heimes > wrote:


On 16/03/2021 16.54, Julien Palard wrote:
 > Le 2021-03-16 à 15:52, Christian Heimes a écrit :
 >> could you please explain your use case? Which problem are you
trying to
 >> solve? How would a sha256 checksum help you solve that problem?
 >
 > No, I'm just forwarding the surprise of a user seen on a random
social
 > network (I'm monitoring the python hashtag on mastodon those days).

The MD5 fingerprint is really just a checksum to detect download issues.
Any checksum would do the trick, even CRC-32. We could (and should)
replace the MD5 fingerprint with SHA-256 or SHA-512 [1].

In our case SHA-256 checksums don't provide any real benefit over MD5.


The benefit of listing the sha256 for files is that it prevents this 
question coming up again and again because md5 is old and rightfully on 
the "never use" list for many people. Even if there are situations where 
it is fine as an effective improvement over a CRC.


Security and data integrity is provided by TLS / HTTPS and optionally by
GPG signatures. The Python source code and checksums are provided by the
same server. If an attacker is able to modify the tar ball, then it's
likely they can replace the checksum information, too.


People do look at https://python.org/  to get the 
official checksums of the downloads at a much different time than the 
tarball they have lying around was downloaded.  Hosting them serves as 
an easy way to check the integrity of what they already got at some 
previous time.


Exactly. I've offered a Flash drive with Python at install parties with 
slow wi-fi before. Allowing people to easily check against 
https://python.org would have been nice to have.



Lets not let perfect be the enemy of the good here.

What do other things hosting downloads do?  I see some that list only 
sha256.  I see others that list both.  I don't really care which we do 
so long as we include something standard not red-flagged as broken due 
to collisions.

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/JLR7DFRD7ETMLALJEYK2DRRAJPVUCGW5/
Code of Conduct: https://www.python.org/psf/codeofconduct/