atus would account for" territory, while still
enabling the improved testing and accessibility for experimentation
that we're after in order to make some better informed API design
proposals for Python 3.8.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
gs like CSP and Actor-based programming backed by stronger
memory separation than is offered by Python threads.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
As per my comment there, and Jakub Wilk's post to this thread, we're
missing a case to also check for the string "POSIX" (which will fix
several of the current locale coercion discrepancies between Linux and
*BSD systems).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.co
On 7 December 2017 at 01:59, Jakub Wilk wrote:
> * Nick Coghlan , 2017-12-06, 16:15:
>> The one that's relevant to default locale detection is just the string
>> that "setlocale(LC_CTYPE, NULL)" returns.
>
> POSIX doesn't require any particular return
ted and arcane, but it works well enough
for
https://github.com/python/cpython/blob/master/Lib/test/test_c_locale_coercion.py
to pass across the full BuildBot fleet :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 6 December 2017 at 14:50, Nick Coghlan wrote:
> On 6 December 2017 at 14:34, Nick Coghlan wrote:
>> That said, I go agree we could offer easier to use APIs to app
>> developers that just want to hide warnings from their users, so I've
>> filed https://bugs.python.o
one) helps us avoid
> tying ourselves strongly to any particular implementation (it seems
> like all the reservations were relative to the implementation). So I
> do not see a reason to wait.
Aye, the split sending API with a merged receive API works for me.
> * "Pass cha
t controls whether the
stream gets wrapped in TextIOWrapper or not.
It's only in Python 2 that the distinction is Windows-specific (where
it controls how "\r\n" sequences get handled).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 6 December 2017 at 15:59, Chris Angelico wrote:
> On Wed, Dec 6, 2017 at 4:46 PM, Nick Coghlan wrote:
>> Something I've just noticed that needs to be clarified: on Linux, "C"
>> locale and "POSIX" locale are aliases, but this isn't true in gener
erce LC_CTYPE in the C locale to a
UTF-8 based equivalent
2. Only if that fails (e.g. as it will on CentOS 7) do we resort to
implicitly enabling CPython's internal UTF-8 mode (which should behave
like C.UTF-8, *except* for the fact extension modules won't respect
it)
That way, the ideal
On 6 December 2017 at 14:34, Nick Coghlan wrote:
> That said, I go agree we could offer easier to use APIs to app
> developers that just want to hide warnings from their users, so I've
> filed https://bugs.python.org/issue32229 to propose a straightforward
> "warnings.hid
ve
filed https://bugs.python.org/issue32229 to propose a straightforward
"warnings.hide_warnings()" API that encapsulates things like checking
for a non-empty sys.warnoptions list.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
have tended to rely on the default filters, and we've
then had ongoing arguments about who wins and who loses in deciding
what the defaults should be.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing
ttps://www.python.org/dev/peps/pep-0538/#explicitly-setting-lc-ctype-for-utf-8-locale-coercion
The relevant code is in _coerce_default_locale_settings (currently at
https://github.com/python/cpython/blob/master/Python/pylifecycle.c#L448)
> I'm not sure how PyGTK interacts with the PEP 538
,
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%
d rationale:
https://github.com/python/peps/commit/966dd426787e6de8ec6218955cec57f65086c5b4
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:
t-in.
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
arise specifically from seeking to
provide a common conceptual underpinning for the semantics of both the
proposed None-aware operations and the existing short-circuiting
logical operators.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 29 November 2017 at 04:31, Eric V. Smith wrote:
> On 11/28/17 7:02 AM, Nick Coghlan wrote:
>> So in the above example, you would have:
>>
>>>>> B.__field_layout__ is B
>>True
>>>>> C1.__field_layout__ is B
>>True
>>
name if not def else name.strip()[4:].upper()
user if not def else user.first_name.upper()
Cheers,
Nick.
P.S. Compared to this, our last symbolic feature addition (matrix
multiplication), was a relatively straightforward transcription of "⋅"
to "@", just as regular multipli
On 29 November 2017 at 03:13, Brett Cannon wrote:
> On Tue, 28 Nov 2017 at 03:33 Nick Coghlan wrote:
>> P.S. Note that inspect.getfullargspec() was actually undeprecated a
>> while back - enough folks that didn't need access to the function
>> annotations were reimpl
decorator to set
`__field_layout__` correctly, using the follow rules:
1. Use the just-defined class if the class defines any fields
2. Use the just-defined class if it inherits from multiple base
classes that define fields and don't already share an MRO
3. Use a base class if that's ei
g supported again. I don't think
that changes the argument here though - it just means guaranteed order
preservation in that API will only happen if we declare dicts to be
insertion ordered in general.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
xed.
> This sentence in particular also reads odd: the
> "but" seems to apply to everything that comes before, but actually is meant
> to apply only to "cases where ...". Maybe rephrasing this can help the
> sentence flow better.
I missed this comment initially. Follow-
On 27 November 2017 at 15:04, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> Perhaps the check could be:
>>
>> (type(lhs) == type(rhs) or fields(lhs) == fields(rhs)) and all
>> (individual fields match)
>
>
> I think the types should *always* have to mat
tion to speed up the
common case, while the formal semantic constraint would be that the
field definitions have to match (including their names and order).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev
ite recursion when the coroutine wrapper attempts to call the
coroutine wrapper.
Cheers,
Nick.
P.S. Making that point reminded me that I still haven't got around to
updating those docs to also include examples of how to do it *right*:
https://bugs.python.org/issue30578
--
Nick Coghlan
en't been combined because they have some
*intentional* differences in exactly what they allow, so I also
suspect that this is easier said than done.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Pyt
e to be sufficient for all practical purposes (as even the "yield
from" based spelling is Python-3-only, so it's only code that still
has to support 3.3, 3.4, 3.5, without needing to support 2.7, that
could use "yield from + yield" comprehensions, but wouldn't have the
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:
>>>> def example():
>>>>
On 25 November 2017 at 15:27, Nathaniel Smith wrote:
> On Fri, Nov 24, 2017 at 9:04 PM, Nick Coghlan wrote:
>> def example():
>> comp1 = yield from [(yield x) for x in ('1st', '2nd')]
>> comp2 = yield from [(yield x) for x in (
e change in 2.7 & 3.1 covered
all Python applications, not just developer tools (developer tools
just provide a particularly compelling example of why "revert to the
Python 2.6 behaviour" isn't a good answer)
Cheers,
Nick.
=
PEP: 565
Title: Show DeprecationW
spect of the "an explicit and immediate 'yield from' is
required when using subgenerator comprehensions" approach is that the
above syntax already works today, and has actually worked since 3.3 -
we'd just never put the pieces together properly to establish this as
a pot
x27;m now suggesting we do for
comprehensions) wouldn't work at all (since a genexp returns a generator
*fuction*, not a generator-iterator object). I'm also pretty sure it will
be difficult for the compiler to tell the difference between explicit and
implicit yield expressions in the subfunc
On 24 November 2017 at 12:21, Glenn Linderman wrote:
> On 11/23/2017 5:31 PM, Nick Coghlan wrote:
>
> - a consolidated list of *all* the APIs that can safely be called before
> Py_Initialize
>
> So it is interesting to know that list, of course, but the ones that are
>
ate API which is not exported...
>
Even after we reach the point of exposing the more fine-grained
initialisation API (which I'm now thinking we may be able to do for 3.8
given Eric & Victor's work on it for 3.7), we're still going to have to
ensure the existing configu
along those lines, so the principle at work there would be pattern
extraction based on things people already do for themselves.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@pytho
t_of_futures:
f(yield future)
(Right now, you instead get "yield f(yield future)" as the innermost
statement, which probably isn't what you wanted)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
ically we *could* define new answers to all of those situations, but
then we're stuck explaining to everyone what those new behaviours actually
are, and I think that will actually be harder than the status quo, where we
only have to explain why these implicit scopes act much the same way that
&quo
cit class based
nullcontext() implementation is 7 lines, the same as contextlib.closing())
After 7+ years, I'm happy that this one comes up often enough to be worth a
more obvious standard library level answer than we'd previously offered.
https://bugs.python.org/issue10049#msg281556 captur
yield (yield expr) # genexp
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.or
(and one
we were able to avoid for async/await by retaining the same "await is only
permitted in async comprehensions" constraint that exists for explicit
scopes).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
ace some additional constraints on us in terms of handling static
initialization of the allocator state, and ensuring we revert back to that
state in Py_Finalize, but I think it's the only way we're going to be able
to reliably replace all calls to malloc & free with PyMem_RawMalloc and
On 21 November 2017 at 01:31, Eric Snow wrote:
> On Nov 18, 2017 19:20, "Nick Coghlan" wrote:
>
>
> OK, in that case I think the answer to Victor's question is:
>
> 1. Breaking calling Py_DecodeLocale() before calling Py_Initialize()
> is a compatibility b
then I'd suggest officially adding that to the
"must work prior to Py_Initialize" list, otherwise we can re-examine
it based on whatever's still broken after reverting the raw allocator
changes.
Cheers,
Nick.
--
Nick Coghlan |
On 19 November 2017 at 17:22, Nick Coghlan wrote:
> I've updated the PEP to try to make the explanation of the historical
> rationale more accurate:
> https://github.com/python/peps/commit/30daada7867dd7f0e008545c7fd98612282ec602
With these changes, I think the version now
On 13 November 2017 at 01:45, Guido van Rossum wrote:
> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
>>
>> In Python 2.7 and Python 3.2, the default warning filters were updated to
>> hide
>> DeprecationWarning by default, such that deprecation warnings in
&
s" would be an easier guideline to remember.
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
On 19 November 2017 at 01:45, Serhiy Storchaka wrote:
> 18.11.17 16:17, Nick Coghlan пише:
>>
>> On 18 November 2017 at 10:01, Victor Stinner
>> wrote:
>>>
>>> I'm writing this email to ask if this change is an issue or not to
>>> embedded
before Py_Initialize, I don't think
we're far enough into the startup refactoring process to be making
those kinds of promises).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python
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
>>
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
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
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
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:/
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
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
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
_
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
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
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
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://
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
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
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
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_
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
__
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
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
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
__
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
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
#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
, 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
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
>
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
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
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
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:
>>
>
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 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
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/
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
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
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
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
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
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://
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
&
"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
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
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
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
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
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
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
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 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
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...@
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
501 - 600 of 6587 matches
Mail list logo
