On Fri, Apr 8, 2016 at 7:41 PM, Brett Cannon wrote:
>
>
> On Fri, Apr 8, 2016, 16:13 Glenn Linderman wrote:
>>
>> On 4/8/2016 3:28 PM, Eric Snow wrote:
>>
>> All this matters because it impacts the value returned from
>> __ospath__(). Should it retur
On Tue, Apr 19, 2016 at 10:50 AM, Brett Cannon wrote:
> Ah, but you see that doesn't make porting easy. If I have a bunch of
> path-manipulating code using os.path already and I want to add support for
> pathlib I can either (a) rewrite all of that path-manipulating code to work
> using pathlib, o
On Sun, Apr 24, 2016 at 1:20 AM, Xavier de Gaye wrote:
> Starting with API level 21 (Android 5.0), the build of python3 with the
> official android toolchains (that is, without resorting to external
> libraries
> for wide character support) runs correctly. With the set of patches
> described
> in
You should get in touch with Mark Shannon, while you're working on
ceval. He has some definite improvements that can be made to the eval
loop.
-eric
On Sat, Jun 4, 2016 at 2:08 AM, Serhiy Storchaka wrote:
> Following the converting 8-bit bytecode to 16-bit bytecode (wordcode), there
> are other
Definition Namespace
Version: $Revision$
Last-Modified: $Date$
Author: Eric Snow
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 4-Jun-2016
Python-Version: 3.6
Post-History: 7-Jun-2016
Abstract
This PEP changes the default class definition namespace to ``O
On Tue, Jun 7, 2016 at 11:01 AM, Ethan Furman wrote:
> On 06/07/2016 10:51 AM, Eric Snow wrote:
>> Specification
>> =
>
>
>>* types for which `__prepare__()`` returned something other than
>> ``OrderedDict`` (or a subclass) have their ``__de
On Fri, Oct 18, 2013 at 2:59 PM, Antoine Pitrou wrote:
> Is it one stat() call per successful import? Or one stat() call per
> sys.path entry?
It's one per finder (i.e. path entry) where a matching name is in the
directory (per the finder's cache). So it's a pretty uncommon case
with not much ov
On Fri, Oct 11, 2013 at 1:37 PM, Eric Snow wrote:
> Any comments? Usually silence implies no disapproval. ;) PEP 451 did
> go through several rounds of review on import-sig, so I'm not going to
> stress over low feedback at this point. However, I'd particularly
> appre
If anyone is interested in having a (faithful) C implementation of
OrderedDict for the 3.4 release, I have a patch up [1]. My interest
in having the patch applied is relative to proposals that won't apply
to 3.4, so I haven't felt the need to advance the patch. However, in
case anyone else would
On Sun, Oct 20, 2013 at 9:56 PM, Raymond Hettinger
wrote:
> I'll look at this in more detail after I've finishing my review of the
> TransformDict,
> but my initial impression is that the original show stopper hasn't been
> overcome:
> http://bugs.python.org/issue10977
>
> The concrete dict API is
I've had some offline discussion with Brett and Nick about PEP 451
which has led to some meaningful clarifications in the PEP. In the
interest of pulling further discussions back onto this
(archived/public) list, here's an update of what we'd discussed and
where things are at. :)
* path entry fin
On Thu, Oct 24, 2013 at 12:05 AM, Eric Snow wrote:
> * Nick suggested writing a draft patch for the language reference
> changes (the import page). Such a patch will be a pretty good
> indicator of the impact of PEP 451 on the import system and should
> highlight any design flaw
On Thu, Oct 24, 2013 at 6:01 AM, Nick Coghlan wrote:
> On 24 October 2013 16:05, Eric Snow wrote:
>> * I've asserted that there shouldn't be much difficulty in adjusting
>> pkgutil and other modules to work with ModuleSpec.
>
> More specifically: importlib finders
On Fri, Oct 25, 2013 at 9:40 AM, Brett Cannon wrote:
> After reading Eric's doc patch, I realized there is one change I want to
> make to the current semantics and that's not to backfill __package__ when
> set to None. Since import is now going to take over the job of setting
> __package__ (along
On Fri, Oct 25, 2013 at 10:24 AM, PJ Eby wrote:
> I've not really had time to review this PEP yet, but from skimming
> discussion to date, the only thing I'm still worried about is whether
> this will break lazy import schemes that use a module subclass that
> hooks __getattribute__ and calls relo
On Fri, Oct 25, 2013 at 9:44 AM, Eric Snow wrote:
> On Fri, Oct 25, 2013 at 9:40 AM, Brett Cannon wrote:
>> After reading Eric's doc patch, I realized there is one change I want to
>> make to the current semantics and that's not to backfill __package__ when
>> s
On Sat, Oct 26, 2013 at 11:27 AM, Nick Coghlan wrote:
> On 26 October 2013 08:51, PJ Eby wrote:
>> Yeah, it actually was to ensure that you could reload a module using a
>> different loader than the one that originally loaded it, e.g. due to a
>> change in path hooks, etc.
>
> Yeah, the rationale
On Sat, Oct 26, 2013 at 9:44 PM, Nick Coghlan wrote:
> I've been thinking about this, and I've come to the conclusion that:
>
> 1. The old __name__ based behaviour was broken (since __name__ may not
> be the actual module name, as in "__main__" or when a pseudo-module is
> lying about its identity
On Mon, Oct 28, 2013 at 12:45 PM, Victor Stinner
wrote:
> I propose to block importing new modules (or import again unloaded
> modules) during Python finalization to avoid such tricky bugs.
Alternatively, we could set sys.modules[name] to None for each
builtin/frozen module when they get finalize
On Sat, Oct 26, 2013 at 11:03 PM, Nick Coghlan wrote:
> I don't think we can postpone it to later, as we need to be clear on:
>
> 1. Does reload use __name__ or __spec__.name when both are available?
> 2. Does __name__ get restored to its original value if reloading via
> __spec__.name?
> 3. Do ot
On Sun, Oct 27, 2013 at 4:41 PM, PJ Eby wrote:
> I'm talking about userspace code that implements lazy importing
> features, like the lazyModule() function in this module:
>
>http://svn.eby-sarna.com/Importing/peak/util/imports.py?view=markup
>
> Specifically, I'm trying to get an idea of how
On Tue, Oct 29, 2013 at 3:32 AM, Nick Coghlan wrote:
> On 29 Oct 2013 14:45, "Eric Snow" wrote:
>> I'd rather give loaders another optional method:
>> supports_reload(name). Complicating the spec methods signatures (to
>> support passing the old spec
On Tue, Oct 29, 2013 at 7:29 PM, Nick Coghlan wrote:
> OK, time for me to stop trying to remember the details of the problem
> I'm trying to solve and go look them up in the source code :)
>
> One of my goals here is to be able to migrate extension loading from
> the old API to the new plugin API.
On Wed, Oct 30, 2013 at 4:09 PM, Nick Coghlan wrote:
> On 31 Oct 2013 03:41, "Eric Snow" wrote:
>> Our recent discovery about reloading should probably be reflected in
>> the signature of finder.find_spec():
>>
>> MetaPathFinder.fin
On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan wrote:
> There's also the option of implementing the constraint directly in the
> finder, which *does* have the necessary info (with the change to pass the
> previous spec to find_spec).
Yeah, I thought of that. I just prefer the more explicit
suppo
On Thu, Oct 31, 2013 at 4:10 PM, Nick Coghlan wrote:
> However, perhaps it makes more sense to pass the entire existing module,
> rather than just the spec?
Sounds good to me. :)
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
On Fri, Nov 1, 2013 at 7:35 AM, Brett Cannon wrote:
> On Thu, Oct 31, 2013 at 6:10 PM, Nick Coghlan wrote:
>> At the time when find_spec runs, sys.modules hasn't been touched yet, so
>> the old module state is still available when reloading. Passing the spec in
>> lets the loader decide whether o
On Fri, Nov 1, 2013 at 11:59 AM, Brett Cannon wrote:
> Thanks for the clarification. It all SGTM.
I've updated the PEP and the reference implementation. If I've missed
anything please let me know. There is only one thing I thought of
that I'd like to get an opinion on:
In the Finders section,
On Sat, Nov 2, 2013 at 9:38 AM, Nick Coghlan wrote:
> Eric: since "target" was on both Brett's list and mine, it looks like
> s/existing/target/ and clarifying that "incompatible target module"
> should be reported by throwing ImportError from find_spec() will get
> you the pronouncement you're lo
On Mon, Nov 4, 2013 at 3:47 PM, Larry Hastings wrote:
> When Clinic generates a function, it knows what kind of callable it
> represents, and it names the first argument (the "PyObject *") accordingly:
>
> module-level function ("self"),
> method ("self"),
> class method ("cls"), or
> class static
On Nov 5, 2013 10:42 PM, "Nick Coghlan" wrote:
> If the benchmark suite indicates there's no measurable speed penalty then
such a patch may be worth reconsidering. I'd be astonished if that was
actually the case, though - the lowest impact approach I can think of is to
check for live iterators whe
On Wed, Nov 6, 2013 at 11:02 AM, Serhiy Storchaka wrote:
> Actually we should guard not against changing dict during iteration, but
> against iterating modifying dict (and only such modifications which change
> dict's keys).
s/iterating modifying/iteration modifying/ ?
Just to clarify, do you me
On Thu, Nov 7, 2013 at 11:44 AM, Brett Cannon wrote:
> Lazy message creation through
> __str__ does leave the message out of `args`, though.
If that's an issue you could make args a (settable) property that
dynmically returns str(self) if appropriate:
@property
def args(self):
ac
On Thu, Nov 7, 2013 at 4:55 PM, Victor Stinner wrote:
> About the 72523 functions PyRun_xxx(), I don't understand something.
> The PyRun_FileEx() is documented in the Python "very high" C API to
> use Python. But this function is not part of the stable ABI. So there
> is no "very high" function in
I'm pleased to announce that Brett Cannon and Nick Coghlan (the
co-BDFL-delegates) have accepted PEP 451 for inclusion in Python 3.4.
Both of them have contributed substantially to the discussions of the
proposal and have helped make it solid. I'm grateful for their
diligence, attentiveness, and e
While looking at something unrelated, I happened to peek at
Python/frozenmain.c and found Py_FrozenMain(). I kind of get the idea
of it, but am curious what motivated the addition and who might be
using it. The function is not documented and doesn't have much
explanation. I'm guessing that not m
On Sat, Nov 16, 2013 at 10:55 AM, M.-A. Lemburg wrote:
> It's used as main()-function for frozen Python interpreters.
>
> See eGenix PyRun as an example and the freeze tool in Tools/freeze/
> for the implementation that uses this API:
>
> http://www.egenix.com/products/python/PyRun/
On Sat, Nov 1
If you look at the Python and Modules directories in the cpython repo,
you'll find modules in Python/ and core files (like python.c and
main.c) in Modules/. (It's like parking on a driveway and driving on
a parkway. ) It's not that big a deal and not that hard to
figure out (so I'm fine with the
On Sat, Nov 16, 2013 at 11:15 AM, Antoine Pitrou wrote:
>
> Hello,
>
> Alexandre Vassalotti (thanks a lot!) has recently finalized his work on
> the PEP 3154 implementation - pickle protocol 4.
>
> I think it would be good to get the PEP and the implementation accepted
> for 3.4.
+1
Once the cor
On Thu, Nov 21, 2013 at 4:17 PM, Nick Coghlan wrote:
> Skipping saving _source under -OO would probably be a good thing, but
> otherwise it's a public API with the usual backwards compatibility
> guarantees.
One alternative might be to make it a property that re-generates the
source (you just nee
Is there a listing of buildbot categories (3.x.stable, custom-stable,
etc.)? The best I could find was http://python.org/dev/buildbot/. I
couldn't find it at http://buildbot.python.org/ or in the devguide,
both places where I expected to find such a list. Thanks!
-eric
_
The bulk of PEP 451 (all but the "fluffy" parts as Brett called them
) is now committed to default. We are tracking the remaining
items as dependencies of http://bugs.python.org/issue18864.
http://hg.python.org/cpython/rev/07229c6104b1
changeset: 87347:07229c6104b1
user: Eric
On Fri, Nov 22, 2013 at 9:36 AM, Eric Snow wrote:
> The bulk of PEP 451 (all but the "fluffy" parts as Brett called them
> ) is now committed to default.
I'm looking into buildbot failures (on Windows of course).
-eric
___
Py
On Wed, Jan 8, 2014 at 3:40 AM, M.-A. Lemburg wrote:
> PS: The PEP mentions having to code for Python 3.0-3.4 as well,
> which would don't support the new methods. I think it's perfectly
> fine to have newly ported code to require Python 2.7/3.5+. After
> all, the porting effort will take some tim
On Mon, Jan 6, 2014 at 6:24 AM, Victor Stinner wrote:
> Abstract
>
>
> Add ``bytes % args`` operator and ``bytes.format(args)`` method to
> Python 3.5.
>
>
> Rationale
> =
>
> ``bytes % args`` and ``bytes.format(args)`` have been removed in Python
> 2. This operator and this metho
On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith wrote:
> For the first iteration of bytes.format(), I think we should just
> support the exact types of int, float, and bytes. It will call the
> type's__format__ (with the object as "self") and encode the result to
> ASCII. For the stated use case o
On Thu, Jan 16, 2014 at 3:06 PM, Jan Kaliszewski wrote:
> I'd treat the format()+.__format__()+str.format()-"ecosystem" as
> a nice text-data-oriented, *complete* Py3k feature, backported to
> Python 2 to share the benefits of the feature with it as well as
> to make the 2-to-3 transition a bit ea
On Jan 22, 2014 6:17 AM, "M.-A. Lemburg" wrote:
> Using an environment switch the extra checks could even be enabled
> without any code changes.
When Donald brought this up it sounded good. It still does. This is
similar to what we did for hash randomization.
-eric
On Sat, Jan 25, 2014 at 6:28 PM, Antoine Pitrou wrote:
> Is there a reason to have separate "importlib" (toplevel) and
> "importlib.util" namespaces?
As to why they are separate, you'll need to ask Brett. I believe it's
meant to keep the top namespace as small as possible.
Regarding this change
[re: "as" clause]
On Fri, Feb 21, 2014 at 6:20 AM, Nick Coghlan wrote:
> It's probably OK to leave it in the deferred section and just note the
> difficulty of implementing it in a backwards compatible way, since
> we're *not* going to be introducing a closure.
Agreed.
-eric
On Fri, Feb 21, 2014 at 8:12 AM, Chris Angelico wrote:
> On Sat, Feb 22, 2014 at 1:50 AM, Antoine Pitrou wrote:
>> On Sat, 22 Feb 2014 00:28:01 +1000
>> Nick Coghlan wrote:
>>>
>>> Neither of these objections addresses the problems with the status quo,
>>> though:
>>>
>>> - the status quo encou
On Fri, Feb 21, 2014 at 8:19 AM, Brett Cannon wrote:
> I understand you are arguing that a try expression will lead to people just
> doing `something() except Exception: None` or whatever and that people will
> simply get lazy and not think about what they are doing with their
> exceptions.
Exact
On Fri, Feb 21, 2014 at 8:27 AM, Chris Angelico wrote:
> It doesn't need to save a huge number of lines. Just like lambda and
> the if/else expression, it's there as a tool - if it makes your code
> easier to read, it's a good too, and if it makes it harder, then don't
> use it.
And as long as th
On Fri, Feb 21, 2014 at 7:42 AM, Nick Coghlan wrote:
> It's a relatively arcane scoping rule that only matters if you have
> non-trivial logic at class scope. The vast majority of Python
> programmers will never have to care, because they do the typical thing
> and their class bodies consist almos
On Fri, Feb 21, 2014 at 6:06 PM, Jan Kaliszewski wrote:
> 21.02.2014 18:37, Guido van Rossum wrote:
>
>> I'm put off by the ':' syntax myself (it looks to me as if someone
>> forgot a newline somewhere)
>
>
> As I mentioned at python-ideas I believe that parens neutralize,
> at least to some exten
On Fri, Feb 21, 2014 at 6:48 PM, Yury Selivanov wrote:
> This new syntax won't magically fix all the code either.
> But it may let people write code like this:
>
> # I'm sorry, I really can't read this.
>
> logging.info("Message shown to user: %s",((cache[k]
> except LookupError:
>
On Fri, Feb 21, 2014 at 7:07 PM, Victor Stinner
wrote:
>> Consider this example of a two-level cache::
>> for key in sequence:
>> x = (lvl1[key] except KeyError: (lvl2[key] except KeyError: f(key)))
>> # do something with x
>
> ... but I don't like when it is used to build comp
On Wed, Mar 5, 2014 at 2:54 PM, Nick Coghlan wrote:
> Guido had a fix in mind - splitting traceback formatting into two pieces.
> The first would convert a traceback to a sequence of named tuples, the
> second would do the actual string formatting.
+1
This is basically how I've handled pickling
On Mon, Mar 10, 2014 at 8:05 PM, R. David Murray wrote:
> Well, I think What's New for 3.4 is done. I've been through all of the
> NEWS items from the start of 3.4 through the beta1 release.
>
> I'm pretty much out of time for this project since
> Final is almost upon us. I'll be making at least
On Tue, Feb 18, 2014 at 2:09 PM, Terry Reedy wrote:
> I am working through the multiple bugs afflicting tokenize.untokenize, which
> is described in the tokenize doc and has an even longer docstring. While the
> function could be implemented as one 70-line function, it happens to be
> implemented
On Thu, Mar 20, 2014 at 11:56 AM, Larry Hastings wrote:
> On 03/20/2014 12:49 AM, Nick Coghlan wrote:
>
> So long as Graham's willing to go along with it, he doesn't have to to
> be the one to write the PEP.
>
>
> PEP? Why does it need a PEP? I didn't think it'd even be a new top-level
> library
On Wed, Mar 19, 2014 at 12:46 PM, Antoine Pitrou wrote:
> In http://bugs.python.org/issue19359#msg213530 I proposed to introduce a
> "proxy
> protocol" (__proxy__ / tp_proxy) that would be used as a fallback by
> _PyObject_LookupSpecial to fetch the lookup target, i.e.:
>
> def _PyObject_LookupSp
On Mon, Mar 31, 2014 at 1:45 PM, Terry Reedy wrote:
> On 3/31/2014 2:30 PM, Eric Snow wrote:
>> Is this still an open question, Terry?
>
>
> It is not currently for #9974 because after consideration of two proposed
> patches (one part of another issue), I decided that
On Apr 8, 2014 10:31 AM, "MRAB" wrote:
> If the RHS yields too few, e.g. 3, you'll get:
>
> ValueError: attempt to assign sequence of size 3 to extended slice of size 4
>
> If it yields too many, e.g. 10, you'll get:
>
> ValueError: attempt to assign sequence of size 10 to extended slice of size 4
On Thu, Apr 10, 2014 at 12:58 PM, Guido van Rossum wrote:
> On Thu, Apr 10, 2014 at 11:41 AM, Thomas Wouters wrote:
>
>>
>> On Thu, Apr 10, 2014 at 4:24 AM, Kushal Das wrote:
>
>
>>>
>>> There was a small discussion about state of CFFI for standard library
>>> inclusion. Alex and David Beazley a
terkeys",
> undefines "basestring", etc., but only for this file. (I haven't thought
> through all the possibilities or implications - Eric Snow said he was going
> to sprint on this today/tomorrow, so he'll soon have a better idea just what
> can be done.)
&
On Mon, Apr 14, 2014 at 3:51 PM, Brett Cannon wrote:
> It was realized during PyCon that since we are freezing importlib we could
> now consider freezing all the modules to cut out having to stat or read them
> from disk. So for day 1 of the sprints I I decided to hack up a
> proof-of-concept to s
On Tue, Apr 15, 2014 at 1:45 AM, Chris Angelico wrote:
> Specific use-case that I can see: Mercurial. In a git vs hg shoot-out,
> git will usually win on performance, and hg is using Py2; migrating hg
> to Py3 will (if I understand the above figures correctly) widen that
> gap, so any improvement
On Sat, Apr 19, 2014 at 4:56 PM, Barry Warsaw wrote:
> On Apr 19, 2014, at 02:12 PM, Giampaolo Rodola' wrote:
>
>>I don't see this as a key porting hassle *at all* and I don't understand
>>why they think this would significantly help their porting (it wouldn't).
>>The only real barrier is the str/
On Tue, Apr 29, 2014 at 8:02 PM, Nikolaus Rath wrote:
>
> Hello,
>
> I've just run the testsuite of hg tip with
>
> ./python -m test -u network,urlfetch -j 8 -G -v
"failfast" (from -G) is passed directly to unittest.TextTestRunner
(see test/support/__init__.py:_run_suite()). However, that's on a
On Sun, May 11, 2014 at 7:57 AM, Steve Dower wrote:
> For those who missed the earlier discussions, Martin v. Löwis has handed
> over responsibility for the Windows installers. It sounds like Brett Cannon
> and I are both in a position to build 2.7 right now, and I hope to simplify
> the setup req
On Mon, May 12, 2014 at 12:43 PM, R. David Murray wrote:
> These changes appear to have caused several builbot failures, and
> there doesn't appear to be a bugs.python.org issue to report it to.
> One failure example:
>
>
> http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.4/buil
Thanks for for putting this together.
On Wed, May 28, 2014 at 4:26 PM, Glyph Lefkowitz
wrote:
> At the language summit, Alex and I volunteered to put together some
> recommendations on what changes could be made to Python (the language) in
> order to facilitate a smoother transition from Python 2
Good catch. I'll look into it.
-eric
On Thu, May 29, 2014 at 8:49 AM, Brett Cannon wrote:
> I think the memory leak was caused by
> http://hg.python.org/cpython/rev/7d20e30bd540 because
> http://hg.python.org/cpython/file/0eedac3d0b0a/Python/import.c#l903 sets the
> 'res' variable and then over
Fixed! (test_site and test_functools are still leaking sporadically,
but it looks unrelated to the import.c leak).
-eric
On Thu, May 29, 2014 at 10:34 AM, Eric Snow wrote:
> Good catch. I'll look into it.
>
> -eric
>
> On Thu, May 29, 2014 at 8:49 AM, Brett Cannon w
On Fri, May 30, 2014 at 12:55 PM, brett.cannon
wrote:
> http://hg.python.org/cpython/rev/b26d021081d2
> changeset: 90915:b26d021081d2
> parent: 90913:69011f6ce573
> user:Brett Cannon
> date:Fri May 30 14:55:29 2014 -0400
> summary:
> Issue #20383: Introduce importlib.util
On Wed, Jun 4, 2014 at 3:14 PM, Paul Sokolovsky wrote:
> That said, and unlike previous attempts to develop a small Python
> implementations (which of course existed), we're striving to be exactly
> a Python language implementation, not a Python-like language
> implementation. As there's no formal
On Wed, Jun 4, 2014 at 5:11 PM, Paul Sokolovsky wrote:
> On Wed, 4 Jun 2014 16:12:23 -0600
> Eric Snow wrote:
>> Actually, there is a "formal, implementation-independent language
>> spec":
>>
>> https://docs.python.org/3/reference/
>
> Opening tha
On Fri, Jun 20, 2014 at 2:32 PM, Philip Jenvey wrote:
> =
> PyPy3 2.3.1 - Fulcrum
> =
>
> We're pleased to announce the first stable release of PyPy3. PyPy3
> targets Python 3 (3.2.5) compatibility.
Awesome!
-eric
__
On Wed, Jun 27, 2018 at 7:05 PM Ned Deily wrote:
> On behalf of the Python development community and the Python 3.7 release
> team, we are pleased to announce the availability of Python 3.7.0.
Thanks, Ned (and everyone), for a great job on this release! And
thanks to all for yet another great Py
On Wed, Jul 18, 2018 at 3:16 PM Barry Warsaw wrote:
> On Jul 18, 2018, at 13:54, Victor Stinner wrote:
> > Last May, we worked hard to fix many random test failures on all CIs
> > before Python 3.7 final release.
>
> Thank you thank you thank you Victor for work on keeping the buildbots happy!
Y
On Tue, Jul 31, 2018 at 7:35 AM Victor Stinner wrote:
> 2018-07-31 14:01 GMT+02:00 Jeroen Demeyer :
> > Anyway, I know that this is probably not going to happen, but I just wanted
> > to bring it up in case people would find it a great idea. But maybe not many
> > CPython core developers actually
On Tue, Jul 31, 2018 at 4:15 PM Victor Stinner wrote:
> I finished my work on the _PyCoreConfig structure:
\o/
Thanks for all the good work!
> Right now, the new API is still private. Nick Coghlan splitted the
> initialization in two parts: "core" and "main". I'm not sure that this
> split is n
On Thu, Aug 2, 2018 at 3:50 AM Victor Stinner wrote:
> I'm still doing further bug fixes and cleanup in the master branch:
> https://bugs.python.org/issue34170
>
> I'm doing more and more changes.
Yeah, it's a question of what you plan to backport. As Barry
suggested, it would be great if you ha
Before I dive in, I'll say that I'd really like to hear Nick's opinion
on all this. :)
On Thu, Aug 2, 2018 at 9:59 AM Victor Stinner wrote:
> 2018-08-02 1:18 GMT+02:00 Eric Snow :
> > The "core" config is basically the config for the runtime. In fact,
>
On Sun, Sep 9, 2018, 14:19 Jacqueline Kazil wrote:
> The PSF has received a few inquiries asking the question — “How do I cite
> Python?”So, I am reaching out to you all to figure this out.
>
> (For those that don’t know my background, I have been in academia for a
> bit as a Ph.D student and hav
Hi all,
I've got a pretty good sense of how signal handling works in the
runtime (i.e. via a dance with the eval loop), but still have some
questions:
1. Why do we restrict calls to signal.signal() to the main thread?
2. Why must signal handlers run in the main thread?
3. Why does signal handling
On Fri, Sep 21, 2018 at 5:11 PM Victor Stinner wrote:
> Le sam. 22 sept. 2018 à 01:05, Eric Snow a
> écrit :
> > 3. Why does signal handling operate via the "pending calls" machinery
> > and not distinctly?
>
> Signals can be received anytime, between two
On Mon, Sep 24, 2018 at 11:14 AM Yury Selivanov wrote:
> On Fri, Sep 21, 2018 at 7:04 PM Eric Snow wrote:
> > 1. Why do we restrict calls to signal.signal() to the main thread?
> > 2. Why must signal handlers run in the main thread?
> > 3. Why does signal handling operate v
On Mon, Sep 24, 2018 at 3:10 PM Yury Selivanov wrote:
> On Mon, Sep 24, 2018 at 4:19 PM Eric Snow wrote:
> > This matters to me because I'd like to use "pending" calls for
> > subinterpreters, which means dealing with signals *in*
> > Py_MakePending
On Tue, Sep 25, 2018 at 1:45 AM Victor Stinner wrote:
> Please don't rely on this ugly API. *By design*, Py_AddPendingCall()
> tries 100 times to acquire the lock: if it fails to acquire the lock,
> it does notthing... your callback is ignored...
Yeah, there are issues with pending calls as imple
On Tue, Sep 25, 2018 at 8:30 AM Barry Warsaw wrote:
> On Sep 25, 2018, at 10:18, Antoine Pitrou wrote:
> > Putting them in the C API documentation risks making the docs harder to
> > browse through for third-party users. I think it's enough if there's a
> > comment in the .h file explaining the
On Tue, Sep 25, 2018 at 9:16 AM Yury Selivanov wrote:
> We already have a mechanism for private header files: the
> "Include/internal/" directory. I think it should be mandatory to
> always put private C API-like functions/structs there.
+1
This is the main reason I created that directory. (Vic
On Tue, Sep 25, 2018 at 9:30 AM Gregory P. Smith wrote:
> We can't change the API of the main thread being where signal handlers are
> executed by default.
>
> If a signal handler raised an exception in a daemon thread, the process would
> not die when it goes uncaught (ie: why KeyboardInterrupt w
On Sun, Oct 28, 2018 at 10:20 AM Victor Stinner wrote:
> Python C API has no strict separation between the 3 levels of API:
>
> * core: Py_BUILD_CORE define
> * stable: Py_LIMITED_API define (it has a value)
> * regular: no define
>
> IMHO the current design of header files is done backward: by de
ssue. I tried to convert
> _PyObject_GC_TRACK() macro to a static inline function. The macro uses
> "_PyGC_generation0" which is defined earlier as: "extern PyGC_Head
> *_PyGC_generation0;". Problem: this symbol has been removed when Eric
> Snow moved it int
On Wed, Oct 31, 2018 at 1:57 PM Victor Stinner wrote:
>
> Ok, I proposed to rename internal header files, add an "internal_"
> prefix, to avoid this issue:
> https://github.com/python/cpython/pull/10263
>
> My PR also adds Include/internal/ to search paths of header files.
>
> Extract of the chang
On Wed, Oct 31, 2018 at 2:05 PM Victor Stinner wrote:
>
> Le mer. 31 oct. 2018 à 20:40, Eric Snow a écrit
> :
> > On Mon, Oct 29, 2018 at 6:39 AM Victor Stinner wrote:
> > > Le lun. 29 oct. 2018 à 06:32, Benjamin Peterson a
> > > écrit :
> > &g
B
On Wed, Oct 31, 2018 at 4:28 PM Victor Stinner wrote:
>
> Le mer. 31 oct. 2018 à 22:19, Eric Snow a écrit
> :
> > > Maybe we can keep "Include/internal/" directory name, but add
> > > "pycore_" rather than "internal_" to header filen
hamt.h -> pycore_hamt.h
> * hash.h -> pycore_hash.h
> * mem.h -> pycore_mem.h
> * pystate.h -> pycore_state.h
> * warnings.h -> pycore_warnings.h
>
> * PCbuild project, Makefile.pre.in, Modules/Setup: add the
> Include/internal/ directory to the search paths o
101 - 200 of 572 matches
Mail list logo
