Hello,
I'd like to ask for the reversion of the changes done in
https://github.com/python/cpython/pull/11664
The reason is simple: the PR isn't complete, it lacks docs and tests.
It also didn't pass any review (this was pointed by Ronald), even
though it adds 1300 lines of code. No programmer
On Sun, 3 Feb 2019 23:22:25 +0100
Victor Stinner wrote:
> Hi Antoine,
>
> The rules to decide what goes where have been discussed in the issues which
> created Include/cpython/ and the issue moving more headers to
> Include/internal/.
>
> In short, internal/ should not be used outside CPython co
On Sun, 3 Feb 2019 21:25:27 -0600
Davin Potts wrote:
> On 2/3/2019 7:55 PM, Guido van Rossum wrote:
> > Also, did anyone ask Davin directly to roll it back?
>
> Simply put: no. There have been a number of reactionary comments in the
> last 16 hours but no attempt to reach out to me directly d
On Sun, 3 Feb 2019 17:52:55 -0800
Raymond Hettinger wrote:
> > On Feb 3, 2019, at 1:03 PM, Antoine Pitrou wrote:
> >
> > I'd like to ask for the reversion of the changes done in
> > https://github.com/python/cpython/pull/11664
>
> Please work *with* Davin o
On Sun, 3 Feb 2019 18:10:43 -0800
Raymond Hettinger wrote:
> > On Feb 3, 2019, at 5:40 PM, Terry Reedy wrote:
> >
> > On 2/3/2019 7:55 PM, Guido van Rossum wrote:
> >> Also, did anyone ask Davin directly to roll it back?
> >
> > Antoine posted on the issue, along with Robert O. Robert revi
On Sun, 3 Feb 2019 21:12:38 -0600
Davin Potts wrote:
>
> I was encouraged by Lukasz, Yury, and others to check in this code early,
> not waiting for tests and docs, in order to both solicit more feedback and
> provide for broader testing.
For the record: submitting a PR without tests or docs is
Hello,
In a recent message, Raymond dramatically pretends that I would have
"edited out" Davin of the maintainers list for the multiprocessing
module.
What I did (*) is different: I asked to mark Davin inactive and to stop
auto-assigning him on bug tracker issues. Davin was /still/ listed in
t
Hello Davin,
I would like this discussion to be constructive and not vindicative. So
I would ask that we leave personal attacks out of this.
> I have been part of several group discussions (among core developers)
> now regarding how to balance the efforts of contributors with copious
> time to
On Mon, 4 Feb 2019 09:45:39 -0600
Zachary Ware wrote:
> On Mon, Feb 4, 2019 at 4:39 AM Antoine Pitrou wrote:
> > What I did (*) is different: I asked to mark Davin inactive and to stop
> > auto-assigning him on bug tracker issues. Davin was /still/ listed in
> > the expert
Hi David,
I cannot comment on the PR, but since the functionality is
asyncio-specific, I would suggest moving it to a dedicate
`asyncio.testing` module, or something similar, rather than leaving it
in `unittest` proper.
Regards
Antoine.
On Tue, 5 Feb 2019 07:05:05 -0500
David Shawley wrote:
Hello,
For the record there are number of initiatives currently to boost the
usefulness and efficiency of multi-process computation in Python.
One of them is PEP 574 (zero-copy pickling with out-of-band buffers),
which I'm working on.
Another is Pierre Glaser's work on allowing pickling of dyn
On Thu, 7 Feb 2019 12:19:14 -0600
Neil Schemenauer wrote:
> On 2019-02-06, Antoine Pitrou wrote:
> > For maximum synergy between these initiatives and the resulting APIs,
> > it is better if things are done in the open ;-)
>
> Hi Antoine,
>
> It would be good if
On Wed, 13 Feb 2019 16:24:48 +0100
Petr Viktorin wrote:
> PEP 394 says:
>
> > This recommendation will be periodically reviewed over the next few
> > years, and updated when the core development team judges it
> > appropriate. As a point of reference, regular maintenance releases
> > for the
On Wed, 13 Feb 2019 17:18:15 +0100
Petr Viktorin wrote:
> On 2/13/19 4:46 PM, Antoine Pitrou wrote:
> > On Wed, 13 Feb 2019 16:24:48 +0100
> > Petr Viktorin wrote:
> >> PEP 394 says:
> >>
> >> > This recommendation will be periodically reviewed
On Wed, 13 Feb 2019 17:32:44 -0800
Nathaniel Smith wrote:
> On Wed, Feb 13, 2019 at 3:02 PM Steven D'Aprano wrote:
> >
> > On Wed, Feb 13, 2019 at 05:16:54PM -0500, Terry Reedy wrote:
> >
> > > It appears python is already python3 for a large majority of human users
> > > (as opposed to machine
On Thu, 14 Feb 2019 00:57:36 -0500
Jason Swails wrote:
>
> I literally just ran into this problem now. Part of a software suite I've
> written uses Python to fetch updates during the installation process. Due
> to the target audience, it needs to access the system Python (only), and
> support s
On Sat, 16 Feb 2019 11:15:44 +0100
Jeroen Demeyer wrote:
> On 2019-02-16 00:37, Eric Snow wrote:
> > One thing that would help simplify changes
> > in this area is if PyInterpreterState were defined in
> > Include/internal.
>
> How would that help anything? I don't like the idea (in general, I'
On Sat, 16 Feb 2019 14:34:46 -0800
Steve Dower wrote:
> On 16Feb.2019 1332, Antoine Pitrou wrote:
> > On Sat, 16 Feb 2019 11:15:44 +0100
> > Jeroen Demeyer wrote:
> >> On 2019-02-16 00:37, Eric Snow wrote:
> >>> One thing that would help simpl
On Mon, 18 Feb 2019 19:04:31 -0800
Steve Dower wrote:
>
> > I'm afraid of hiding actually useful private macros under Py_BUILD_CORE.
> > For example, Modules/_functoolsmodule.c and Modules/_json.c use API
> > functions from (4). But if an API function is useful for implementing
> > functools or j
On Thu, 21 Feb 2019 12:13:51 +0100
Victor Stinner wrote:
>
> Premature optimization is the root of all evil. Most C extensions use
> premature optimization
How do you know it's premature? Some extensions _are_ meant for speed.
Regards
Antoine.
___
Le 21/02/2019 à 12:58, Paul Moore a écrit :
> On Thu, 21 Feb 2019 at 11:35, Antoine Pitrou wrote:
>>
>> On Thu, 21 Feb 2019 12:13:51 +0100
>> Victor Stinner wrote:
>>>
>>> Premature optimization is the root of all evil. Most C extensions use
>>> p
On Thu, 21 Feb 2019 13:45:05 +0100
Victor Stinner wrote:
> Le jeu. 21 févr. 2019 à 12:36, Antoine Pitrou a écrit :
> >
> > On Thu, 21 Feb 2019 12:13:51 +0100
> > Victor Stinner wrote:
> > >
> > > Premature optimization is the root of all evil
On Sat, 23 Feb 2019 22:09:03 -0600
Davin Potts wrote:
> I have done what I was asked to do: I added tests and docs in a new
> PR (GH-11816) as of Feb 10.
>
> Since that time, the API has matured thanks to thoughtful feedback
> from a number of active reviewers. At present, we appear to have
> s
On Sun, 24 Feb 2019 20:54:02 -0800
Raymond Hettinger wrote:
> I'll been running benchmarks that have been stable for a while. But between
> today and yesterday, there has been an almost across the board performance
> regression.
Have you tried bisecting to find out the offending changeset, i
On Thu, 28 Feb 2019 22:43:04 +1100
Steven D'Aprano wrote:
> On Wed, Feb 27, 2019 at 02:15:53PM -0800, Barry Warsaw wrote:
>
> > I’m just relaying a data point. Some Python folks I’ve worked with do
> > make the connection between dicts and sets, and have questions about
> > the ordering guaran
On Mon, 11 Mar 2019 18:03:26 -0400
David Mertz wrote:
> Parrot got rather further along than rattlesnake as a register based VM. I
> don't think it every really beat CPython in speed though.
>
> http://parrot.org/
But Parrot also had a "generic" design that was supposed to cater for
all dynamic
On Tue, 12 Mar 2019 01:27:14 -0400
Terry Reedy wrote:
> > First of all, I'm sorry if I'm wrong. I'm not lawyer.
> >
> > You can use both of GPL and MIT. Users can use your package under it.
> >
> > On the other hand, when you publish your package, *you* should follow
> > PSF license.
> > Read
Hi Raymond,
As long as the new serialization order is deterministic (i.e. it's the
same every run and doesn't depend on e.g. hash randomization), then I
think it's fine to change it.
Some more comments / questions:
> 2). Go into every XML module and add attribute sorting options to each
> fun
-1. Please don't remove tempfile.mktemp(). mktemp() is useful to
create a temporary *name*. All other tempfile functions create an
actual file and impose additional burden, for example by making the
file unaccessible by other processes. But sometimes all I want is a
temporary name that an *oth
On Tue, 19 Mar 2019 15:32:25 +0200
Serhiy Storchaka wrote:
> 19.03.19 15:03, Stéphane Wirtel пише:
> > Suggestion and timeline:
> >
> > 3.8, we raise a PendingDeprecationWarning
> > * update the code
> > * update the documentation
> > * update the tests
> >(check a PendingD
On Wed, 20 Mar 2019 00:37:56 +1100
Chris Angelico wrote:
> On Wed, Mar 20, 2019 at 12:25 AM Antoine Pitrou wrote:
> >
> >
> > -1. Please don't remove tempfile.mktemp(). mktemp() is useful to
> > create a temporary *name*. All other tempfile functions crea
On Tue, 19 Mar 2019 15:10:40 +0100
Stéphane Wirtel wrote:
> totally agree with you but this function is deprecated (2002) since 2.3,
> with a simle comment about a security issue.
"Deprecated" doesn't mean anything here. It's just a mention in the
documentation. It doesn't produce actual warnin
Le 19/03/2019 à 15:52, Guido van Rossum a écrit :
>
> If all you need is a random name, why not just use a random number
> generator?
> E.g. I see code like this:
>
> binascii.hexlify(os.urandom(8)).decode('ascii')
mktemp() already does this, probably in a better way, including the
notion o
On Tue, 19 Mar 2019 15:12:06 +0100
Sebastian Rittau wrote:
> Am 19.03.19 um 14:53 schrieb Victor Stinner:
> >
> > When I write tests, I don't really care of security, but
> > NamedTemporaryFile caused me many troubles on Windows: you cannot
> > delete a file if it's still open in a another program
On Wed, 20 Mar 2019 11:25:53 +1300
Greg Ewing wrote:
> Antoine Pitrou wrote:
> > Does it always work? According to the docs, """Whether the name can be
> > used to open the file a second time, while the named temporary file is
> > still open, v
On Thu, 21 Mar 2019 02:07:01 +0100
Victor Stinner wrote:
> Le lun. 18 mars 2019 à 23:41, Raymond Hettinger
> a écrit :
> > The code in the current 3.8 alpha differs from 3.7 in that it removes
> > attribute sorting and instead preserves the order the user specified when
> > creating an element.
On Thu, 21 Mar 2019 01:46:14 +0100
Victor Stinner wrote:
>
> Getting the same output on Python 3.7 and Python 3.8 is also matter
> for https://reproducible-builds.org/
If you want reproducible output, you should settle on a well-known
version of Python. You don't expect two different versions o
On Fri, 22 Mar 2019 20:31:33 +1300
Greg Ewing wrote:
> A poster on comp.lang.python is asking about array.array('u').
> He wants an efficient mutable collection of unicode characters
> that can be initialised from a string.
TBH, I think anyone trying to use array.array should be directed to
Numpy
On Fri, 22 Mar 2019 13:27:08 +0200
Serhiy Storchaka wrote:
> 22.03.19 09:31, Greg Ewing пише:
> > A poster on comp.lang.python is asking about array.array('u').
> > He wants an efficient mutable collection of unicode characters
> > that can be initialised from a string.
> >
> > According to the
On Fri, 22 Mar 2019 12:51:49 +0100
Stefan Behnel wrote:
> Antoine Pitrou schrieb am 22.03.19 um 11:39:
> > On Fri, 22 Mar 2019 20:31:33 +1300 Greg Ewing wrote:
> >> A poster on comp.lang.python is asking about array.array('u').
> >> He wants an efficient mut
On Fri, 22 Mar 2019 16:11:45 +0200
Serhiy Storchaka wrote:
> 22.03.19 13:33, Antoine Pitrou пише:
> > On Fri, 22 Mar 2019 13:27:08 +0200
> > Serhiy Storchaka wrote:
> >> Making it always 32 bits would be compatibility breaking change.
> >> Currently array(&
On Mon, 25 Mar 2019 21:53:07 +1000
Nick Coghlan wrote:
> On Mon, 25 Mar 2019 at 14:39, Inada Naoki wrote:
> > We have many ways to deprecation:
> >
> > * Document only deprecation (no warning) -- no actual removal is planned.
> > * FutureWarning -- to warn end users.
> > * DeprecationWarning --
On Wed, 27 Mar 2019 15:59:25 -0700
"Gregory P. Smith" wrote:
>
> That had a C++ stack trace 1000+ levels deep repeating the pattern of
>
> ...
> @ 0x564d59bd21de 32 func_dealloc
> @ 0x564d59bce0c1 32 cell_dealloc
> @ 0x564d5839db41 48 tupledeall
On Thu, 11 Apr 2019 08:26:47 -0700
Steve Dower wrote:
> On 10Apr2019 1917, Nathaniel Smith wrote:
> > It sounds like --with-pydebug has accumulated a big grab bag of
> > unrelated features, mostly stuff that was useful at some point for
> > some CPython dev trying to debug CPython itself? It's cle
On Mon, 15 Apr 2019 12:50:00 +0200
Antoine Pitrou wrote:
> On Thu, 11 Apr 2019 08:26:47 -0700
> Steve Dower wrote:
> > On 10Apr2019 1917, Nathaniel Smith wrote:
> > > It sounds like --with-pydebug has accumulated a big grab bag of
> > > unrelated features, mostly
On Wed, 24 Apr 2019 01:44:17 +0200
Victor Stinner wrote:
>
> The first requirement for the use case is that a Python debug build
> supports the ABI of a release build. The current blocker issue is that
> the Py_DEBUG define imply the Py_TRACE_REFS define: PyObject gets 2
> extra fields (_ob_prev
On Wed, 24 Apr 2019 18:02:18 +0200
Victor Stinner wrote:
>
> I see 2 solutions:
>
> (1) Use a different directory. If "libpython" gets the same filename
> in release and debug mode, at least, they must be installed in
> different directories. If libpython build in debug mode is installed
> in /u
On Sun, 28 Apr 2019 08:25:30 +0100
Chris Withers wrote:
>
> What's the best way to spell "show me all the revisions on master that
> affect {mock files} from commit x to HEAD, not including x"?
Something like:
$ git log x...HEAD -- {mock files}
perhaps?
Regards
Antoine.
__
Hello,
I've put the final touches to PEP 574 - Pickle protocol 5 with
out-of-band data (*). It is now ready for review. The implementation
is fully functional, as well as its PyPI backport (**), and has
regression tests against Numpy. Numpy and PyArrow have their own tests
against the pickle5
On Tue, 30 Apr 2019 22:24:53 +0100
Chris Withers wrote:
> Hi All,
>
> I have a crazy idea of getting unittest.mock up to 100% code coverage.
>
> I noticed at the bottom of all of the test files in testmock/, there's a:
>
> if __name__ == '__main__':
> unittest.main()
>
> ...block.
>
> Ho
On Wed, 1 May 2019 14:30:01 +0100
Chris Withers wrote:
>
> > Is it really that difficult to simply tell coverage to ignore them? I
> > thought someone had already pointed to a coveragerc file that let you
> > do this.
>
> It would be if the cpython repo had a coveragerc, but it does not.
Well
On Wed, 1 May 2019 12:49:24 -0700
Nick Coghlan wrote:
> Thanks Antoine.
>
> As BDFL-Delegate I'm happy with this version of the PEP, so it's my
> pleasure to accept it for inclusion in Python 3.8.
Thank you Nick!
The implementation has been posted for review at
https://github.com/python/cpyth
On Mon, 6 May 2019 15:55:03 +0200
Jeroen Demeyer wrote:
> Hello,
>
> I have a simple question for which there doesn't seem to be a good
> answer: is the layout of PyTypeObject considered to be part of the
> stable ABI?
>
> Officially, the answer is certainly "no" (see PEP 384).
>
> However, u
Should I submit a PR to change the PEP status or would you like to do
it?
Regards
Antoine.
On Wed, 1 May 2019 12:49:24 -0700
Nick Coghlan wrote:
> Thanks Antoine.
>
> As BDFL-Delegate I'm happy with this version of the PEP, so it's my
> pleasure to accept it for inclusion in Python 3.8.
>
On Wed, 15 May 2019 08:40:58 +0100
Steve Holden wrote:
> As a mere user I'd like to thank the developer team for biting this bullet.
> Remembering the transition to Git I am sure that the further
> democratisation (?) of the development process will similarly increase the
> diversity and scope of
On Tue, 14 May 2019 18:11:14 -0700
Barry Warsaw wrote:
> As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest
> of the Steering Council, I hereby Accept this PEP.
For future reference, is it possible to post the Steering Council's
reflection and rationale on the PEP?
Th
On Wed, 15 May 2019 10:44:35 +0200
Bastian Venthur wrote:
> Hi,
>
> I'd like to discuss the idea to add a module to parse TOML [toml-lang]
> to Python's standard library.
How stable is the TOML format? Is it bound to change significantly in
the coming years?
If the format is stable enough, th
On Wed, 15 May 2019 13:00:16 -0700
Steve Dower wrote:
> On 15May2019 1248, Nathaniel Smith wrote:
> > I don't care about the deprecation either way. But can we fix the
> > individual decorators so both orders work? Even if it requires a special
> > case in the code, it seems worthwhile to remov
Hello,
I need a review on the PEP 574 implementation:
https://github.com/python/cpython/pull/7076
I would really like it to be in 3.8 and so ideally it should be merged
within two weeks.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@pyth
Hi,
- Since PyInitError can be "ok", I'd rather call it "PyInitStatus".
- The PyConfig example sets "module_search_paths" but not
"module_search_paths_set". Is it an error?
- "PyConfig_InitPythonConfig" vs "PyConfig_InitIsolatedConfig": why not
"PyConfig_InitConfig" and "PyConfig_InitIsol
NNTP is still quite used (often through GMane, but probably not only) so
I'd question the removal of nntplib.
cgitb used to be used by some Web frameworks in order to format
exceptions. Perhaps one should check if that's still the case.
If the wave module depends on the audioop module, and if
On Tue, 21 May 2019 00:06:35 +0200
Christian Heimes wrote:
> On 20/05/2019 23.27, Antoine Pitrou wrote:
> > NNTP is still quite used (often through GMane, but probably not only) so
> > I'd question the removal of nntplib.
>
> Is NNTP support important enough to keep
On Tue, 21 May 2019 00:41:19 +0200
Simon Cross wrote:
> Woot. +100 on this PEP.
>
> > If the stdlib didn't have NNTP support, obviously nobody would suggest
> > adding it nowadays.
>
> Perhaps this is a good reason to keep nntplib in the deprecation list?
No, because the same applies to getop
On Tue, 21 May 2019 00:55:20 +0200
Christian Heimes wrote:
> On 21/05/2019 00.13, Antoine Pitrou wrote:
> > On Tue, 21 May 2019 00:06:35 +0200
> > Christian Heimes wrote:
> >> On 20/05/2019 23.27, Antoine Pitrou wrote:
> >>> NNTP is still quite used (o
As I said, if the main annoyance with nntplib is the sporadic test
failures, then the relevant tests can be disabled on CI.
NNTP itself is still used, even if less and less.
Regards
Antoine.
On Tue, 21 May 2019 16:12:42 +0200
Christian Heimes wrote:
> Hi,
>
> I have updated the PEP with fee
On Tue, 21 May 2019 13:59:56 -0400
Terry Reedy wrote:
> On 5/21/2019 9:01 AM, Steven D'Aprano wrote:
> ...
> > Many Python users don't have the privilege of being able to install
> > arbitrary, unvetted packages from PyPI. They get to use only packages
> > from approved vendors, including the stdl
Le 21/05/2019 à 20:16, Brett Cannon a écrit :
>
>
> On Tue., May 21, 2019, 09:10 Christian Heimes, <mailto:christ...@python.org>> wrote:
>
> On 21/05/2019 17.31, Antoine Pitrou wrote:
> >
> > As I said, if the main annoyance with nntplib is the
On Tue, 21 May 2019 17:44:16 -0700
Brett Cannon wrote:
> >
> > So I should never have added those tests and then we wouldn't be talking
> > about removing nntplib.
> >
>
> Not necessarily. I suspect it still would have been listed, you would have
> objected, and someone may have looked at the t
On Thu, 23 May 2019 00:23:39 +0200
Ray Donnelly wrote:
> On Thu, May 23, 2019, 12:17 AM Ivan Pozdeev via Python-Dev <
> python-dev@python.org> wrote:
>
> > On 22.05.2019 23:52, Steve Dower wrote:
> > > On 22May2019 1309, Ivan Pozdeev via Python-Dev wrote:
> > >> As someone whose job is to dia
On Fri, 24 May 2019 00:59:08 +0900
Inada Naoki wrote:
> >
> > It's relatively easy to test replacing our custom allocators with the
> > system ones, yes? Can we try those to see whether they have the same
> > characteristic?
> >
>
> Yes.
>
> PYTHONMALLOC=malloc LD_PRELOAD=/path/to/jemalloc.so
On Fri, 24 May 2019 14:23:21 +0200
Thomas Wouters wrote:
> On Thu, May 23, 2019 at 5:15 PM Steve Dower wrote:
>
> > On 23May2019 0542, Inada Naoki wrote:
> > > 1. perf shows 95% of CPU time is eaten by _PyObject_Free, not kernel
> > space.
> > > 2. This loop is cleary hot:
> > >
> > http
On Fri, 24 May 2019 09:54:05 -0700
Steve Dower wrote:
>
> All in all, this is basically where we are today, with the exception
> that we haven't officially said that we no longer support these modules.
> PEP 594 is this official statement, and our usual process for things we
> don't support is
On Mon, 27 May 2019 09:27:33 -0400
David Mertz wrote:
> On Sun, May 26, 2019 at 11:17 PM Steven D'Aprano
> wrote:
>
> > > Nobody reads warnings.
> >
> > If nobody reads warnings, we should just remove the warnings module and
> > be done with it. That should probably be a PEP.
> >
>
> We'll
Congrats to everyone who participated!
Regards
Antoine.
On Tue, 28 May 2019 13:52:53 +0200
Petr Viktorin wrote:
> As BDFL-Delegate, I am accepting PEP 590 -- Vectorcall: a fast calling
> protocol for CPython.
> https://www.python.org/dev/peps/pep-0590/
>
> There was a major last-minute cha
I second this.
There are currently ~7000 bugs open on bugs.python.org. The Web UI
makes a good job of actually being able to navigate through these bugs,
search through them, etc.
Did the Steering Council conduct a usability study of Github Issues
with those ~7000 bugs open? If not, then I th
On Fri, 31 May 2019 11:58:22 -0700
Nathaniel Smith wrote:
> On Fri, May 31, 2019 at 11:39 AM Barry Warsaw wrote:
> >
> > On May 31, 2019, at 01:22, Antoine Pitrou wrote:
> >
> > > I second this.
> > >
> > > There are currently ~7000 bugs open on
On Sun, 2 Jun 2019 00:56:52 -0500
Tim Peters wrote:
>
> But because O is only trying to deal with small (<= 512 bytes)
> requests, it can use a very fast method based on trivial address
> arithmetic to find the size of an allocated block by just reading it
> up from the start of the (4K) "pool" t
On Thu, 6 Jun 2019 13:57:37 -0500
Tim Peters wrote:
> [Antoine Pitrou ]
> > The interesting thing here is that in many situations, the size is
> > known up front when deallocating - it is simply not communicated to the
> > deallocator because the traditional free() API
On Thu, 6 Jun 2019 16:03:03 -0500
Tim Peters wrote:
> But I don't know what you mean by "access memory in random order to
> iterate over known objects". obmalloc never needs to iterate over
> known objects - indeed, it contains no code capable of doing that..
> Our cyclic gc does, but that's inde
On Thu, 6 Jun 2019 17:26:17 -0500
Tim Peters wrote:
>
> The doubly linked lists in gc primarily support efficient
> _partitioning_ of objects for gc's purposes (a union of disjoint sets,
> with constant-time moving of an object from one set to another, and
> constant-time union of disjoint sets).
On Fri, 7 Jun 2019 19:03:50 -0400
Ned Deily wrote:
> On Jun 7, 2019, at 18:03, Victor Stinner wrote:
> > I am not sure that we are good at archiving.
>
> I'm not sure what this has to do with mailing list URLs but ...
>
> > Example with Subversion links in the bug tracker:
> >
> > https://bu
On Wed, 12 Jun 2019 00:09:10 +0200
Victor Stinner wrote:
> Update.
>
> Le ven. 31 mai 2019 à 10:49, Petr Viktorin a écrit :
> > PEP 570 (Positional-Only Parameters) changed the signatures of
> > PyCode_New() and types.CodeType(), adding a new argument for "posargcount".
> >
>
> Pablo propose
On Thu, 13 Jun 2019 02:07:54 +0200
Victor Stinner wrote:
>
> For PyCodeOptions: does it contain posonlyargcount? If not, how do you
> pass posonlyargcount. I'm not sure if you plan to handle the backward
> compatibility.
The idiom to use it could be:
PyCodeOptions opts = PyCodeOptions_INIT;
//
On Thu, 13 Jun 2019 22:05:01 +0900
Inada Naoki wrote:
>
> Currently, many private APIs uses `PyAPI_FUNC()`.
It's easier to use PyAPI_FUNC() everywhere than forget it in some
places and then bother Windows users.
Private APIs are sometimes used in third-party modules if they want
access to highe
On Sat, 15 Jun 2019 01:15:11 -0500
Tim Peters wrote:
>
> > ...
> > My feeling right now is that Tim's obmalloc-big-pool is the best
> > design at this point. Using 8 KB or 16 KB pools seems to be better
> > than 4 KB. The extra complexity added by Tim's change is not so
> > nice. obmalloc is a
On Sat, 15 Jun 2019 19:56:58 -0500
Tim Peters wrote:
>
> At the start, obmalloc never returned arenas to the system. The vast
> majority of users were fine with that. A relative few weren't. Evan
> Jones wrote all the (considerable!) code to change that, and I
> massaged it and checked it in -
On Sat, 15 Jun 2019 22:02:35 -0600
Neil Schemenauer wrote:
> On 2019-06-15, Antoine Pitrou wrote:
> > We should evaluate what problem we are trying to solve here, instead
> > of staring at micro-benchmark numbers on an idle system.
>
> I think a change to obmalloc is not
On Mon, 17 Jun 2019 11:15:29 +0900
Inada Naoki wrote:
>
> Increasing pool size is one obvious way to fix these problems.
> I think 16KiB pool size and 2MiB (huge page size of x86) arena size is
> a sweet spot for recent web servers (typically, about 32 threads, and
> 64GiB), but there is no evide
Le 17/06/2019 à 10:55, Inada Naoki a écrit :
> On Mon, Jun 17, 2019 at 5:18 PM Antoine Pitrou wrote:
>>
>> On Mon, 17 Jun 2019 11:15:29 +0900
>> Inada Naoki wrote:
>>>
>>> Increasing pool size is one obvious way to fix these problems.
>>> I think
On Mon, 17 Jun 2019 13:44:29 -0500
Tim Peters wrote:
>
> To illustrate, I reverted that change in my PR and ran exactly same
> thing. Wow - _then_ the 1M-arena-16K-pool PR reclaimed 1135(!) arenas
> instead of none. Almost all worse than uselessly. The only one that
> "paid" was the last: the
On Tue, 18 Jun 2019 13:36:33 -0700
Steve Dower wrote:
> On 18Jun2019 1025, Stephen J. Turnbull wrote:
> > Oleg Broytman writes:
> > > On Tue, Jun 18, 2019 at 10:09:59AM -, smartmanoj42...@gmail.com
> > wrote:
> >
> > > > Why don't we check the architecture using js and provide the
On Fri, 21 Jun 2019 12:22:21 +0900
Inada Naoki wrote:
> On Fri, Jun 21, 2019 at 1:28 AM Victor Stinner wrote:
> >
> > Le jeu. 20 juin 2019 à 11:15, Inada Naoki a écrit
> > :
> > > Can we change _PyUnicode_FromId to use _PyUnicode_FromASCII?
> >
> > How would a developer detect a mistake (no
On Fri, 21 Jun 2019 17:18:18 -0500
Tim Peters wrote:
>
> > And what would be an efficient way of detecting allocations punted to
> > malloc, if not address_in_range?
>
> _The_ most efficient way is the one almost all allocators used long
> ago: use some "hidden" bits right before the address
For the record, there's another contender in the allocator
competition now:
https://github.com/microsoft/mimalloc/
Regards
Antoine.
On Mon, 24 Jun 2019 00:20:03 -0500
Tim Peters wrote:
> [Tim]
> > The radix tree generally appears to be a little more memory-frugal
> > than my PR (presumably b
On Thu, 4 Jul 2019 16:19:52 +0900
Inada Naoki wrote:
> On Tue, Jun 25, 2019 at 5:49 AM Antoine Pitrou wrote:
> >
> >
> > For the record, there's another contender in the allocator
> > competition now:
> > https://github.com/microsoft/mimalloc/
> >
>
On Thu, 4 Jul 2019 23:32:55 +0900
Inada Naoki wrote:
> On Thu, Jul 4, 2019 at 8:09 PM Antoine Pitrou wrote:
> >
> > Ah, interesting. Were you able to measure the memory footprint as well?
> >
>
> Hmm, it is not good. mimalloc uses MADV_FREE so it may affect to
On Tue, 23 Jul 2019 23:44:35 +0100
MRAB wrote:
>
> However, when comparing the values you have a problem: you have 2
> collections of objects that might contain duplicates, might not be
> hashable, and might not be sortable, so comparing them could be
> inefficient, and you can't refer back to
On Wed, 24 Jul 2019 19:09:37 -0400
David Mertz wrote:
>
> There are various possible behaviors that might make sense, but having
> `d.values() != d.values()` is about the only one I can see no sense in.
Why? Does the following make no sense to you?
>>> iter(()) == iter(())
False
Python deliber
On Fri, 26 Jul 2019 20:28:05 +1000
Steven D'Aprano wrote:
> So there are no conceptual problems in defining equality for value
> views. Putting aside efficiency, this is easy to solve.
Right. It's just waiting for someone's PR. However, that doesn't mean
that the current behaviour is senseless
On Fri, 26 Jul 2019 19:09:35 -0700
Guido van Rossum wrote:
> See the thread 'The trouble with "Easy" issues' in
> core-mentors...@python.org.
> Essentially those "easy" issues aren't so easy,
> and we're starting over.
But how do we know that the same mistake won't be done again? :-)
Regards
An
1001 - 1100 of 4909 matches
Mail list logo
