[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python

[Nick Coghlan]

On Fri., 1 Nov. 2019, 4:15 am Mats Wichmann,  wrote:

> Just slightly off topic (sorry Brett), but I have past experience with
> the effort to try and sync the release cycle of something significant
> with that of major distros - and it's just too hard. (What are major
> "the major distros" anyway?  the enterprise ones are on a completely
> different cycle, and some have gone to rolling releases where there's
> really nothing to sync to). By all means, if it hurts nothing to go for
> a sync now, to take advantage of some synergies, great, but don't try
> enshrine it in a PEP as a requirement going forward, there will only be
> lots of pain as things start to skew. And they will.


This was actually one of the benefits of PEP 602: while Ubuntu LTS and
Debian being offset means that every Python version is likely to find its
way into one long lived Linux distro or another, the 12 month cadence means
that when cycles don't line up well enough for immediate adoption, even the
previous version should still be less than 18 months old (e.g. if Debian 11
were to ship Python 3.8 early in 2021 instead of 3.9).

The balance between alpha/beta/rc is definitely negotiable though, and I
expect we'll see iteration on that aspect over the first few years.

Cheers,
Nick.


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

[Python-Dev] Re: Implementation of PEP-0604

[Nick Coghlan]

On Thu., 31 Oct. 2019, 11:45 pm Philippe Prados, 
wrote:

> To implement a full version of PEP604
> , I analyze the typing module,
> started with _GenericAlias.
> 1) I must rewrite :
>
>- def _type_check(arg, msg, is_argument=True)
>- def _type_repr(obj)
>- def _collect_type_vars(types)
>- def _subs_tvars(tp, tvars, subs)
>- def _check_generic(cls, parameters)
>- def _remove_dups_flatten(parameters)
>- def _tp_cache(func)
>- class _Final
>- class _Immutable
>- class _SpecialForm(_Final, _Immutable, _root=True)
>- class ForwardRef(_Final, _root=True)
>- class TypeVar(_Final, _Immutable, _root=True)
>- def _is_dunder(attr)
>- class _GenericAlias(_Final, _root=True)
>- class Generic
>- class _TypingEmpty
>- class _TypingEllipsis
>- def _get_protocol_attrs(cls)
>- def _is_callable_members_only(cls)
>- def _allow_reckless_class_cheks()
>- class _ProtocolMeta(ABCMeta)
>- class Protocol(Generic, metaclass=_ProtocolMeta)
>
> 2) The function _tp_cache use functools.lru_cache()
> def _tp_cache(func):
> cached = functools.lru_cache()(func)
> it's not reasonable to move the lru_cache() in the core
>

However, there may be C level caching machinery that can be used instead
(we have a lot of low level caches, lru_cache is just the flexible option
that's available to Python code).

3) The method TypeVar.__init__() use:
> def_mod = sys._getframe(1).f_globals['__name__']  # for pickling
>
> 4) The method def _allow_reckless_class_cheks() use:
> return sys._getframe(3).f_globals['__name__'] in ['abc', 'functools']
>

_getframe is already a Python level wrapper around an underlying C API. A C
implementation of this code would skip the wrapper and call the underlying
API directly.


> 5) The method Protocol.__init_subclass___proto_hook() use:
> if (isinstance(annotations, collections.abc.Mapping)
> it's not reasonable to move the Mapping type in the core
>

I believe the collections ABCs are already available to builtin code
through the frozen "_collections_abc" module.

If I'm misremembering, and that module is just imported early rather than
being frozen as precompiled bytecode, then freezing it as part of the
interpreter build process (rather than rewriting it in C) would be the way
to handle this (and a proof of concept could likely get away with importing
it just before it is needed).


> It's not enough to move the typing classes, I must move
> functools.lru_cache() and dependencies, collections.abs.Mapping and
> dependencies, and track the frame level.
>
> *It's too big for me.*
>
>
It's certainly not an easy project to tackle.

For some of the specific points you raise though, you wouldn't translate
the existing Python code directly to C.

Instead, you would want to look for existing builtin code that does
something similar (e.g. by searching for references to "_collections_abc"),
and then use C level code that gives the same external behavior, even
though it works differently internally.

Cheers,
Nick.


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

[Python-Dev] Re: Do not fallback to __trunc__ when convert to int

[Guido van Rossum]

It seems a good idea to add __int__ to Fraction, but if you stop falling
back to __trunc__, won't that cause backwards compatibility issues? I'd say
looking for __trunc__ if the alternative is failing isn't so bad.

On Thu, Oct 31, 2019 at 3:43 AM Serhiy Storchaka 
wrote:

> Currently __trunc__ is used for two purposes:
>
> * In math.trunc() which just calls __trunc__.
> * In int() and PyNumber_Long() as a fallback if neither __int__ nor
> __index__ are implemented.
>
> Unlike to __int__ and __index__ there is not a slot corresponding to
> __trunc__. So using it is slower than using __int__ or __index__. float
> and Decimal implement __int__ and __trunc__ by the same code. Only
> Fraction implements __trunc__ but not __int__.
>
> I propose to deprecate the falling back to __trunc__ for converting to
> int and remove it in future. Fraction should implement __int__.
>
> We cannot use __trunc__ for setting the nb_int slot because it can
> return non-int.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/6ZMQE4YTFZWN7H366YJG5QFNP6TFPMFZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python

[Mats Wichmann]

On 10/30/19 4:20 PM, Barry Warsaw wrote:

On Oct 30, 2019, at 14:31, Łukasz Langa  wrote:


Yes. This allows for synchronizing the schedule of Python release management 
with Fedora. They've been historically very helpful in early finding 
regressions not only in core Python but also in third-party libraries, helping 
moving the community forward. It seems like a bargain to make a slight 
adjustment of our schedule to help Fedora help us make 3.9 and beyond better 
releases.


It would be really interesting for the major distros to work together, 
coordinating their archive rebuilds with the new/beta releases.  E.g. Ubuntu 
might be ahead of Fedora, or vice versa, for any particular new Python release. 
 Rebuilding the whole archive with the new version as default always uncovered 
interesting issues.  It seems like we have a great untapped resource to find 
good signals as to bugs, breakages, regressions, and other problems during the 
Python beta process.  How can that be leveraged better?


Just slightly off topic (sorry Brett), but I have past experience with 
the effort to try and sync the release cycle of something significant 
with that of major distros - and it's just too hard. (What are major 
"the major distros" anyway?  the enterprise ones are on a completely 
different cycle, and some have gone to rolling releases where there's 
really nothing to sync to). By all means, if it hurts nothing to go for 
a sync now, to take advantage of some synergies, great, but don't try 
enshrine it in a PEP as a requirement going forward, there will only be 
lots of pain as things start to skew. And they will.

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

[Python-Dev] Re: EnHackathon 2019 - seeking core dev support

[Lewis Gaul]

Hi Tal, Brandt, Chris, Kyle,

Thank you all for offering to support us in one way or another. Just to
update with our plans:

- We have 12 contributors who have agreed to spend on average 4 days in
November contributing.
- The blog will be up tomorrow at http://enhackathon.github.io/ - already
two blog posts waiting to go!
- Our first day of EnHackathon contribution will be on Monday 4th November
(sorry for short notice) when we will try to form a more concrete plan for
the remaining days.
- We will spend 2 days contributing the following week (perhaps Tues-Weds
12th-13th November).
- We will spend the last 2 days the following week.

I'm happy to set up an EnHackathon channel - is IRC or Zulip preferred in
general?

Please let me know if there are specific dates that are better than others
for you - we can be flexible with the last 4 days, and all the support we
can get is greatly appreciated!

Thanks,
Lewis

On Mon, 28 Oct 2019 at 20:55, Tal Einat  wrote:

> Hi Lewis,
>
> As I mentioned in our earlier conversation, I'd be happy to help!
>
> I'm in the UTC+2 timezone so hopefully I should be available for live
> support for most of your working hours. I suggest setting up a dedicated
> channel for online communication, e.g. an IRC channel or Zulip stream (with
> Zulip I'll also be available via my phone.)
>
> Please update ASAP regarding the exact dates so I can let you know when
> I'll be available and try to increase my availability during that period.
>
> I am unfortunately barely familiar with most of the interest areas you've
> mentioned, with unittest being the exception. I'll still be able to assist,
> but perhaps not as well as an expert on these would be. I suggest
> contacting the experts on the relevant library modules directly regarding
> this, mostly to ask what they think would be most helpful and whether they
> have any preferences or requests, but also regarding their availability to
> help before, during and after.
>
> - Tal Einat
>
> P.S. Apologies for the delayed reply, I'm working back through my email
> backlog after a vacation.
>
> On Sun, Oct 20, 2019 at 3:04 PM Lewis Gaul  wrote:
>
>> Hi all,
>>
>> In early November this year I'll be leading the first ever Python
>> 'EnHackathon' at the Ensoft Cisco office - we anticipate having ~10
>> first-time contributors, all with experience writing C and/or Python (and
>> training in both). We each have up to 5 days (per year) to contribute, with
>> my intention being to focus on contributing to CPython. We will be blogging
>> about our experience (probably using GitHub pages) - I'll send out the URL
>> when it's been set up.
>>
>> Having spoken to people about this at PyCon UK this year and emailed on
>> the core-mentorship mailing list, I'm posting here looking for any core
>> devs who would be happy to provide us with some guidance. I'm wary of PR
>> reviews being a blocker, and not wanting my co-contributors to feel
>> disheartened by issues they're working on not reaching a resolution.
>>
>> We're open to working on almost any area of CPython, although particular
>> areas of interest/familiarity might be: CPython core, re, unittest,
>> subprocess, asyncio, ctypes, typing. There would be scope for us to work in
>> small teams to work on more substantial issues if that is seen as a useful
>> way to contribute, otherwise we can start with some of the easier issues on
>> bpo.
>>
>> Would anyone here be willing to offer some support to help us reach our
>> full potential? Please don't hesitate to contact me if you're interested in
>> any way, or if you have any advice.
>>
>> If this year is a success there's a high probability we would look to do
>> a similar thing in future years (with the experience from this year already
>> in the bag)!
>>
>> Thanks,
>> Lewis
>>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IFSE5U6CB3EXPVYRJOJJIKUD6R5QL2LP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Implementation of PEP-0604

[Philippe Prados]

To implement a full version of PEP604
, I analyze the typing module,
started with _GenericAlias.
1) I must rewrite :

   - def _type_check(arg, msg, is_argument=True)
   - def _type_repr(obj)
   - def _collect_type_vars(types)
   - def _subs_tvars(tp, tvars, subs)
   - def _check_generic(cls, parameters)
   - def _remove_dups_flatten(parameters)
   - def _tp_cache(func)
   - class _Final
   - class _Immutable
   - class _SpecialForm(_Final, _Immutable, _root=True)
   - class ForwardRef(_Final, _root=True)
   - class TypeVar(_Final, _Immutable, _root=True)
   - def _is_dunder(attr)
   - class _GenericAlias(_Final, _root=True)
   - class Generic
   - class _TypingEmpty
   - class _TypingEllipsis
   - def _get_protocol_attrs(cls)
   - def _is_callable_members_only(cls)
   - def _allow_reckless_class_cheks()
   - class _ProtocolMeta(ABCMeta)
   - class Protocol(Generic, metaclass=_ProtocolMeta)

2) The function _tp_cache use functools.lru_cache()
def _tp_cache(func):
cached = functools.lru_cache()(func)
it's not reasonable to move the lru_cache() in the core

3) The method TypeVar.__init__() use:
def_mod = sys._getframe(1).f_globals['__name__']  # for pickling

4) The method def _allow_reckless_class_cheks() use:
return sys._getframe(3).f_globals['__name__'] in ['abc', 'functools']

5) The method Protocol.__init_subclass___proto_hook() use:
if (isinstance(annotations, collections.abc.Mapping)
it's not reasonable to move the Mapping type in the core

It's not enough to move the typing classes, I must move
functools.lru_cache() and dependencies, collections.abs.Mapping and
dependencies, and track the frame level.

*It's too big for me.*

May be, the approach with only PEP 563 is enough.
from __future__ import annotations
a:int|str=3

This new syntax is only usable in annotations. Without runtime evaluation
and without modifying issubclass() and isinstance() may be acceptable. Only
the mypy (and others tools like this) must be updated.


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

[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python

[Matthias Klose]

On 30.10.19 22:22, Barry Warsaw wrote:

On Oct 30, 2019, at 12:50, Matthias Klose  wrote:


On 30.10.19 20:26, Brett Cannon wrote:

This was discussed on https://discuss.python.org


I appreciate that you are informing the python-dev ML. However this discussion 
was never announced on the ML.  I assume this is a kind of thing that makes the 
ML obsolete and forces everyone into discourse.


Doko, as to the substance of PEP 602, does the annual release cadence in 
October cause problems for Ubuntu?


It's around four months before the Ubuntu feature freeze [1], and six before the 
release in April (which every two years usually becomes a long term support 
release). Having a window of four months for the adoption, with new third party 
releases for 3.8/3.9 trickling in, might be a bit short.


The adoption of 3.8 during this time frame might be more dominated by the 
removal of Python2 packages [2] (3300 sources affected, 1900 still to do).  And 
having fun with third party packages without having 2.7 and 3.8 support in the 
same release, with the Py2 removal having a top to bottom order for 
dependencies, and the 3.8 addition a bottom to top order.


We will see in 2021, how the distros will do with that work load and 3.9.

An August or September release might help, but I think it's more the shortened 
release cycle which has a bigger effect.


Matthias

[1] https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule
[2] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2removal;users=debian-pyt...@lists.debian.org

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

[Python-Dev] Re: [WARNING] Some users who downloaded the Python 3.5.8 .xz tarball got the wrong version

[Michael]

On 31/10/2019 00:17, Larry Hastings wrote:
>
>
> Due to awkward CDN caching, some users who downloaded the source code
> tarballs of Python 3.5.8 got a preliminary version instead of the
> final version.  As best as we can tell, this only affects the .xz
> release; there are no known instances of users downloading an
> incorrect version of the .tgz file.
>
> If you downloaded "Python-3.5.8.tar.xz" during the first twelve hours
> of its release, you might be affected.  It's easy to determine this
> for yourself.  The file size (15,382,140 bytes) and MD5 checksum
> (4464517ed6044bca4fc78ea9ed086c36) published on the release page have
> always matched the correct version.  Also, the GPG signature file will
> only report a "Good signature" for the correct .xz file (using "gpg
> --verify").
>
> What's the difference between the two?  The only difference is that
> the final version also merges a fix for Python issue tracker #38243:
>
> https://bugs.python.org/issue38243
>
> The fix adds a call to "html.escape" at a judicious spot, line 896 in
> Lib/xmlrpc/server.py.  The only other changes are one new test, to
> ensure this new code is working, and an entry in the NEWS file.  You
> can see the complete list of changes here:
>
> https://github.com/python/cpython/pull/16516/files
>
> What should you do?  It's up to you.
>
>   * If you and your users aren't using the XMLRPC library built in to
> Python, you don't need to worry about which version of 3.5.8 you
> downloaded.
>   * If you downloaded the .tgz tarball or the Git repo, you already
> have the correct version.
>   * If you downloaded the xz file and want to make sure you have the
> fix, check the MD5 sum, and if it's wrong download a fresh copy
> (and make sure that one matches the known good MD5 sum!).
>
> To smooth over this whole sordid mess, I plan to make a 3.5.9 release
> in the next day or so.  It'll be identical to the 3.5.8 release; its
> only purpose is to ensure that all users have the same updated source
> code, including the fix for #38243.
>
>
> Sorry for the mess, everybody,
>
a) "Congratulations" on the 3.5.8 release

b) excellent solution - to up the release number!

c) Thanks!!

>
> //arry/
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/OYNQS2BZYABXACBRHBHV4RCEPQU5R6EP/
> Code of Conduct: http://python.org/psf/codeofconduct/




signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LKXNJQLSNAOONGVAGUXMTBEF77QXEY65/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Do not fallback to __trunc__ when convert to int

[Serhiy Storchaka]

Currently __trunc__ is used for two purposes:

* In math.trunc() which just calls __trunc__.
* In int() and PyNumber_Long() as a fallback if neither __int__ nor 
__index__ are implemented.


Unlike to __int__ and __index__ there is not a slot corresponding to 
__trunc__. So using it is slower than using __int__ or __index__. float 
and Decimal implement __int__ and __trunc__ by the same code. Only 
Fraction implements __trunc__ but not __int__.


I propose to deprecate the falling back to __trunc__ for converting to 
int and remove it in future. Fraction should implement __int__.


We cannot use __trunc__ for setting the nb_int slot because it can 
return non-int.

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

[Python-Dev] Re: small improvement idea for the CSV module

[Inada Naoki]

On Wed, Oct 30, 2019 at 11:55 PM Oz Tiram  wrote:
>
> Hi Steve,
>
> Thanks for your reply. While dataclass provide a cleaner API than DictRow 
> (you can access `row.id` instead of `row["id"]`).
> However, dataclass still use the built in `__dict__` instead of  `__slots__`.
>
> This means that the users reading large files won't see the suggested memory 
> improvements.
>

FWIW, there is memory improvements thanks to the Key-sharing dictionary.
See PEP 412 [1].
I have an idea about utilizing Key-sharing dictionary in DictReader, but I have
not implemented it yet.

[1]: https://www.python.org/dev/peps/pep-0412/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/R4XMTCZKTJG32HJYTIZO7XJQMJBJMWQ3/
Code of Conduct: http://python.org/psf/codeofconduct/