[Python-Dev] [RELEASE] Python 3.8.1, 3.7.6, 3.6.10, and 3.9.0a2 are now available!

[Łukasz Langa]

from locale import seasons_greetings
seasons_greetings()

On behalf of the entire Python development community, and the currently serving 
Python release team in particular, I'm pleased to announce the unprecedented 
combined release of no less than four versions of Python. Let's dig in!


Python 3.8.1

Python 3.8.1 is the first maintenance release of Python 3.8.

The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. You can find Python 3.8.1 here:

https://www.python.org/downloads/release/python-381/ 


See the “What’s New in Python 3.8 
” document for more information 
about features included in the 3.8 series. Detailed information about all 
changes made in 3.8.1 can be found in its change log 
.

Maintenance releases for the 3.8 series will continue at regular bi-monthly 
intervals, with 3.8.2 planned for February 2020.



Python 3.7.6

Python 3.7.6, the next bugfix release of Python 3.7, is also available. You can 
find the release files, a link to the change log, and more information here:

https://www.python.org/downloads/release/python-376/ 




Python 3.9.0a2

An early developer preview of Python 3.9 is also ready: 
https://www.python.org/downloads/release/python-390a2/ 


Python 3.9 is still in development. This releasee, 3.9.0a2 is the second of six 
planned alpha releases. Alpha releases are intended to make it easier to test 
the current state of new features and bug fixes and to test the release 
process. During the alpha phase, features may be added up until the start of 
the beta phase (2020-05-18) and, if necessary, may be modified or deleted up 
until the release candidate phase (2020-08-10). Please keep in mind that this 
is a preview release and its use is not recommended for production environments.


Python 3.6.10

And, one more thing: Python 3.6.10, the next security fix release of Python 
3.6, is also available:

https://www.python.org/downloads/release/python-3610/ 




We hope you enjoy all those!

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.

https://www.python.org/psf/ 


Your friendly release team,
Ned Deily
Steve Dower
Łukasz Langa


signature.asc
Description: Message signed with OpenPGP
___
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/6T5GL5LN6OC5QY32Y6RV5VN335NNRHAO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should set objects maintain insertion order too?

[Tim Peters]

[Nick Coghlan ]
> Starting with "collections.OrderedSet" seems like a reasonable idea,
> though - that way "like a built-in set, but insertion order preserving" will
> have an obvious and readily available answer, and it should also
> make performance comparisons easier.

Ya, I suggested starting with collections.OrderedSet earlier, but gave up on it.

The problem is that the "use case" here isn't really a matter of
functionality, but of consistency:  "it would be nice if", like dicts
enjoy now, the iteration order of sets was defined in an
implementation-independent way.  That itch isn't scratched unless the
builtin set type defines it.
___
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/PM5ENMLR665XG32AS2FEAEUVDG3AFWV6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should set objects maintain insertion order too?

[Wes Turner]

OrderedSet implementations:

- https://github.com/methane/cpython/pull/23/files

- https://pypi.org/search/?q=orderedset
  - https://pypi.org/project/orderedset/
- https://code.activestate.com/recipes/576694/
- https://pypi.org/project/ordered-set/
- 
https://github.com/pandas-dev/pandas/blob/master/pandas/core/indexes/base.py#L172
(pandas' Index types)
- https://pypi.org/project/sortedcollections/

[Ordered] Sets and some applications:

- https://en.wikipedia.org/wiki/Set_(mathematics)
  - https://en.wikipedia.org/wiki/Set_notation
- https://en.wikipedia.org/wiki/Set-builder_notation
  - https://en.wikipedia.org/wiki/Glossary_of_set_theory
- https://en.wikipedia.org/wiki/Set_(abstract_data_type)
- Comparators
  - https://en.wikipedia.org/wiki/Total_order
  - https://en.wikipedia.org/wiki/Partially_ordered_set
- https://en.wikipedia.org/wiki/Causal_sets

On Thu, Dec 19, 2019 at 12:05 PM Tim Peters  wrote:
>
> [Nick Coghlan ]
> > Starting with "collections.OrderedSet" seems like a reasonable idea,
> > though - that way "like a built-in set, but insertion order preserving" will
> > have an obvious and readily available answer, and it should also
> > make performance comparisons easier.
>
> Ya, I suggested starting with collections.OrderedSet earlier, but gave up on 
> it.
>
> The problem is that the "use case" here isn't really a matter of
> functionality, but of consistency:  "it would be nice if", like dicts
> enjoy now, the iteration order of sets was defined in an
> implementation-independent way.  That itch isn't scratched unless the
> builtin set type defines it.
> ___
> 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/PM5ENMLR665XG32AS2FEAEUVDG3AFWV6/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
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/XPFWTEAM7QUPJMP7R7E7LG23FAC2WXYW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should set objects maintain insertion order too?

[Nick Coghlan]

On Fri., 20 Dec. 2019, 2:58 am Tim Peters,  wrote:

> [Nick Coghlan ]
> > Starting with "collections.OrderedSet" seems like a reasonable idea,
> > though - that way "like a built-in set, but insertion order preserving"
> will
> > have an obvious and readily available answer, and it should also
> > make performance comparisons easier.
>
> Ya, I suggested starting with collections.OrderedSet earlier, but gave up
> on it.


> The problem is that the "use case" here isn't really a matter of
> functionality, but of consistency:  "it would be nice if", like dicts
> enjoy now, the iteration order of sets was defined in an
> implementation-independent way.  That itch isn't scratched unless the
> builtin set type defines it.
>

I took Larry's request a slightly different way: he has a use case where he
wants order preservation (so built in sets aren't good), but combined with
low cost duplicate identification and elimination and removal of arbitrary
elements (so lists and collections.deque aren't good).

Organising a work queue that way seems common enough to me to be worthy of
a stdlib solution that doesn't force you to either separate a "job id" from
the "job" object in an ordered dict, or else use an ordered dict with
"None" values.

So while it means answering "No" to the "Should builtin sets preserve
order?" question (at least for now), adding collections.OrderedSet *would*
address that "duplicate free pending task queue" use case.

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/HO4UDEFGPA4AIXDK4M3ITZIG2XWJ6XDM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Thread argument for exc_info and public API

[Victor Stinner]

Hi,

Le mer. 18 déc. 2019 à 16:43, Julien Danjou  a écrit :
> The only way to retrieve the current exception is via sys.excinfo or
> PyErr_GetExcInfo in C. However, the issue is that they don't take a
> PyThreadState as argument, but use _PyThreadState_GET() to retrieve the
> thread state.

If we add the following function, does it solve your use case?

void
_PyErr_GetExcInfo(PyThreadState *tstate,
 PyObject **p_type, PyObject **p_value, PyObject **p_traceback)


> In order to retrieve the exception from *any* PyThreadState, the caller
> has to use _PyErr_GetTopmostException which takes a PyThreadState as
> argument — though that function is private and therefore not documented
> or usable in an external module (in theory at least).

What if this function is exported as a private function? Usually,
functions in Python header files are prefixed by PyAPI_FUNC(), but for
an unknown reason, this one is not:

_PyErr_StackItem *_PyErr_GetTopmostException(PyThreadState *tstate);

Maybe it's because the author didn't want to expose the private
_PyErr_StackItem structure?

> Should we make _PyErr_GetTopmostException public, or implement something
> different to retrieve the top most exception from a PyThreadState?

IMHO a _PyErr_GetExcInfo() function taking a tstate parameter is a
better idea than exposing the private _PyErr_StackItem structure.

Private functions *can* be used for debuggers, but we don't provide
any warranty that the function is not going to disappear. Such
functions have been moved to the internal API for example. The
internal C API *can* be used, but you have to opt-in so you know that
you get unstable APIs :-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/TLP6MWNML4PRKFFGXHCKNEUMN6UIQ4MT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should set objects maintain insertion order too?

[David Mertz]

On Thu, Dec 19, 2019 at 5:39 PM Nick Coghlan  wrote:

> I took Larry's request a slightly different way: he has a use case where
> he wants order preservation (so built in sets aren't good), but combined
> with low cost duplicate identification and elimination and removal of
> arbitrary elements (so lists and collections.deque aren't good). Organising
> a work queue that way seems common enough to me to be worthy of a stdlib
> solution that doesn't force you to either separate a "job id" from the
> "job" object in an ordered dict, or else use an ordered dict with "None"
> values.
>

It's not obvious to me that insertion order is even the most obvious or
most commonly relevant sort order.  I'm sure it is for Larry's program, but
often a work queue might want some other order.  Very often queues might
instead, for example, have a priority number assigned to them.

The widely used third-party `sortedcollections` module maintains either
"natural" order or some key order.  That could be engineered to be
insertion order fairly easily.  Admittedly, 'OrderedSet' sounds a bit
different from 'SortedSet'.

In [8]: sortedcontainers.SortedSet(['Wake Up', 'Drink Coffee', 'Make
Breakfast'])
Out[8]: SortedSet(['Drink Coffee', 'Make Breakfast', 'Wake Up'])

In [9]: sortedcontainers.SortedSet(['Wake Up', 'Drink Coffee', 'Make
Breakfast'], key=lambda s: s[-1])
Out[9]: SortedSet(['Drink Coffee', 'Wake Up', 'Make Breakfast'],
key= at 0x7f68f5985400>)

In [10]: 'Make Breakfast' in tasks
Out[10]: True

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/KKYFUXUHYIQB5Q532FV4YXDLKMRX55XY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should set objects maintain insertion order too?

[Tim Peters]

[Nick]
> I took Larry's request a slightly different way:

Sorry, I was unclear:  by "use case" I had in mind what appeared to me
to be the overwhelming thrust of the _entirety_ of this thread so far,
not Larry's original request.

> he has a use case where he wants order preservation (so built in sets aren't
> good), but combined with low cost duplicate identification and elimination and
> removal of arbitrary elements (so lists and collections.deque aren't good).

Sure.

> Organising a work queue that way seems common enough to me to be
> worthy of a stdlib solution that doesn't force you to either separate a
> "job id" from the "job" object in an ordered dict, or else use an ordered
> dict with "None" values.
>
> So while it means answering "No" to the "Should builtin sets preserve
> order?" question (at least for now), adding collections.OrderedSet *would*
> address that "duplicate free pending task queue" use case.

Only Larry can answer whether that would meet his perceived need.  My
_guess_ is that he wouldn't know OrderedSet existed, and, even if he
did, he'd use a dict with None values anyway (because it's less hassle
and does everything he wanted).

But I have to add that I don't know enough about his original use case
to be sure it wasn't "an XY problem":

https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem
"""
The XY problem is asking about your attempted solution rather than
your actual problem.

That is, you are trying to solve problem X, and you think solution Y
would work, but instead of asking about X when you run into trouble,
you ask about Y.
"""

Because I've never had a "job queue" problem where an OrderedSet would
have helped.  Can't guess what's different about Larry's problem.
___
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/TV2XVX2NKUGJJZNFKO4TSMEPVQI6Y75Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should set objects maintain insertion order too?

[Tim Peters]

[David Mertz ]
> It's not obvious to me that insertion order is even the most obvious or
> most commonly relevant sort order.  I'm sure it is for Larry's program, but
> often a work queue might want some other order.  Very often queues
> might instead, for example, have a priority number assigned to them.

Indeed, and it makes me more cautious that claims for the _usefulness_
(rather than just consistency) of an ordered set are missing an XY
problem.  The only "natural" value of insertion-order ordering for a
dynamic ordered set is that it supports FIFO queues.  Well, that's one
thing that a deque already excels at, but much more obviously,
flexibly, and space- and time- efficiently.

For dicts the motivating use cases were much more "static", like
preserving textual order of keyword argument specifications, and
avoiding gratuitous changing of order when round-tripping key-value
encodings like much of JSON.

So what problem(s) would a dynamic ordered set really be aiming at?  I
don't know.  Consistency & predictability I understand and appreciate,
but little beyond that.  Even FIFO ordering is somewhat a PITA, since
`next(iter(set))` is an overly elaborate way to need to spell "get the
first" if a FIFO queue _is_ a prime dynamic use case.  And there's no
efficient way at all to access the other end (although I suppose
set.pop() would - like dict.popitem() - change to give a _destructive_
way to get at "the other end").
___
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/J52ATOHFXNBSEJV6QQZBFXSC2TAHOWGW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should set objects maintain insertion order too?

[Nick Coghlan]

On Fri., 20 Dec. 2019, 1:56 pm Tim Peters,  wrote:

> So what problem(s) would a dynamic ordered set really be aiming at?  I
> don't know.  Consistency & predictability I understand and appreciate,
> but little beyond that.  Even FIFO ordering is somewhat a PITA, since
> `next(iter(set))` is an overly elaborate way to need to spell "get the
> first" if a FIFO queue _is_ a prime dynamic use case.  And there's no
> efficient way at all to access the other end (although I suppose
> set.pop() would - like dict.popitem() - change to give a _destructive_
> way to get at "the other end").
>

I must admit that I was assuming without stating that a full OrderedSet
implementation would support the MutableSequence interface.

Dictionaries can't do that because they already support the MutableMapping
interface.

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/JL7N2ZPTWGGDDSRIAWXPK6PSADBPWLKK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should set objects maintain insertion order too?

[Tim Peters]

[Nick]
> I must admit that I was assuming without stating that a full OrderedSet
> implementation would support the MutableSequence interface.

Efficient access via index position too would be an enormous new
requirement,  My bet:  basic operations would need to change from O(1)
to O(log(N)).

BTW, in previous msgs there are links to various implementations
calling themselves "ordered sets".  One of them supplies O(1)
indexing, but at the expense of making deletion O(N) (!):

https://pypi.org/project/ordered-set/

If efficient indexing is really wanted, then the original "use case"
Larry gave was definitely obscuring an XY problem ;-)
___
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/IBRSGUTHIMOZ6JGIYJBQJFXEANFZI4V5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should set objects maintain insertion order too?

[Wes Turner]

How slow and space-inefficient would it be to just implement the set
methods on top of dict?

Do dicts lose insertion order when a key is deleted? AFAIU, OrderedDict do
not lose insertion order on delete. Would this limit the utility of an
ordered set as a queue? What set methods does a queue need to have?

On Thu, Dec 19, 2019, 11:41 PM Tim Peters  wrote:

> [Nick]
> > I must admit that I was assuming without stating that a full OrderedSet
> > implementation would support the MutableSequence interface.
>
> Efficient access via index position too would be an enormous new
> requirement,  My bet:  basic operations would need to change from O(1)
> to O(log(N)).
>
> BTW, in previous msgs there are links to various implementations
> calling themselves "ordered sets".  One of them supplies O(1)
> indexing, but at the expense of making deletion O(N) (!):
>
> https://pypi.org/project/ordered-set/
>
> If efficient indexing is really wanted, then the original "use case"
> Larry gave was definitely obscuring an XY problem ;-)
> ___
> 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/IBRSGUTHIMOZ6JGIYJBQJFXEANFZI4V5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/PK4C2OGTB2HZ4E7OYU6B6W7A7H4LPX7W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should set objects maintain insertion order too?

[Inada Naoki]

On Fri, Dec 20, 2019 at 4:15 PM Wes Turner  wrote:
>
> How slow and space-inefficient would it be to just implement the set methods 
> on top of dict?

Speed:  Dict doesn't cache the position of the first item.  Calling
next(iter(D)) repeatedly is O(N) in worst case.
Space:  It waste 8bytes per member.

>
> Do dicts lose insertion order when a key is deleted? AFAIU, OrderedDict do 
> not lose insertion order on delete.

Dict keeps insertion order after deletion too.

>Would this limit the utility of an ordered set as a queue? What set methods 
>does a queue need to have?

I want O(1) D.popleft(). (The name is borrowed from deque.  popfirst()
would be better maybe).

--
Inada Naoki  
___
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/T4DT5P7CZE7A4J6XNOT6QGC5UDS4INTR/
Code of Conduct: http://python.org/psf/codeofconduct/