On 12 October 2017 at 14:49, Mike Miller wrote:
>
> On 2017-10-11 19:56, Nick Coghlan wrote:
>
>> From my perspective, the main benefit of a compound name like "data
>> class" is that it emphasises a deliberate behavioural choice (adopted from
>> attrs):
lt values, but that's a real conflict, as you'd be trying to use the
same name on the class object for both the slot descriptor and the default
value)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailin
pattern extraction from cases where people have decided the feature was
valuable enough to be worth the hassle of maintaining a custom metaclass.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Pytho
hod in the class body using the zero-arg
super() form (when cls.__classcell__ is non-None), and either issue a
warning or fail outright (since methods that rely on cooperative multiple
inheritance need a specific defining class or else the runtime parent
resolution gets inconsistent).
Cheers,
Nick.
_" and
"mcl.__prepare__/bases.__prepare_subclass__".
OTOH, if you have multiple bases with competing __prepare__ methods you
really *should* get a metaclass conflict, since the class body can only be
executed in one namespace.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
lly undefined in 3.7, I think that's reasonable -
folks that want to ensure the current behaviour indefinitely should keep
using thread locals rather than switching over to context variables.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
nted to do something different (like capturing the context at the point
where iterator was created and then temporarily switching back to that on
each iteration).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python
strong
intuition about how it should work, then instead of attempting to guess
suitable semantics, we can instead define it as raising RuntimeError for
now, and then wait and see if the appropriate semantics become clearer over
time.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisb
untimeError("Cannot modify an inactive execution context")
That way, to actually mutate a different context, you'd still have to
switch contexts, just as you have to switch threads in C if you want to
modify another thread's thread specific storage.
On 17 October 2017 at 15:02, Nick Coghlan wrote:
> On 17 October 2017 at 14:31, Guido van Rossum wrote:
>
>> No, that version just defers to magic in ContextVar.get/set, whereas what
>> I'd like to see is that the latter are just implemented in terms of
>> manipulat
process:
- sched
- concurrent.futures
- arbitrary callback APIs
- method based protocols (including iteration)
By contrast, "contextvars.set_ctx" would need various wrappers to handle
correctly reverting the context change, and would hence be prone to
"changed the active context
1] as a good recent example of the effectiveness of the
latter approach).
Cheers,
Nick.
[1]
https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mai
On 18 October 2017 at 16:25, Ethan Furman wrote:
> On 10/17/2017 09:40 PM, Nick Coghlan wrote:
>
>> At the Python API layer, we don't expose the ability to switch explicitly
>> to another thread state while remaining within
>> the current function. Instead, we only
in your latest API design, and marking that specific function
as private will cover the fact that its semantics aren't guaranteed yet.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev maili
ronics.stackexchange.com/questions/14816/what-is-metastability
[3]
https://medium.com/@decodoku/how-to-program-a-quantum-computer-982a9329ed02
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-D
On 23 October 2017 at 01:06, Wes Turner wrote:
> On Saturday, October 21, 2017, Nick Coghlan wrote:
>
>> So yeah, for nanosecond resolution to not be good enough for programs
>> running in Python, we're going to be talking about some genuinely
>> fundamental chang
pecified as "If the constructor
arguments consist of a single string, that is handled by calling the
fromisoformat class method".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Py
erview).
Cheers,
Nick.
P.S. MM3 supports a multi-archiver design, so it would presumably also be
possible to write a static-HTML-only pipermail style archiver that ran in
parallel with the interactive web gateway.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
you can't safely delete
messages from MM2 archives: doing so will renumber the archive URLs for all
subsequent messages).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@pyth
ks, rather than asking them to speculate about what they
think *might* break.
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:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
y seems like it
would be a maintainability nightmare that delivered the worst of all
possible outcomes for everyone involved (CPython maintainers, regex
maintainers, Python end users)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
he
ensurepip and venv modules (using existing documented third party
recommendations like those in the re docs for regex and the urllib.request
docs for requests), without actually bundling anything directly into the
python.org installers.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
liably inject expections at "bad"
times, so otherwise rare race conditions can be deliberately provoked.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
ces, but it
wasn't worth it when it came at the cost of making tracebacks unreadable).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailm
On 2 November 2017 at 23:42, Victor Stinner wrote:
> (Email resent, I first sent it to Nick privately by mistake.)
Oops, I didn't even notice that. Reposting my reply below.
> 2017-11-02 2:53 GMT+01:00 Nick Coghlan :
>> The piece that we're currently missing to make su
pyc
files")
To make this syntactic polyfill approach usable with older Python
versions (including 2.7), importlib2 could be resynced to the first
importlib version that supported this (importlib2 is currently up to
date with Python 3.5's multi-phase initialisation support, since that
was the last maj
tyles in a nested
function definition
Baseline:
$ python -m perf timeit -s "def f(): str" "f()"
.
Mean +- std dev: 103 ns +- 3 ns
String constant (~1.25x speedup):
$ python -m perf timeit -s "def f(): 'str'" "f()"
.......
nge, even though you'd only have to type a single ! character extra --
> that's not a lot work, right?
>
> I think that the analogy is reasonable.
I think it also makes a pretty decent argument that pushing function
annotations into implicit lambda expressions will be easier to e
refix to the
sre_*.py files in their new home).
The one caveat I'll note is that this may limit automatic backporting
of fixes to this files (I'm not sure how good 'git cherry-pick' is at
handling file renames).
Cheers,
Nick.
--
Nick Coghlan | ncogh..
lp", "copyright", "credits" or "license" for more information.
>>> await = 1
>>> async = 1
>>> print(async, await)
1 1
So if we're going to go ahead with making them real keywords in 3.7
(as specified in PEP 492
instance and issubclass respect that new hook as well, and define
the hooks as returning the relevant ABCs.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
. If we subsequently decided to elevate expression thunks to a
first class language primitive, they shouldn't need any further
semantic enhancements beyond that one, since the existing scoping
rules already give the desired behaviour at module and function scope.
--
Nick Coghlan | ncogh...
hunk to be executed with eval rather than via a
regular function call), or a new kind of cell stored on a regular
function object (implicit access to class attributes from implicitly
defined scopes in the class body).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
ms, while collections.OrderedDict uses the ordered array
algorithms.
--
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 6 November 2017 at 02:02, Yury Selivanov wrote:
> On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan wrote:
>> The current lack of DeprecationWarnings in 3.6 is a fairly major
>> oversight/bug, though:
>
> There's no oversight. We had PendingDeprecationWarning for
>
vant sections of the documentation, and just use
DeprecationWarning as the specific example)
Cheers,
Nick.
[1] https://docs.python.org/3/library/exceptions.html#DeprecationWarning
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Pyt
def is_class_var(annotation):
return isinstance(annotation, _ClassVar)
It would put the burden on static analysers and the typing module to
understand that `dataclasses.ClassVar` meant the same thing
conceptually as `typing.ClassVar`, but I think that's OK.
Cheers,
Nick.
--
Nick Coghlan |
o-maps-in-action (search for "Iteration Order")
[2] https://docs.oracle.com/javase/8/docs/api/java/util/LinkedHashMap.html
[3]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map
[4]
https://docs.microsoft.com/en-us/dotnet/api/system.collections.specialized.orde
On 6 November 2017 at 09:43, Raymond Hettinger
wrote:
> On Nov 4, 2017, at 7:04 PM, Nick Coghlan wrote:
>> I don't think that situation should change the decision, but I do
>> think it would be helpful if folks that understand CPython's dict
>> implementation cou
d-to-miss advance notice of upcoming
breaking changes in the language definition and standard library), for
the sake of letting app developers duck responsibility for managing
what their own software writes to stderr.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australi
On 6 November 2017 at 14:14, Barry Warsaw wrote:
> On Nov 5, 2017, at 18:05, Nick Coghlan wrote:
>
>> So my proposal is simple (and not really new): let's revert back to
>> the way things were in 2.6 and earlier, with DeprecationWarning being
>> visible by defaul
On 6 November 2017 at 14:40, Lukasz Langa wrote:
> On 4 Nov, 2017, at 6:32 PM, Nick Coghlan wrote:
>> The only workaround I can see for that breakage is that instead of
>> using strings, we could instead define a new "thunk" type that
>> consists of two things:
On 6 November 2017 at 16:00, Stephen J. Turnbull
wrote:
> -committers and some individuals dropped from address list.
>
> Nick Coghlan writes:
>
> > Gah, seven years on from Python 2.7's release, I still get caught by
> > that. I'm tempted to propose we re
On 6 November 2017 at 16:26, Stephen J. Turnbull
wrote:
> Nick Coghlan writes:
>
> > Hence the proposed documentation change: the responsibility for
> > silencing these warnings (for both their own code and for their
> > dependencies) should rest with *application* de
On 6 November 2017 at 16:36, Lukasz Langa wrote:
>
> On 5 Nov, 2017, at 9:55 PM, Nick Coghlan wrote:
>
> Python's name resolution rules are already ridiculously complicated,
> and PEP 563 is proposing to make them *even worse*, purely for the
> sake of an optional featur
ants to see.
Cheers,
Nick.
P.S. That README also points out another problem with the status quo:
DeprecationWarning still gets silenced by default when encountered in
third party modules as well, meaning that also shows up as an abrupt
compatibility break for anyone that didn't already know the
ine to support Python
implementations that don't provide insertion ordering semantics.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
On 6 November 2017 at 19:14, Steven D'Aprano wrote:
> On Mon, Nov 06, 2017 at 01:07:51PM +1000, Nick Coghlan wrote:
>> When we did the "insertion ordered hash map" availability review, the
>> main implementations we were checking on behalf of were Jython & VOC
On 6 November 2017 at 20:21, Paul Moore wrote:
> On 6 November 2017 at 03:38, Nick Coghlan wrote:
>> - if we ever write "import foo" ourselves, then we're a Python
>> developer, and it's our responsibility to work out how to manage
>> DeprecationWarning w
particular key order.
The proposal is that in 3.7 we retroactively declare that the first,
most obvious, version of this code should in fact reliably pass all
three assertions.
Failing that, the proposal is that we instead change the dict
iteration implementation
er list to mark
where the default filters start (and adjust the append mode to insert
filters there), or else provide a new option for programmatic
configuration that's "higher priority than the defaults, lower
priority than the explicit configuration settings".
--
Nick Coghlan
for us to say "CPython uses [these warnings filters] by default,
but redistributors may set the default warnings filter differently.
Always use -W or PYTHONWARNINGS if you want to ensure a particular set
of default filters are active."
Cheers,
Nick.
--
Nick Coghlan | ncogh...@
On 6 November 2017 at 12:18, Nick Coghlan wrote:
> That particular dependency could also be avoided by defining an
> "is_class_var(annotation)" generic function and a "ClassVar" helper
> object in the dataclasses module. For example:
>
> class _Cl
us quo, how do educators learn that the examples they're
teaching to their students are using deprecated APIs?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mai
On 7 November 2017 at 09:20, Lukasz Langa wrote:
>
>
>> On Nov 5, 2017, at 11:28 PM, Nick Coghlan wrote:
>>
>> On 6 November 2017 at 16:36, Lukasz Langa wrote:
>>
>> - compile annotations like a small nested class body (but returning
>> the expr
On 7 November 2017 at 03:27, Chris Jerdonek wrote:
> On Mon, Nov 6, 2017 at 4:11 AM Nick Coghlan wrote:
>> Getting from the "Works on CPython 3.6+ but is technically
>> non-portable" state to a fully portable correct implementation that
>> ensures a particular
years of CPython working a particular way increasing
the inertia against making such a change in 3.8 (and beyond that, I'd
say we'd be well and truly into de facto standardisation territory,
and the chances of ever introducing deliberate perturbation of dict
iteration order would drop to
ython's low end.
So for CPython's target use cases algorithmic efficiency dominates
performance, and we afford to invest extra memory usage and startup
overhead in service to more efficient data access algorithms.
MicroPython's the opposite - you&#x
On 7 November 2017 at 19:30, Paul Moore wrote:
> On 7 November 2017 at 04:09, Nick Coghlan wrote:
>> Given the status quo, how do educators learn that the examples they're
>> teaching to their students are using deprecated APIs?
>
> By reading the documentation on what
ly assumed that their
absence meant we'd forgotten to include them.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyth
"Insertion ordered until the first key removal" is the only guarantee
that's being proposed.
OrderedDict just comes into the discussion because reaching for its
stronger guarantees is currently the only way to obtain that guarantee
in a formally implementation-independent and futu
On 8 November 2017 at 06:32, Guido van Rossum wrote:
> On Mon, Nov 6, 2017 at 7:23 PM, Terry Reedy wrote:
>>
>> On 11/6/2017 9:47 PM, Nick Coghlan wrote:
>> [...]
>>>
>>> - "only show me legacy calls in *my* code" (the "I trust my deps to
&
oids future confusion if the final version of
Python 3.7 were to start bundling Python 3.8's version of typing.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://
er pass "-Wd" to get warnings for everything, or else enable them
selectively using the default main module filter as an example.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python
the array. The bounds checking and
pointer validity testing becomes relatively fiddly if you try to push
against that and instead start iteration from a point partway through
the storage array.
That second point also becomes a concern from a performance
perspective because this is code that run
On 8 November 2017 at 11:44, Nick Coghlan wrote:
> 2. So far, I haven't actually come up with a perturbed iteration
> implementation that doesn't segfault the interpreter. The dict
> internals are nicely laid out to be iteration friendly, but they
> really do assume that yo
On 8 November 2017 at 11:46, Guido van Rossum wrote:
> On Tue, Nov 7, 2017 at 5:35 PM, Nick Coghlan wrote:
>>
>> On 8 November 2017 at 10:03, Guido van Rossum wrote:
>> > OK, so let's come up with a set of heuristics that does the right thing
>> > for
iting portable code doesn't achieve anything
in that scenario - it just puts an extra road block in the way of
those users trying out the alternative interpreter implementation.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
x27;s not Red Hat
specific, but shortening it to the initialism is a bit enterprisey :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/
On 8 November 2017 at 19:21, Antoine Pitrou wrote:
> On Wed, 8 Nov 2017 11:35:13 +1000
> Nick Coghlan wrote:
>
>> On 8 November 2017 at 10:03, Guido van Rossum wrote:
>> > OK, so let's come up with a set of heuristics that does the right thing for
>> > thos
On 9 November 2017 at 07:09, Simon Cross wrote:
> On Wed, Nov 8, 2017 at 10:33 PM, Nick Coghlan wrote:
>> For interactive use, the principle ends up being "Code you write gives
>> deprecation warnings, code you import doesn't" (which is the main
>> aspect I
On 9 November 2017 at 07:46, Antoine Pitrou wrote:
>
> Le 08/11/2017 à 22:43, Nick Coghlan a écrit :
>>
>> However, between them, the following two guidelines should provide
>> pretty good deprecation warning coverage for the world's Python code:
>>
>
ok like:
def f():
class C:
field = 1
class D:
def method(a: C.field):
...
C.D.C = C # Make annotations work at runtime
return f
That leaves the door open to a future PEP that proposes thunk-based
annotations
and the compatibility fixes without causing problems for
the release manager (and you're currently fine on that front with
respect to 3.7).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
m Nathaniel pointed out that "stacklevel"
can be hard to set correctly when emitting a warning (especially at
import time), but it also opens a new way of dealing with that: using
warnings.warn_explicit to claim that the reporting module is
"__main__" if
ed my
mind :)
On 9 November 2017 at 14:16, Guido van Rossum wrote:
> On Wed, Nov 8, 2017 at 5:49 PM, Nick Coghlan wrote:
>>
>> On 8 November 2017 at 16:24, Guido van Rossum wrote:
>> > I also don't like the idea that there's nothing you can do with a thunk
>
, and I routinely
use the REPL to check the validity of snippets of code that I plan to
use (or advise someone else to use). Those are the cases where the
status quo sometimes trips me up, because I forget that I'm *not*
getting deprecation warnings.
Cheer
#unittest.TextTestRunner
So that's likely part of the problem.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p
On 10 November 2017 at 11:53, Nick Coghlan wrote:
> On 10 November 2017 at 11:32, Nathaniel Smith wrote:
>> Is this intended to be a description of the current state of affairs?
>> Because I've never encountered a test runner that does this... Which runners
>> are you t
sistently be "Do
not roll your own refcount management, get a code generator or library
to handle it for you".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
tringify_annotations
> is too hard to spell.
Aye, I'd be fine with "from __future__ import string_annotations" -
that's even more explicitly self-documenting than either of my
suggestions.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
for these are generally either "Did it do what I wanted?" or
else a dry-run mode where it prints out what it *would* have done in
normal operation.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Pytho
r way, it just struck me
that the reversed order might be marginally clearer, so it seemed
worthwhile to mention it.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.o
t; et al. I
> think it has a nice vibe to it.
Getting folks to *not* call type hinting static typing is an ongoing
challenge though, so it doesn't seem like a good idea to encourage
that link to me.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 11 November 2017 at 02:02, Random832 wrote:
> On Tue, Nov 7, 2017, at 07:22, Nick Coghlan wrote:
>> My suggestion for that definition is to have the *default* meaning of
>> "third party code" be "everything that isn't __main__".
>
> What is __main_
On 11 November 2017 at 01:48, Guido van Rossum wrote:
> I don't mind the long name. Of all the options so far I really only like
> 'string_annotations' so let's go with that.
+1 from me.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
est runners that do import the code under test, I think
that *our* responsibility is to make it clearer that the default
warning state isn't something that test runner designers should
passively inherit from the interpreter - deciding what the default
warning state should be (and how to get s
have encountered the specific notion of "API
deprecation"
Cheers,
Nick.
==
PEP: 565
Title: Show DeprecationWarning in __main__
Author: Nick Coghlan
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 12-Nov-2017
Python-Version: 3.7
Post-History: 12-Nov-2017
t;a"))
operator.itemgetter and operator.attrgetter may provide some
inspiration for possible proposals.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://
On 13 November 2017 at 03:10, Serhiy Storchaka wrote:
> 12.11.17 11:24, Nick Coghlan пише:
>>
>> The PEP also proposes repurposing the existing FutureWarning category
>> to explicitly mean "backwards compatibility warnings that should be
>> shown to users of Python
rand precedence (we'd use the same rules as normal
expressions), but we could still offer a runtime expression type that
was compiled at the same time as everything else, but rather than
accepting parameters like a regular function, instead accepted a
namespace to use when evaluating the express
luence, if any, should I have over
the use of 'bar' as an import package or module name in other
distribution packages?
I expect that the PSF will need to address them directly some day, but
I don't think PEP 561 itself needs to address them (and the first
version of PEP 541 proba
for them"
snippet actually looks like:
if not sys.warnoptions:
warnings.simplefilter("ignore")
(I'll mention this in the PEP and docs patch as well)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
dd more debugging capabilities.
I don't consider it a replacement for tweaking how we handle
DeprecationWarning by default, though :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@pyt
27;s getting much closer to the "negligible" range, even for
command line apps.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
turned provides a way to programmatically
combine mixins without having to define a new subclass for each combination
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https:/
ig_bases" with __mro_entries__ methods,
do all such methods get passed the *same* orig_bases tuple? Or do they
receive partially resolved ones, such that bases listed before them have
already been resolved to their MRO entries by the time they run.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail
se: default, once, module, and always are all
different settings.
once: once per process (regardless of location)
module: once per module (regardless of line)
default: once per location (line+module combination)
always: every time
Still, even with once-per-location behaviour, the warning o
gent change, but the strict backwards compatibility
policy means it's one where we'll be stuck with any mistakes we make
for a long time. (Proper use of symbol versioning might offer a
subsequent escape clause, but that introduces its own cross-platform
compatibility
On 18 November 2017 at 23:50, Nick Coghlan wrote:
> On 18 November 2017 at 11:05, Victor Stinner wrote:
>> Hi,
>>
>> tl; dr I propose to extend the existing "stable API" to make it almost
>> as complete as the current API. For example, add back
>>
401 - 500 of 6587 matches
Mail list logo
