My thanks to Miro and (especially!) Victor for quickly putting together
those lovely PRs. I've now merged everything outstanding for 3.4 and
3.5 except this:
https://github.com/python/cpython/pull/10994
It's a backport of LibreSSL 2.7.0 support for 3.5. This is something I
believe
On Tue, Feb 26, 2019 at 2:07 PM Neil Schemenauer
wrote:
> On 2019-02-26, Gregory P. Smith wrote:
> > On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw wrote:
> > For an OS distro provided interpreter, being able to restrict its use to
> > only OS distro provided software would be ideal (so ideal
On Wed, Feb 27, 2019 at 3:04 PM Richard Belleville
wrote:
> Timedelta division is quite a nice solution to the problem. However, since
> we're maintaining a python version agnostic library at least until 2020, we
> need a solution that works in python 2 as well.
>
So you were limited to a py2
Sorry for the slow response.
Timedelta division is quite a nice solution to the problem. However, since
we're maintaining a python version agnostic library at least until 2020, we
need a solution that works in python 2 as well.
For the moment, we've left the code as in the original snippet.
Did we ever hear back from the OP as to whether they were using py2 or 3?
If they were unable to find timedelta division in py3 -- that's a pretty
good case that we need something else.
The OP:
"""
On Wed, Feb 13, 2019 at 9:10 PM Richard Belleville via Python-Dev <
python-dev@python.org> wrote:
On Wed, Feb 27, 2019 at 7:15 AM Paul Ganssle wrote:
> As another data point, I also have a background in the physical sciences,
> and I actually do find it quite intuitive. The first time I saw this idiom
> I took it to heart immediately and only stopped using it because many of
> the libraries
On Tue, Feb 26, 2019 at 7:22 PM Terry Reedy wrote:
> > timedelta.total_seconds()
>
> To me, total_x implies that there is a summation of multiple timedeltas,
> and there is not. So not intuitive to me.
THAT was a discussion for when it was added -- I can't say it's my favorite
name either.
If sets were ordered, then what ought pop() return - first, last, or
nevertheless an arbitrary element? I lean toward arbitrary because in
existing code, set.pop often implies that which particular element is
immaterial.
On Wed, Feb 27, 2019 at 2:18 PM Barry Warsaw wrote:
> On Feb 27, 2019, at
On Feb 27, 2019, at 13:54, Chris Barker via Python-Dev
wrote:
>
> A mapping and a set type really don't have much to do with each other other
> than implementation -- anyone that isn't familiar with python C code, or hash
> tables in general, wouldn't likely have any expectation of them
On Tue, Feb 26, 2019 at 3:43 PM Barry Warsaw wrote:
> The behavior differences between dicts and sets is already surprising to
> many users, so we should be careful not to make the situation worse.
>
It's a nice to have, but other than the fact that we all used to use a dict
when we really
On Tue, Feb 26, 2019 at 2:31 PM Steve Dower wrote:
> On 2/26/2019 1:20 PM, Gregory P. Smith wrote:
> > For an OS distro provided interpreter, being able to restrict its use to
> > only OS distro provided software would be ideal (so ideal that people
> > who haven't learned the hard distro
On Tue, Feb 26, 2019 at 2:28 PM Victor Stinner wrote:
> Le mar. 26 févr. 2019 à 22:24, Gregory P. Smith a écrit
> :
> > A feature that I find missing from posix-y OSes that support #! lines is
> an ability to restrict what can use a given interpreter.
>
> Fedora runs system tools (like
We should also consider that before long datetimes are frequently stored to
nanosecond resolution (two fields where this is significant are finance and
physics, and the latter would probably appreciate femtosedonds as well). So
maybe an external library that layers on top of datetime might be
On 2/26/19 7:03 PM, Chris Barker via Python-Dev wrote:
> This thread petered out, seemingly with a consensus that we should
> update the docs -- is anyone doing that?
>
I don't think anyone is, I've filed a BPO bug for it:
https://bugs.python.org/issue3613
>
> -- I am a physical scientist, I
> On 27 Feb 2019, at 14:22, Łukasz Langa wrote:
>
> The Python Language Summit is an event for the developers of Python
> implementations (CPython, PyPy, Jython, and so on) to share information,
> discuss our shared problems, and — hopefully — solve them.
Oh, you'd also like to know *when* and
On Wed, Feb 27, 2019 at 9:59 PM Victor Stinner wrote:
> Maybe pickle is inefficient in its memory management and causes a lot
> of memory fragmentation?
>
No, it is not relating to pickle efficiency and memory fragmentation.
This problem is happened because pymalloc doesn't have no hysteresis
The Python Language Summit is an event for the developers of Python
implementations (CPython, PyPy, Jython, and so on) to share information,
discuss our shared problems, and — hopefully — solve them.
These issues might be related to the language itself, the standard
library, the development
Maybe pickle is inefficient in its memory management and causes a lot
of memory fragmentation?
It's hard to write an efficient memory allocator :-( My notes on memory:
* "Excessive peak memory consumption by the Python parser"
https://bugs.python.org/issue26415
*
It happened very accidentally. Since venv is used,
many paths in the interpreter is changed. So how memory
is used are changed.
Let's reproduce the accident.
$ cat m2.py
import pickle, sys
LIST = pickle.dumps([[0]*10 for _ in range(10)], pickle.HIGHEST_PROTOCOL)
N = 1000
z = [[0]*10 for _ in
Sorry, I didn't get a coffee yet: more *often* in a venv.
Le mer. 27 févr. 2019 à 11:32, Victor Stinner a écrit :
>
> Any idea why Python calls mmap+munmap more even in a venv?
>
> Victor
>
> Le mer. 27 févr. 2019 à 10:00, INADA Naoki a écrit :
> >
> > >
> > > > Ah, another interesting point,
Any idea why Python calls mmap+munmap more even in a venv?
Victor
Le mer. 27 févr. 2019 à 10:00, INADA Naoki a écrit :
>
> >
> > > Ah, another interesting point, this huge slowdown happens only when
> > > bm_pickle.py
> > > is executed through pyperformance. When run it directly, slowdown is
While these are interesting ideas, wouldn't it be better to leave this kind
of packaging to snap and similar utilities that bundle the language support
and libraries to allow simple isolated installation.
Kind regards
Steve Holden
On Tue, Feb 26, 2019 at 10:05 PM Neil Schemenauer
wrote:
> On
>
> > Ah, another interesting point, this huge slowdown happens only when
bm_pickle.py
> > is executed through pyperformance. When run it directly, slowdown is
> > not so large.
>
> pyperformance runs benchmarks in a virtual environment. I don't know
> if it has any impact on bm_pickle.
>
> Most
23 matches
Mail list logo
