On Thu, 9 Nov 2017 04:22:20 -0800
Raymond Hettinger wrote:
>
> Probably, we're the wrong people to be talking about this. The proposal is
> to make these macros part of the official API so that it starts to appear in
> source code everywhere. The question isn't whether the above makes sense t
On Sat, 11 Nov 2017 07:34:05 +
Brett Cannon wrote:
>
> One problem with that is I don't want e.g. mypy to start spewing out
> warnings while checking my code.
It's rather trivial for mypy (or any other code analysis tool) to turn
warnings off when importing the code under analysis. And sinc
On Sun, 12 Nov 2017 19:24:12 +1000
Nick Coghlan wrote:
> I've written a short(ish) PEP for the proposal to change the default
> warnings filters to show DeprecationWarning in __main__:
> https://www.python.org/dev/peps/pep-0565/
Thank you for writing this. This is a nice summary. You finally
co
On Sun, 12 Nov 2017 19:48:28 -0800
Nathaniel Smith wrote:
> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
> > This change will lead to DeprecationWarning being displayed by default for:
> >
> > * code executed directly at the interactive prompt
> > * code executed directly as part of a sin
On Mon, 13 Nov 2017 22:37:46 +1100
Chris Angelico wrote:
> On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou wrote:
> > On Sun, 12 Nov 2017 19:48:28 -0800
> > Nathaniel Smith wrote:
> >> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
> >> > This ch
On Mon, 13 Nov 2017 17:08:06 +0100
Victor Stinner wrote:
> Hi,
>
> The discussion on DeprecationWarning reminded me my old idea of a
> "development mode" for CPython: -X dev. Since Brett likes it, I post
> it on python-dev. Last year, I posted this idea to python-ideas but my
> idea was rejected:
Le 13/11/2017 à 17:46, Victor Stinner a écrit :
> 2017-11-13 17:40 GMT+01:00 Antoine Pitrou :
>> I would personally not add `-b` in those options. I think it was
>> useful while porting stuff to 3.x, but not so much these days.
>
> You should consider youself as lucky if
On Mon, 13 Nov 2017 18:19:07 +0100
Victor Stinner wrote:
>
> I really dislike this code since warnings.catch_warnings() is
> process-wide and so impact other threads :-(
>
> (Maybe Yury's PEP "context variables" would help here? ;-))
They can't really help unless we break the catch_warnings() A
Hi Stephen,
On Mon, 13 Nov 2017 15:55:03 -0500
Stephen Michell wrote:
> I am looking for one or two experts to discuss with me how Python concurrency
> features fit together, and possible vulnerabilities associated with that.
>
> TR 24772 lists 5 vulnerabilities associated with
Can you expla
On Thu, 16 Nov 2017 12:53:24 +0100
Victor Stinner wrote:
> Ok, I merged my PR adding -X dev: you can now test in Python 3.7 ;-)
>
> > The list of checks can be extended later. For example, we may enable
> > the debug mode of asyncio: PYTHONASYNCIODEBUG=1.
>
> I opened https://bugs.python.org/
On Thu, 16 Nov 2017 03:57:49 +0100
Victor Stinner wrote:
> Hi,
>
> Since Brett and Nick like the idea and nobody complained against it, I
> implemented the -X dev option:
> https://bugs.python.org/issue32043
> (Right now, it's a pull request.)
Could you measure and perhaps document the expected
Le 16/11/2017 à 13:38, Victor Stinner a écrit :
> 2017-11-16 13:09 GMT+01:00 Antoine Pitrou :
>>> What do you think? Is it ok to include asyncio in the global "developer
>>> mode"?
>>
>> I'd rather not. Those are two orthogonal things. In part
Hi Victor,
Thanks for the answer!
Le 16/11/2017 à 13:48, Victor Stinner a écrit :
>
> faulthandler has a negligible cost on performance/memory.
>
> For -W default, I guess that your question is the cost on emitting a
> warning: overhead when a warning is displayed, and overhead when the
> warn
Le 16/11/2017 à 17:42, Victor Stinner a écrit :
>
> Running an application in debug mode or "developer mode" was never
> recommanded by anyone.
I don't know. Almost everyone runs Python with __debug__ set to True :-)
Regards
Antoine.
___
Python-Dev
Hi Christian,
On Fri, 17 Nov 2017 10:15:24 +0100
Christian Tismer wrote:
>
> Example:
> One of my tests emits warnings when a certain condition is
> met. Instead of reporting the error immediately, it uses
> warnings, and at the end of the test, an error is produced
> if there were warnings.
I
I agree with Serhiy. It doesn't make sense to add PyTuple_GET_ITEM to
the stable ABI. People who want to benefit from the stable ABI should
use PyTuple_GetItem. That's not very complicated.
Regards
Antoine.
On Sat, 18 Nov 2017 11:42:36 +0200
Serhiy Storchaka wrote:
> 18.11.17 11:13, Victo
On Sat, 18 Nov 2017 10:13:36 +0100
Victor Stinner wrote:
>
> Anyway, the PyTuple_GET_ITEM() will remain a macro in the default API for
> Python 3.7.
>
> See also my blog post which explains why the fact that it is a macro
> prevents us from optimizing it, like having specialized compact tuple fo
On Sat, 18 Nov 2017 01:01:47 +0100
Victor Stinner wrote:
>
> Maybe, the minimum change is to expose _PyRuntime_Initialize() in the
> public C API?
+1. Also a symmetric PyRuntime_Finalize() function (even if it's a
no-op currently).
Regards
Antoine.
__
On Sun, 19 Nov 2017 00:18:28 +0100
Victor Stinner wrote:
> Le 18 nov. 2017 10:44, "Serhiy Storchaka" a écrit :
>
> The simplest way to do this:
>
> #define PyTuple_GET_ITEM PyTuple_GetItem
>
> This will not add new names to ABI. Such defines can be added in a separate
> header file included fo
On Wed, 22 Nov 2017 10:38:32 +0100
Victor Stinner wrote:
>
> I fixed the issue by calling _PyRuntime_Initialize() as the very first
> function in main().
>
> I also had to add _PyMem_GetDefaultRawAllocator() to get a
> deterministic memory allocator, rather than depending on the allocator
> set
On Wed, 22 Nov 2017 12:12:32 +0100
Victor Stinner wrote:
> 2017-11-22 12:04 GMT+01:00 Antoine Pitrou :
> > IMHO this really needs a simple solution documented somewhere. Also,
> > hopefully when you do the wrong thing, you get a clear error message to
> > know how to fix yo
On Wed, 22 Nov 2017 15:03:09 +0200
Serhiy Storchaka wrote:
> From
> https://stackoverflow.com/questions/45190729/differences-between-generator-comprehension-expressions.
>
> g = [(yield i) for i in range(3)]
>
> Syntactically this looks like a list comprehension, and g should be a
> list
On Wed, 22 Nov 2017 15:15:49 +0100
Ivan Levkivskyi wrote:
> There are many things that I would reject in code review, but they are
> still allowed in Python,
> this is one of the reasons why code reviews exist. Also I am not sure how
> `yield` in a comprehension
> is more tricky than `await` in a
On Wed, 22 Nov 2017 17:08:14 +0100
Ivan Levkivskyi wrote:
> On 22 November 2017 at 16:56, Yury Selivanov
> wrote:
>
> > On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi
> > wrote:
> > > On 22 November 2017 at 15:47, Paul Moore wrote:
> > [...]
> > I'm all for prohibiting using 'yield' exp
On Thu, 23 Nov 2017 10:37:59 +0100
"M.-A. Lemburg" wrote:
> On 18.11.2017 01:01, Victor Stinner wrote:
> > Hi,
> >
> > The CPython internals evolved during Python 3.7 cycle. I would like to
> > know if we broke the C API or not.
> >
> > Nick Coghlan and Eric Snow are working on cleaning up the P
On Thu, 23 Nov 2017 12:39:46 +0100
Ivan Levkivskyi wrote:
>
> Also I think it makes sense to keep discussion in one place, i.e. either
> here xor at https://bugs.python.org/issue10544
The bug tracker can be used for implementation discussions, but general
language design decisions (such as wheth
On Thu, 23 Nov 2017 09:50:27 +
Paul Moore wrote:
> On 23 November 2017 at 09:14, Steve Holden wrote:
> > I would urge developers, in their improvements to the language to support
> > asynchronous programming, to bear in mind that this is (currently) a
> > minority use case. Why the rush to se
Le 23/11/2017 à 13:01, Ivan Levkivskyi a écrit :
>
> "I don't use it, therefore it is not needed" is a great argument, thanks.
This is just a data point. Some people seem to think that the construct
is useful for asynchronous programming. In my experience it isn't.
YMMV, etc.
> Lets just for
On Thu, 23 Nov 2017 14:17:32 +0200
Serhiy Storchaka wrote:
>
> I used the "yield" statement, but I never used the "yield" expressions.
> And I can't found examples. Could you please present a real-world use
> case for the "yield" (not "yield from") expression?
Of course I can. "yield" express
Le 23/11/2017 à 13:42, Ivan Levkivskyi a écrit :
>
> Great, so I open this page and see this code:
>
> results = []
> for future in list_of_futures:
> results.append(yield future)
>
> Interesting, why don't they use a comprehension for this and instead
> need to invent a whole `tornado.gen.
On Thu, 23 Nov 2017 14:54:27 +0200
Serhiy Storchaka wrote:
> 23.11.17 14:30, Antoine Pitrou пише:
> > On Thu, 23 Nov 2017 14:17:32 +0200
> > Serhiy Storchaka wrote:
> >>
> >> I used the "yield" statement, but I never used the "yield" ex
On Sat, 25 Nov 2017 03:03:02 +
MRAB wrote:
> On 2017-11-25 02:21, Chris Jerdonek wrote:
> > On Fri, Nov 24, 2017 at 5:06 PM, Nathaniel Smith wrote:
> >> On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum
> >> wrote:
> >>> The more I hear about this topic, the more I think that `await`,
On Sat, 25 Nov 2017 17:10:12 +1000
Nick Coghlan wrote:
> On 25 November 2017 at 16:18, Nathaniel Smith wrote:
> > On Fri, Nov 24, 2017 at 9:39 PM, Nick Coghlan wrote:
> >> On 25 November 2017 at 15:27, Nathaniel Smith wrote:
> >>> On Fri, Nov 24, 2017 at 9:04 PM, Nick Coghlan wrote:
> >>>
At this point, the fact that several Python core developers fail to
understand the pieces of code presented as examples should be a hint
that the syntax here is far from desirable...
Regards
Antoine.
On Sat, 25 Nov 2017 15:47:14 +
Paul Moore wrote:
> On 25 November 2017 at 14:55, Ivan Lev
On Mon, 27 Nov 2017 00:41:55 -0800
Nathaniel Smith wrote:
>
> Since most libraries assume that they control both __await__ and the
> coroutine runner, they don't tend to give great error messages here
> (though trio does [2] ;-)). I think this is also why the asyncio docs
> don't talk about this.
isdataclass() testing for instance-ship does sound like a bug magnet to
me.
If isdataclassinstance() is too long (that's understandable), how about
isdatainstance()?
Regards
Antoine.
On Wed, 29 Nov 2017 17:02:21 -0800
Guido van Rossum wrote:
> On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer wr
Or, simply, is_dataclass_instance(), which is even longer, but far more
readable thanks to explicit word boundaries :-)
On Thu, 30 Nov 2017 10:16:58 +0100
Antoine Pitrou wrote:
> isdataclass() testing for instance-ship does sound like a bug magnet to
> me.
>
> If isdataclassinsta
On Tue, 28 Nov 2017 12:10:54 -0800
Lukasz Langa wrote:
> Hi Mark,
> it looks like the PEP is dormant for over two years now. I had multiple
> people ask me over the past few days about it though, so I wanted to ask if
> this is moving forward.
I am -1 on this PEP. I also think we don't need an
On Sat, 2 Dec 2017 09:02:37 -0500
"Eric V. Smith" wrote:
> I've pushed another version of PEP 557. The only difference is changing
> the default value of "order" to False instead of True. This matches
> regular classes: instances can be tested for equality, but are unordered.
>
> Discussion at
On Tue, 5 Dec 2017 19:46:39 +0100
Stephane Wirtel via Python-Dev wrote:
> But seriously, I was surprised by the number of Pull Requests and by the
> number of contributors from Feb 2017 to Oct 2017.
>
> Here is my graph for October and November 2017.
Is it possible to compare those numbers with
On Wed, 6 Dec 2017 01:49:41 +0100
Victor Stinner wrote:
> Hi,
>
> I knew that I had to rewrite my PEP 540, but I was too lazy. Since
> Guido explicitly requested a shorter PEP, here you have!
>
> https://www.python.org/dev/peps/pep-0540/
>
> Trust me, it's the same PEP, but focused on the most
On Wed, 6 Dec 2017 23:20:41 +0100
Victor Stinner wrote:
> 2017-12-06 23:07 GMT+01:00 Antoine Pitrou :
> > One question: how do you plan to test for the POSIX locale?
>
> I'm not sure. I will probably rely on Nick for that ;-) Nick already
> implemented this exact check f
On Thu, 7 Dec 2017 00:22:52 +0100
Victor Stinner wrote:
> 2017-12-06 23:36 GMT+01:00 Antoine Pitrou :
> > Other than that, +1 on the PEP.
>
> Naoki doesn't seem to be confortable with the usage of the
> surrogateescape error handler by default for open(). Are you ok wit
Hi,
On Sun, 10 Dec 2017 19:17:25 +
Tin Tvrtković wrote:
> Hello,
>
> I'm one of the attrs contributors, and the person who initially wrote the
> slots functionality there.
>
> We've given up on returning a new class always since this can conflict with
> certain metaclasses (have you notice
On Sun, 10 Dec 2017 20:47:45 +0100
Antoine Pitrou wrote:
> Hi,
>
> On Sun, 10 Dec 2017 19:17:25 +
> Tin Tvrtković wrote:
> > Hello,
> >
> > I'm one of the attrs contributors, and the person who initially wrote the
> > slots functionality there.
&
On Tue, 12 Dec 2017 10:50:53 +0100
Xavier de Gaye wrote:
> On 12/11/2017 04:14 PM, Victor Stinner wrote:
> > I'm asking for precise hardware specifications since Red Hat may be
> > able to provide one through the https://osci.io/ program.
>
> Is it acceptable to run the arm buildbots only on
Hello,
After debugging a crash on AppVeyor for a submitter's PR
(see https://github.com/python/cpython/pull/4611 ), I came to the
following diagnosis: converting the "atexit" module (which is a
built-in C extension) to PEP 489 multiphase initialization can lead to
its m_traverse function (and pre
On Thu, 14 Dec 2017 17:00:10 +1000
Nick Coghlan wrote:
> On 14 Dec. 2017 9:19 am, "Antoine Pitrou" wrote:
>
>
> Hello,
>
> After debugging a crash on AppVeyor for a submitter's PR
> (see https://github.com/python/cpython/pull/4611 ), I came to the
> foll
Hello,
After noticing that many issues were opened for it and it was lacking
maintenance, I contacted the sqlite3 module's historical author and
maintainer, Gerhard Häring (for the record, Gerhard didn't make any
changes to the sqlite3 module since 2011... and the Python 2-only,
third-party "pysq
On Thu, 14 Dec 2017 15:05:02 +0100
Petr Viktorin wrote:
>
> PEP 489 gives you good defaults, if you use it and avoid global state
> (roughly: C-level mutable static variables), then you should get
> multi-interpreter support for free in simple cases.
> It's also possible to use PyModule_GetStat
On Thu, 14 Dec 2017 16:03:48 -0800
Guido van Rossum wrote:
> A slot is pretty expensive, as *every* class in existence will be another 8
> bytes larger (and possibly more due to malloc rounding).
I'm always surprised by the discussions about class object size.
Even imagining you have 1 classe
I'm not sure what Mail User Agent each of you is using, but it is quite
impossible (here) to make out who is saying what in your latest
messages.
See plain text rendering here:
https://mail.python.org/pipermail/python-dev/2017-December/151274.html
Regards
Antoine.
On Fri, 15 Dec 2017 10:56:28
On Fri, 15 Dec 2017 14:05:46 +0200
Serhiy Storchaka wrote:
> 15.12.17 04:00, Guido van Rossum пише:
> > In the light of Antoine's and Stephan's feedback I think this can be
> > reconsidered -- while I want to take a cautious stance about resource
> > consumption I don't want to stand in the way
On Fri, 15 Dec 2017 19:18:11 +0200
Serhiy Storchaka wrote:
> 15.12.17 18:36, Antoine Pitrou пише:
> > Do you have any general idea how to speed up class creation?
>
> Some work was done in [https://bugs.python.org/issue31336]. Currently I
> have no ideas.
>
> Creati
Hello,
Nowadays we have an official mechanism for third-party C extensions to
be binary-compatible accross feature releases of Python: the stable ABI.
But, for non-stable ABI-using C extensions, there are also mechanisms
in place to *try* and ensure binary compatibility. One of them is the
way
On Sat, 16 Dec 2017 09:34:02 -0800
Guido van Rossum wrote:
> I think it's more acceptable to require matching versions now than it was
> 10 years ago -- people are much more likely to use installer tools like pip
> and conda that can check version compatibility.
>
> I think I'd be okay with dropp
On Sat, 16 Dec 2017 19:37:54 +0100
Antoine Pitrou wrote:
>
> Currently, you can pass a `module_api_version` to PyModule_Create2(),
> but that function is for specialists only :-)
>
> ("""Most uses of this function should be using PyModule_Create()
> instead;
On Sat, 16 Dec 2017 11:42:15 -0800
Guido van Rossum wrote:
>
> If it's only a warning, I worry that if we stop checking the flag bits it
> can cause wild pointer following. This sounds like it would be a potential
> security issue (load a module, ignore the warning, try to use a certain API
> on
On Sun, 17 Dec 2017 14:04:52 +0800
尚辉 wrote:
> Hi, guys
>
> In https://github.com/python/cpython/pull/4904, I made csv.DictReader
> returning regular dict instead of OrderedDict. But this code could break
> existing code that relied on methods like move_to_end() which are present
> in OrderedDict
On Mon, 18 Dec 2017 03:24:05 +0900
INADA Naoki wrote:
> On Mon, Dec 18, 2017 at 12:46 AM, Guido van Rossum wrote:
> > My gut suggests me not to do this (neither here nor in other similar cases).
> > I doubt there's much of a performance benefit anyway.
>
> OrderedDict uses 2x memory than dict
On Sun, 17 Dec 2017 21:07:02 -0500
Random832 wrote:
>
> Is there any practical for of having the flag off for one slot and on
> for another slot that's been added later?
>
> Could this be replaced (that is, a slot for such a thing added before
> it's too late) with a simple counter that goes up
On Tue, 19 Dec 2017 16:10:06 +0100
Petr Viktorin wrote:
> >
> > Speaking of which, the doc is not very clear: is PEP 489 required for
> > multi-interpreter support or is PyModule_GetState() sufficient?
>
> Yes, it is possible to have proper subinterpreter support without
> multi-phase init.
Th
On Tue, 19 Dec 2017 17:32:52 -0800
Nathaniel Smith wrote:
>
> > In any case, there are so many ways
> > to spoil the first point for yourself that it's hardly worth treating as an
> > important constraint.
>
> I guess the underlying issue here is partly the question of what the
> pprint module
Following this discussion, I opened two issues:
* https://bugs.python.org/issue32387: "Disallow untagged C extension
import on major platforms"
* https://bugs.python.org/issue32388: "Remove cross-version binary
compatibility"
Regards
Antoine.
On Sat, 16 Dec 2017 14:22:57
On Wed, 27 Dec 2017 14:19:16 +
Jonathan Underwood wrote:
> Hello,
>
> I am not sure if this is expected behaviour, or a bug.
>
> In a C extension module, if I create and return an empty bytes object like
> this:
>
> val = PyBytes_FromStringAndSize (NULL, 20);
> Py_SIZE(val) = 0;
I
On Wed, 27 Dec 2017 17:28:41 +0100
Antoine Pitrou wrote:
> On Wed, 27 Dec 2017 14:19:16 +
> Jonathan Underwood wrote:
> > Hello,
> >
> > I am not sure if this is expected behaviour, or a bug.
> >
> > In a C extension module, if I create and return
On Fri, 29 Dec 2017 02:23:56 -0800
Ethan Smith wrote:
>
> In a few cases I want to override the repr of the AST nodes. I wrote a
> __repr__ and ran the code but lo and behold I got a type error. I couldn't
> override it. I quickly learned that one needs to pass a keyword to the
> dataclass decora
On Fri, 29 Dec 2017 11:12:11 -0800
Ethan Smith wrote:
>
> > Agreed as well. If I make the effort of having a dataclass inherit
> > from a base class, I probably don't want the base class' methods to be
> > silently overriden by machine-generated methods. Of course, that can
> > be worked around
On Fri, 29 Dec 2017 21:54:46 +0100
Christian Heimes wrote:
>
> On the other hand ssl module is currently completely broken. It converts
> hostnames from bytes to text with 'idna' codec in some places, but not
> in all. The SSLSocket.server_hostname attribute and callback function
> SSLContext.set
Thanks. So the change sounds ok to me.
Regards
Antoine.
On Sat, 30 Dec 2017 14:34:04 +0100
Christian Heimes wrote:
> On 2017-12-30 11:28, Antoine Pitrou wrote:
> > On Fri, 29 Dec 2017 21:54:46 +0100
> > Christian Heimes wrote:
> >>
> >> On the o
On Sat, 30 Dec 2017 23:27:04 -0800
Nathaniel Smith wrote:
>
> We can bikeshed what the new name should be. Maybe set_sni_callback?
> or set_server_hostname_callback, since the corresponding client-mode
> argument is server_hostname?
Or set_idna_servername_callback().
Regards
Antoine.
_
On Mon, 08 Jan 2018 09:11:38 +
Pablo Galindo Salgado wrote:
> Hi,
>
> I'm currently working on exposing posix_spawn in the posix module (and by
> extension in the os module). You can find the initial implementation in
> this PR:
>
> https://github.com/python/cpython/pull/5109
>
> As pointed
On Sat, 13 Jan 2018 13:54:33 +0100
Christian Heimes wrote:
>
> If we agree to drop support for OpenSSL 0.9.8 and 1.0.1, then I can land
> bunch of useful goodies like proper hostname verification [2], proper
> fix for IP address in SNI TLS header [3], PEP 543 compatible Certificate
> and PrivateK
On Sat, 13 Jan 2018 15:49:21 +0100
Christian Heimes wrote:
> On 2018-01-13 14:23, Antoine Pitrou wrote:
> > On Sat, 13 Jan 2018 13:54:33 +0100
> > Christian Heimes wrote:
> >>
> >> If we agree to drop support for OpenSSL 0.9.8 and 1.0.1, then I can land
> &g
On Sat, 13 Jan 2018 19:18:41 +0100
Christian Heimes wrote:
> On 2018-01-13 19:04, Random832 wrote:
> > On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote:
> >> Hi,
> >>
> >> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> >> decade and two days ago for Python 2.6 a
On Sat, 13 Jan 2018 21:06:19 +0100
Christian Heimes wrote:
> >>
> >> I see two option:
> >>
> >> 1) "pip install --user" is no longer supported. You have to learn how to
> >> use virtual envs. It's really easy: "python3 -m venv path; path/bin/pip
> >> install package".
> >> 2) "pip install --user"
On Sat, 13 Jan 2018 23:45:07 +0100
Christian Heimes wrote:
> On 2018-01-13 21:02, Brett Cannon wrote:
> > +1 from me as well for the improved security.
>
> Thanks, Brett!
>
> How should we handle CPython's Travis CI tests? The 14.04 boxes have
> OpenSSL 1.0.1. To the best of my knowledge, Trav
On Tue, 16 Jan 2018 17:44:14 -0500
Yury Selivanov wrote:
> Offloading execution to other threads
> -
>
> It is possible to run code in a separate OS thread using a copy
> of the current thread context::
>
> executor = ThreadPoolExecutor()
> current_co
On Tue, 16 Jan 2018 17:18:06 -0800
Nathaniel Smith wrote:
> On Tue, Jan 16, 2018 at 5:06 PM, Yury Selivanov
> wrote:
> >
> > I think it would be a very fragile thing In practice: if you have even
> > one variable in the context that isn't pickleable, your code that uses
> > a ProcessPool would s
On Wed, 17 Jan 2018 20:53:42 -0500
Yury Selivanov wrote:
>
> Proposed by Antoine Pitrou, this could enable transparent
> cross-process use of ``Context`` objects, so the
> `Offloading execution to other threads`_ example would work with
> a ``ProcessPoolExecutor`` too.
>
On Thu, 18 Jan 2018 22:04:34 -0800
Nathaniel Smith wrote:
> On Thu, Jan 18, 2018 at 12:27 PM, Victor Stinner
> wrote:
> > CPython still has compatibility code for Linux 2.6, whereas the
> > support of Linux 2.6.x ended in August 2011, longer than 6 years ago.
> > Should we also drop support for o
On Thu, 18 Jan 2018 22:04:34 -0800
Nathaniel Smith wrote:
> On Thu, Jan 18, 2018 at 12:27 PM, Victor Stinner
> wrote:
> > CPython still has compatibility code for Linux 2.6, whereas the
> > support of Linux 2.6.x ended in August 2011, longer than 6 years ago.
> > Should we also drop support for
This is missing a bit of context. Is this about python-dev? Some
other ML?
Regards
Antoine.
On Tue, 30 Jan 2018 02:16:14 +
Brett Cannon wrote:
> Over the last 3 days I have had two situations come up where I was asked
> for my opinion in regards to possible CoC violations. I just wanted
On Fri, 2 Feb 2018 16:23:20 +0100
Christian Heimes wrote:
> Hi,
>
> in PR 3854 [1] Serhiy added blowfish, extended DES and NT-Hash to
> Python's crypt mdodule. I vetoed against addition of the APIs because
> all these hashing algorithms are not state of the art. Their quality
> ranges from old to
On Sun, 4 Feb 2018 14:31:06 -0800
Guido van Rossum wrote:
> On Sun, Feb 4, 2018 at 11:59 AM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
>
> > I think the folks that are concerned about this issue are quite right
> > — most Python users equate immutable and hashable—so the dat
On Wed, 21 Feb 2018 01:58:15 +
Brett Cannon wrote:
> It's been a year and 10 days since we moved to GitHub, so I figured now is
> as good a time as any to ask people if they are generally happy with the
> workflow and if there is a particular sticking point to please bring it up
> on the core-
On Wed, 21 Feb 2018 14:19:54 -0800
Barry Warsaw wrote:
> On Feb 21, 2018, at 13:22, Guido van Rossum wrote:
> >
> > I'm willing to reconsider if there's a good enough tool. Ditto for C code
> > (or do we already do it for C?).
>
> For Python code, flake8 --possibly with our own custom plugin
On Thu, 22 Feb 2018 07:51:17 -0800
Steve Dower wrote:
> It then becomes grunt work for reviewers, who also have to carefully balance
> encouraging new contributors against preventing the code base from getting
> worse.
That's a fair point I hadn't considered. OTOH the style issues I
usually co
On Mon, 12 Mar 2018 09:49:27 -0700
Raymond Hettinger wrote:
>
> Starting point: Do we need this?
> * We already have a simple, traditional, portable, and readable way to make
> the test: int(x) == x
It doesn't look that obvious to me. As a reviewer I would request to
add a comment explaining
n.org/dev/peps/pep-0574/
The PEP text is also inlined below.
Regards
Antoine.
PEP: 574
Title: Pickle protocol 5 with out-of-band data
Version: $Revision$
Last-Modified: $Date$
Author: Antoine Pitrou
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 23-Mar-2018
Pos
On Wed, 28 Mar 2018 23:03:08 +0300
Serhiy Storchaka wrote:
> 28.03.18 21:39, Antoine Pitrou пише:
> > I'd like to submit this PEP for discussion. It is quite specialized
> > and the main target audience of the proposed changes is
> > users and authors of applicati
On Thu, 29 Mar 2018 01:40:17 +
Robert Collins wrote:
> >
> > Data sharing
> >
> >
> > If you pickle and then unpickle an object in the same process, passing
> > out-of-band buffer views, then the unpickled object may be backed by the
> > same buffer as the original pickled object.
On Thu, 29 Mar 2018 11:25:13 +
Nathaniel Smith wrote:
>
> > I doubt it'll be a problem to pickle though as it'll use some form of
> > versioning even in NONPORTABLE mode right?
> >
>
> I guess the (merged, but undocumented?) changes in
> https://bugs.python.org/issue28053 should make it po
On Fri, 30 Mar 2018 15:28:47 +0900
INADA Naoki wrote:
> Hi,
>
> As far as I know, most amd64 and arm64 systems use only 48bit address spaces.
> (except [1])
>
> [1]
> https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf
>
> It means there are some chance
On Fri, 30 Mar 2018 15:28:47 +0900
INADA Naoki wrote:
>
> # Possible optimizations by 48bit pointer
>
> ## PyASCIIObject
>
> [snip]
> unsigned int ready:1;
> /* Padding to ensure that PyUnicode_DATA() is always aligned to
>4 bytes (see issue #19537 on m68k). */
>
On Fri, 30 Mar 2018 21:40:21 +0300
Serhiy Storchaka wrote:
> 30.03.18 16:54, Antoine Pitrou пише:
> > We could also simply nuke wstr. I frankly don't think it's very
> > important. It's only used when calling system functions taking a
> > wchar_t argum
On Mon, 2 Apr 2018 13:48:46 -0700
Lukasz Langa wrote:
> Pickle protocol version 4.0 was originally defined back in PEP 3154 and
> shipped as part of Python 3.4 back in 2011. Yet it's still not the default.
Because we want pickles produced with the default to be readable by
earlier Python 3 versi
On Mon, 2 Apr 2018 15:57:11 -0700
Lukasz Langa wrote:
> > On Apr 2, 2018, at 2:13 PM, Antoine Pitrou wrote:
> >
> > On Mon, 2 Apr 2018 13:48:46 -0700
> > Lukasz Langa wrote:
> >> Pickle protocol version 4.0 was originally defined back in PEP 3154 and
> &
On Fri, 6 Apr 2018 17:17:58 -0400
Ned Deily wrote:
> On Apr 6, 2018, at 12:06, Skip Montanaro wrote:
> > [...]
> > https://bugs.python.org/issue27805
> > [...]
> > Any chance of this getting into 3.7 or will a fix have to wait for 3.8
> > at this point? (I'm guessing "no" as I don't see a patch.)
On Sun, 8 Apr 2018 13:17:36 +1000
Nick Coghlan wrote:
> On 6 April 2018 at 14:45, Guido van Rossum wrote:
> > As you may guess from the silence, it may be hard to get a definitive answer
> > to this question -- PEP 384's author has stopped actively participating in
> > the Python community and I'
301 - 400 of 4909 matches
Mail list logo
