PEP 422 through __autodecorate__, while
PEP 487 currently has no equivalent mechanism.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/
t someone being in a position to
contribute the time to start figuring it out.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinf
if it may be possible to reach out to
the pylint authors (similar to what Brett did for the "pylint --py3k"
flag) and ask for a way to make it easy to register "base class,
decorator" pairs where pylint will complain if it sees a particular
method decorator but can't determine at
rticular feature of DecoratorTools) to Python 3. So I went to check
> on PEP 422's status, and here we are.
Given my change of heart, I believe that at this point, if you were
willing to champion a revived PEP 422 that implemented the behaviour
you're after, th
On 3 April 2015 at 18:21, Nick Coghlan wrote:
> That means I'm now OK with monkeypatching __build_class__ being the
> only way to get dynamic hooking of the class currently being defined
> from the class body - folks that really want that behaviour can
> monkeypatch it in, while
On 4 Apr 2015 00:29, "Martin Teichmann" wrote:
>
> > When I first wrote PEP 422 I was of the view that "Python 2 allows
> > class definition postprocessing injection, we should allow it in
> > Python 3 as well". I've since changed my view to "Having to declare
> > post-processing of a class defini
On 4 April 2015 at 06:36, PJ Eby wrote:
> On Fri, Apr 3, 2015 at 4:21 AM, Nick Coghlan wrote:
>> No, you can't do it currently without risking a backwards
>> incompatibility through the introduction of a custom metaclass.
>
> Right... which is precisely why I
ingle class, but throw an exception if you try to register the same
instance with a second class without removing it from the old one
first).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Pytho
On 7 Apr 2015 03:43, "Neil Girdhar" wrote:
>
> Hello,
>
> Following up with PEP 448, I've gone over the entire code review except
a few points as mentioned at the issue: http://bugs.python.org/review/2292/.
I'm hoping that this will get done at the PyCon sprints. Is there any way
I can help?
>
>
(and hence ctypes) are notable exceptions to
that :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 20 Apr 2015 14:44, "Barry Warsaw" wrote:
>
> On Apr 20, 2015, at 07:30 PM, Harry Percival wrote:
>
> >tldr; type hints in python source are scary. Would reserving them for
stub
> >files be better?
>
> I think so. I think PEP 8 should require stub files for stdlib modules
and
> strongly encoura
f
practicality, we each get to decide whether or not we're OK with just
pushing a particular change and relying on the buildbots and
post-commit review.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
ng all sorts of things to
> accommodate for a new metadata struct is way too cumbersome and ugly in
> comparison.
Sorry for the delayed reply (post-PyCon travel), but +1 from me as
well for the reasons Stefan gives.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Aus
uot;s: accept={...,NoneType}"
My other question would be whether we can use "None" in preference to
NoneType, as PEP 484 does:
https://www.python.org/dev/peps/pep-0484/#using-none
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 25 April 2015 at 14:44, Nick Coghlan wrote:
> On 22 April 2015 at 03:31, Larry Hastings wrote:
>>
>> On 04/21/2015 04:50 AM, Tal Einat wrote:
>>
>> As for the default set of accepted types for various convertors, if we
>> could choose any syntax we liked,
ealing to me. If anyone doesn't want to deal
with type hints themselves, but has a contributor that really wants to
annotate their library, then "take it to typeshed" will hopefully
become a recurring refrain :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane,
ot;anything except a tuple literal" as the
subexpression after the await keyword, so it will likely still need
special case handling in the affected statements in order to avoid
"await a, b" being interpreted as waiting for a tuple.
Cheers,
Nick.
--
Nick Coghlan | ncogh.
nk of a concise and unambiguous name
> for it, it's probably a bad idea".)
I think "async function" is fine - "async function" is to "coroutine"
as "function" is to "callable".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
On 25 April 2015 at 17:58, Larry Hastings wrote:
>
> On 04/24/2015 09:45 PM, Nick Coghlan wrote:
>
> Ah, I misread Tal's suggestion. Using unary + is an even neater approach.
>
>
> Not exactly. The way I figure it, the best way to achieve this with unary
> p
(await a(), b)
I think it's OK if these end up requiring parentheses in order to do
the right thing (as that will be helpful for humans regardless), but
the PEP should be clear as to whether or not they do:
res = (await a()), b()
res = [(await a()), b()]
with (await a()), b: pass
On 27 Apr 2015 07:50, "Mark Shannon" wrote:
> On 26/04/15 21:40, Yury Selivanov wrote:
>>
>> But it's hard. Iterating through something asynchronously? Write a
>> 'while True' loop. Instead of 1 line you now have 5 or 6. Want to
>> commit your database transaction? Instead of 'async with' you
am aware, we don't have the equivalent of a "coding
cookie" for the interactive interpreter, so if anyone else knows how
to do it, I'll be learning something too :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
disable certificate verification (hence the change
to the example code)
* new paragraph making it explicit that even though we've improved
Python's default behaviour, particularly security sensitive
applications should still provide their own context rather than
relying on the defa
ected ways.
We have a defined process for introducing new keywords (i.e.
__future__ imports) and the PEP doesn't adequately make the case for
why we shouldn't use it here.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
nchronous code still has an important role
to play as one of the 3 models (together with thread pools and
blocking on the event loop while running a coroutine to completion)
that lets synchronous code play nice with asynchronous code:
http://python-notes.curiousefficiency.org/en/latest/pep_idea
On 30 April 2015 at 11:12, Guido van Rossum wrote:
> On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan wrote:
>> It is also makes things more painful than they need to be for syntax
>> highlighters.
>
> Does it? Do highlighters even understand __future__ imports? I wouldn'
On 30 April 2015 at 12:31, Guido van Rossum wrote:
> On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan wrote:
>>
>> [...]
>> Yeah, I'm coming around to the idea. For the async pseudo-keyword, I
>> can see that the proposal only allows its use in cases that were
>
On 30 Apr 2015 5:59 pm, "M.-A. Lemburg" wrote:
> On 30.04.2015 02:33, Nick Coghlan wrote:
> > Hi folks,
> >
> > This is just a note to highlight the fact that I tweaked the "Opting
> > out" section in PEP 476 based on various discussio
e multitasking, threads & processes for preemptive
multitasking, and yield & yield from for iteration", rather than
having the "cooperative multitasking" case continue to be a particular
way of using yield & yield from as it is in Python 3.4 (and a way of
use "yield" in e
On 8 May 2015 6:52 pm, "M.-A. Lemburg" wrote:
>
> On 07.05.2015 04:30, Nick Coghlan wrote:
> >> Can we please make the monkeypatch a regular part of Python's
> >> site.py which can enabled via an environment variable, say
> >> export PYTHONHTT
ity tools (most obviously file system permissions,
but also other systems like SELinux & AppArmor) to bear on controlling who
(and what) has permission to change the default security settings.
Cheers,
Nick.
>
> Regards
>
> Antoine.
>
>
>
> On Fri, 08 May 2015 12:13:5
On 8 May 2015 8:14 pm, "M.-A. Lemburg" wrote:
>
> On 08.05.2015 11:36, Nick Coghlan wrote:
> > On 8 May 2015 6:52 pm, "M.-A. Lemburg" wrote:
> >>
> >> On 07.05.2015 04:30, Nick Coghlan wrote:
> >>>> Can we please make the monkey
ing together a PEP to that effect, so given this
discussion, I'll go ahead and do that myself, with Robert Kuska listed
as co-author (since he came up with the general design I'm advocating
for).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Austra
working on the
Windows installer changes, and several of our other Windows folks
aren't C programmers.
PEP 432 (the interpreter startup sequence improvements) will be back
on the agenda for Python 3.6, so the 3.6 time frame seems more
plausible at this point.
Cheers,
Nick.
--
Nick Coghl
moother migration path to the more hardened
configuration.
I've now written a draft "recommendations to redistributors" PEP for
Robert's configuration file based design:
https://www.python.org/dev/peps/pep-0493/ (exact file names & config
setting names TBD)
I wouldn't
On 11 May 2015 at 19:22, M.-A. Lemburg wrote:
> On 11.05.2015 11:13, Nick Coghlan wrote:
>> I wouldn't be opposed to seeing that as an upstream Python 2.7.x
>> feature, but agreement amongst redistributors on using a file-based
>> approach is the main outcome I'm
On 11 May 2015 at 20:23, Donald Stufft wrote:
> On May 11, 2015, at 6:15 AM, Nick Coghlan wrote:
>> We made the decision when PEP 476 was accepted that this change turned
>> a silent security failure into a noisy one, rather than being a
>> regression in its own right
On 11 May 2015 10:16 pm, "Robert Kuska" wrote:
> > >
> >
> > Oh, another issue that I forgot to mention--
> >
> > A fair number of people had no idea that Python wasn't validating TLS
before
> > 2.7.9/3.4.3 however as part of the processing of changing that in 2.7.9
a lot
> > of people became awa
On 12 May 2015 at 04:49, M.-A. Lemburg wrote:
> On 11.05.2015 12:15, Nick Coghlan wrote:
>> By contrast, the configuration file shouldn't provide a new attack
>> vector (or simplify any existing attack vector), as if you have the
>> permissions needed to modify the co
On 12 May 2015 at 06:38, Glenn Linderman wrote:
> On 5/11/2015 1:09 AM, Nick Coghlan wrote:
> On 10 May 2015 at 23:28, Adam Bartoš wrote:
> I'd love to see it included in 3.5, but I doubt that will happen. For one
> thing, it's only two weeks till beta 1, which is feat
ations rather than importing them via sys.path.
It won't come to that, as Linux system package managers don't support
any of these - that's what containers are for.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
nd the eGenix design, since we cover two different
use cases) still adopt that same basic implementation model, they just
provide ways for redistributors to move the configuration inside the
SSL module itself if they decide it is in their users' interests for
them to do so.
Cheers,
Nick.
--
Nic
9+ on a per-application basis, *without* modifying
the applications.
Both of those make sense to me as cases where the environment variable
based security downgrade approach is the "least bad" answer available,
which is why I eventually agreed it should be one of the
recommendations in the
On 12 May 2015 at 21:17, Nick Coghlan wrote:
> Both of those make sense to me as cases where the environment variable
> based security downgrade approach is the "least bad" answer available,
> which is why I eventually agreed it should be one of the
> recommendations in the
On 12 May 2015 at 21:21, Donald Stufft wrote:
>
>> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote:
>>
>> On 12 May 2015 at 21:09, Donald Stufft wrote:
>>> If you control the app you don't need to do that. All relevant api accept
>>> the context p
On 12 May 2015 at 21:45, Donald Stufft wrote:
>
>> On May 12, 2015, at 7:40 AM, Nick Coghlan wrote:
>>
>> On 12 May 2015 at 21:21, Donald Stufft wrote:
>>>
>>>> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote:
>>>>
>>>> On 12
On 13 May 2015 03:47, "Brett Cannon" wrote:
>
>
>
> On Tue, May 12, 2015 at 1:05 PM Larry Hastings wrote:
>>
>> [SNIP]
>>
>>
>> What do you think? My votes are as follows:
>>>
>>> Workflow 0: -0.5
>>> Workflow 1: +1
>>> Workflow 2: +0.5
>>
>>
>> Please cast your votes,
>
>
> Workflow 0: -0
> Wor
e TransformDict idea sounded interesting when
Antoine proposed it, but Raymond's rationale for the rejection makes a
great deal of sense.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Py
tations of the latter for the standard
library sequence types implemented in C to return NotImplemented
rather than throwing TypeError directly.
However, my intermittent attempts to get anyone else interested in
fixing it haven't borne any fruit, and I've prioritised other projects
over
tuple, etc. work, and PyPy
> and friends need to match...
No, CPython is broken.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
anguage specification, so that other interpreters can implement it up
front, rather than all having to come up with their own independent
custom hacks just to make NumPy work.
Regards,
Nick.
P.S. It would also be nice if someone could take on the PEP for a
Python level buffer API for 3.6: http:
implicitly manage the
execution context for threads and generators and how event loops
(including asyncio as the reference implementation) are going to be
expected to manage the execution context explicitly when scheduling
coroutines.
Cheers,
Nick.
--
Nick Cog
ally checking in calls
to breakpoint() won' t hang CI systems.
Then folks that wanted to use the functionality would set
"PYTHONBREAKPOINTHOOK=pdb:set_trace"
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
reg gives (while Fedora doesn't
currently do any per-file build artifact caching, I hope we will in
the future, and output formats based on input artifact hashes will
make that much easier than formats based on input timestamps).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
On 7 September 2017 at 19:17, Barry Warsaw wrote:
> On Sep 7, 2017, at 18:12, Nick Coghlan wrote:
>>
>> Related to this is the suggestion that we make the default
>> sys.breakpointhook() a no-op, so that accidentally checking in calls
>> to breakpoint() won' t h
FL-Delegate that this
proposal is now accepted :)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
On 8 September 2017 at 03:04, Antoine Pitrou wrote:
> On Thu, 7 Sep 2017 18:47:20 -0700
> Nick Coghlan wrote:
>> However, I do wonder whether we could encode *all* the mode settings
>> into the magic number, such that we did something like reserving the
>> top
ey can mess with PYTHONIOENCODING,
PYTHONPATH, LD_PRELOAD, OpenSSL certificate verification settings, and
more).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail
On 8 September 2017 at 07:55, Antoine Pitrou wrote:
> On Fri, 8 Sep 2017 07:49:46 -0700
> Nick Coghlan wrote:
>> > I'd rather a single magic number and a separate bitfield that tells
>> > what the header encodes exactly. We don't *have* to fight for a tin
I did not come up with the idea for this PEP while other people
> were having nightmares.
I dunno, debugging finalizer re-entrancy problems seems pretty
nightmarish to me ;)
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python
hat the pyc file was
compiled with this alternative behaviour. While that wouldn't be
needed for import, it would be useful for anyone trying to confirm
that the pyc file actually matches the corresponding source file.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Bri
s
part of the PEP 539 implementation (and we'll get Eric Snow to be one
of the PR reviewers).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
idered part of the instance value for a
data class, so if you do:
@dataclass
class BaseItem:
value: Any
class DerivedItem:
pass
Then instances of DerivedItem *won't* be considered equivalent to
instances of BaseItem, and they also won't be orderable relative to
ea
t want to ensure signals don't run at arbitrary
points in their code are already free to push all their application
logic into a subthread and have the main thread be purely a signal
handling thread.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisb
bytes-out.
Such a memoryview based primitive can then potentially be expanded in
the future to support additional more-efficient-than-multiprocessing
serailisation based protocols, where the sending interpreter
serialises into a region of memory, shares that region with the
subinterpreter via a
On 10 September 2017 at 03:54, Nathaniel Smith wrote:
> On Sep 9, 2017 9:07 AM, "Nick Coghlan" wrote:
>
>
> To immediately realise some level of efficiency benefits from the
> shared memory space between the main interpreter and subinterpreters,
> I also think the
ps including a full rendered traceback), but the exception
itself won't be able to be propagated.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
reviewed at least one previous iteration of it, so I'll let
Stephen know I'll be happy to help out this time as well. (It would be
highly desirable to have more than just me looking at it, though!)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmai
em the capability solves in the simplest possible terms than we
will if we choose something that more accurately describes how it is
implemented.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing lis
it should be queried
lazily regardless of whether it's the builtin or the default hook that
checks it.
I think it would be reasonable for the default hook to cache the
result of PYTHONBREAKPOINT on the first lookup and then not check it
again on future calls, though.
Cheers,
Nick.
--
Nick Cogh
ollections module.
Data classes are things you're likely to put *in* a collection, rather
than really being collections themselves (they're only collections in
the same sense that all Python classes are collections of attributes,
and that's not the way
f (using Mailbox_pend), or else wait on the
underlying events directly.
It seems to me that a similar model would work here (and wouldn't
necessarily need to be included in the initial version of the PEP): a
SendPipe could accept an optional Event object that it calls set() on
when the pipe ce
k objects there that you aren't using
> any more.
>
> Solutions include:
>
> * a ``create()`` arg to indicate resetting ``__main__`` after each
> ``run`` call
> * an ``Interpreter.reset_main`` flag to support opting in or out
> after the fact
> * an ``Inter
On 14 September 2017 at 15:27, Nathaniel Smith wrote:
> On Sep 13, 2017 9:01 PM, "Nick Coghlan" wrote:
>
> On 14 September 2017 at 11:44, Eric Snow
> wrote:
>>send(obj):
>>
>>Send the object to the receiving end of the channel. Wait until
&
On 15 September 2017 at 02:56, Mike Miller wrote:
>
> On 2017-09-12 19:09, Nick Coghlan wrote:
>>
>> On 13 September 2017 at 02:01, Chris Barker - NOAA Federal
>> wrote:
>>>
>>> This really does match well with the record concept in databases, and
On 15 September 2017 at 12:04, Nathaniel Smith wrote:
> On Thu, Sep 14, 2017 at 5:44 PM, Nick Coghlan wrote:
>> The reason we're OK with this is that it means that only reading a new
>> message from a channel (i.e creating a cross-interpreter view) or
>> discarding a pr
ce), and we probably want to
change that condition to be "the main thread in the main interpreter".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
idered in PEP 541:
https://www.python.org/dev/peps/pep-0541/#invalid-projects
Getting PEP 541 accepted will likely make it easier to start scaling
the ticket review team for PyPI (with both paid and volunteer
efforts), and that's currently with Donald for review as an initial
policy that we ca
do if he'd changed his mind on the topic since 2004
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
; automatically clear all locals on frames when they have finished
> executing. It could be a thread-local setting (or, better, a PEP 550
> context variable setting).
I wonder if it might be reasonable to have tracebacks only hold a weak
reference to their
On 18 September 2017 at 20:18, Victor Stinner wrote:
> 2017-09-18 12:07 GMT+02:00 Nick Coghlan :
>> I wonder if it might be reasonable to have tracebacks only hold a weak
>> reference to their frame objects when "__debug__ == False".
>
> Please don't chan
On 18 September 2017 at 20:52, Antoine Pitrou wrote:
> On Mon, 18 Sep 2017 20:35:02 +1000
> Nick Coghlan wrote:
>> Rather than being thread local or context local state, whether or not
>> to keep the full frames in the traceback could be a yet another
>> setting o
an
interpreter-specific reference to a common underlying sync primitive.
>> Unfortunately while technically you can construct a buffered channel
>> out of an unbuffered channel, the construction's pretty unreasonable
>> (it needs two dedicated threads per channel).
>
>
he responsibility of not messing up the frame
stack.
Cheers,
Nick.
[1] See https://bugs.python.org/issue29988 if you're interested in the
gory details
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
P
ne numbers simply weren't relevant to my use case (injecting
inconveniently timed exceptions), so I never checked whether or not
f_lineno was accurate when the trace event was emitted.
So yeah, a follow-up bug report and PR to fix that would be
appreciated (no need for a NEWS entry, since it
ipts
and other startup-sensitive operations that will include an "import
requests", but *not* directly import any of the other modules in its
dependency tree, so "What requests uses" can identify a useful set of
avoidable imports. A Flask "Hello world" app could likely pr
at's mod_wsgi, uWSGI, gunicorn,
Twisted, tornado, or something else) that can choose to adjust *their*
defaults to force the underlying language runtime into an "eager state
initialisation" mode, even if the default setting is to respect
requests for lazy initialisation.
Cheers,
Nic
takes longer than it otherwise for full support for new interfaces to
ripple out through various object proxying libraries (especially for
hard-to-proxy protocols like the new asynchronous ones that require
particular methods to be defined as coroutines).
Cheers,
Nick.
--
Nick Coghlan |
ache
coherency guarantees provided by the GIL).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
On 4 October 2017 at 20:22, Koos Zevenhoven wrote:
> On Wed, Oct 4, 2017 at 8:07 AM, Nick Coghlan wrote:
>>
>> On 3 October 2017 at 03:13, Koos Zevenhoven wrote:
>> > Well, it's not completely unrelated to that. The problem I'm talking
>> > about
>
On 4 October 2017 at 22:45, Koos Zevenhoven wrote:
> On Wed, Oct 4, 2017 at 3:33 PM, Nick Coghlan wrote:
>> That's not a backwards compatibility problem, because the only way to
>> encounter it is to update your code to rely on the new extended
>> protocol - your *exist
On 4 October 2017 at 23:51, Eric Snow wrote:
> On Tue, Oct 3, 2017 at 11:36 PM, Nick Coghlan wrote:
>> The problem relates to the fact that there aren't any memory barriers
>> around CPython's INCREF operations (they're implemented as an ordinary
>> C post-
ou don't need to rely on -E or -I
when running your tests.
That said, it may also be worth considering a "-X nobreakpoints"
option (and then -I could imply "-E -s -X nobreakpoints").
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Austra
s *shouldn't*
be implemented as memoryview subclasses, but instead defined as
*containing* a managed view of an object owned by a different interpreter.
That way, even if the initial implementation only supported CIVs that
contained a memoryview instance, we'
alid opcode set for each CPython feature release
- any other version dependent variations (e.g. the expected stack layout
for BUILD_MAP changed in Python 3.5, when the evaluation order for dict
displays was updated to be key then value, rather than the other way around)
Chee
ong lists of items, so such a field would ideally be based on a combo-box
with typeahead support. (We have something like that already for the nosy
list, where the typeahead support checks for Experts Index entries)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
554 my goal is to find a solution for object
> sharing that keeps things simple in Python while laying a basic
> foundation we can build on at the C level, so we don't get locked in
> but still maximize our opportunities to experiment. :)
>
I think our p
thread by default? I
> think this would make things simpler and leave more freedom regarding the
> implementation in the future. If you need to run an interpreter within the
> current thread, you could perhaps optionally do that too.
>
Not really, as that approach doesn't compose as
uot;MainThread" object to be mapped to different OS
level threads at different points in time, which means it's easier to
combine with existing constructs for managing OS level thread pools).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
P.S. I'll grant that this reasoning doesn't entirely mesh with the naming
of "Abstract Base Class", but that phrase at least explicitly has the word
"base" in it, suggesting that inheritance is involved in the way it works.
--
Nick Coghlan | ncogh...@gmail.com
301 - 400 of 6587 matches
Mail list logo
