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 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
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 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
&
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
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 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
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
(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
___
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
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
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
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
_
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
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
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
>
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
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
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
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 (
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():
>>>>
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
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
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
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
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
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-
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
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
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
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 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
>>
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
__
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
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:
,
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%
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
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
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
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
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 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
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
_
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
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
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 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
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
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
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
__
n target back when the
PEP still set both LANG & LC_ALL, whereas it now changes only
LC_CTYPE. That means setting it won't mess with LC_COLLATE, or any of
the other locale categories. That said, I'm not sure if there are
behavioural differences between "LC_CTYPE=C.UTF-8"
e new class object.
So right now, I think this trade-off tilts heavily in favour of "Keep
the same class, but reimplement any required method inference logic
when injecting methods".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 12 Dec. 2017 8:52 am, "Guido van Rossum" wrote:
- 558 (locals()) -- I think this will have to be postponed
+1 for deferring that one to 3.8. While I like where it's heading now, it
isn't urgent, and we already have quite a few refactorings of low level
internals landing in 3.7.
Cheers,
Nic
On 11 Dec. 2017 12:26 pm, "Eric V. Smith" wrote:
I see a couple of options:
1a: Use a default type annotation, if one is not is supplied. typing.Any
would presumably make the most sense.
1b: Use None if not type is supplied.
2: Rework the code to not require annotations at all.
1c: annotate w
On 11 Dec. 2017 6:50 am, "INADA Naoki" wrote:
Except one typo I commented on Github,
I accept PEP 540.
Well done, Victor and Nick for PEP 540 and 538.
Python 3.7 will be most UTF-8 friendly Python 3 than ever.
And thank you for all of your work on reviewing them! The appropriate
trade-offs bet
On 13 Dec. 2017 12:53 pm, "Victor Stinner" wrote:
2017-12-13 0:24 GMT+01:00 Guido van Rossum :
> Considered disagreement is acceptable.
Sure, I'm fine with that ;-)
> Nick, congrats with PEP 565! Please update the PEP to mark it as approved
> with a link to this message as the resolution, and l
On 14 Dec. 2017 9:19 am, "Antoine Pitrou" wrote:
Hello,
After debugging a crash on AppVeyor for a submitter's PR
(see https://github.com/python/cpython/pull/4611 ), I came to the
following diagnosis: converting the "atexit" module (which is a
built-in C extension) to PEP 489 multiphase initiali
On 19 Dec. 2017 7:00 am, "Chris Barker" wrote:
Are there other options??
plain old:
@dataclass
class C:
a = 1
b = 1.0
would work, though then there would be no way to express fields without
defaults:
The PEP already supports using "a = field(); b = field()" (etc) to declare
untyped
On 23 Dec. 2017 9:37 am, "David Mertz" wrote:
There name Data seems very intuitive to me without suggesting type
declaration as Any does (but it can still be treated as a synonym by actual
type checkers)
Type checkers would also be free to interpret it as "infer the type from
the default value"
to the case with functools.partialmethod,
where you're going to need to write a separate
functools.singledispatchmethod class that's aware of the descriptor
protocol, rather than trying to add the functionality directly to
functools.singledispatch.
Cheers,
Nick.
--
Nick Coghla
w).
And you need the change to be explicitly opt-in *somehow*, in order to
avoid breaking any existing code that relies on methods decorated with
"singledispatch" dispatching on the bound class.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 30 Dec. 2017 11:01 am, "Ethan Smith" wrote:
On Fri, Dec 29, 2017 at 4:52 PM, Guido van Rossum wrote:
> I still think it should overrides anything that's just inherited but
> nothing that's defined in the class being decorated.
>
>
Could you explain why you are of this opinion? Is it a conc
fferences matter for educational purposes (i.e. "data
classes" with "fields", vs trying to explain that "attributes",
"attrs", "attr.s", and "attr.ib" are all different things), but
"available by default" matters even more on that fr
ensure "self is
module.__spec__.loader" as part of their get_resource_reader()
implementation.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python
if no var level default
was specified.
The conservative option would be to start with only the
`ContextVar.lookup` method, and then add `ContextVar.get` later if
it's absence proved sufficiently irritating.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
neral idea
(a dedicated Python class to represent a C struct), just in the other
direction.
As with DirEntry, I don't see any obvious value in making the new
objects iterable though - we should be able to just use named field
access in both the C and Python APIs.
Cheers,
Nick.
--
Nick Cogh
On 9 January 2018 at 17:07, Serhiy Storchaka wrote:
> 09.01.18 05:31, Nick Coghlan пише:
>> As with DirEntry, I don't see any obvious value in making the new
>> objects iterable though - we should be able to just use named field
>> access in both the C and Python APIs.
&
o deal with it anyway: a switch
statement dispatching on the first value, and then passing the
remaining arguments to the corresponding posix_file_actions API.
Wrapping it all up in a more Pythonic self-validating API would then
be the responsibility of the subprocess module (in the standard
library
any kind of consistent response time
assurance for issues or pull requests).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
e do want to support raising an exception for
unitialised access after all, then we could introduce a "missing"
callback to the ContextVar constructor that would be akin to
defaultdict's "default_factory" callback (with the requirement
becoming that you have to specify
"my
packages" vs "the system's package" split is a better option. (It's
also rather useful for bootstrapping tools like "pipsi" - "pip install
--user pipsi", then "pipsi install" the other commands you want access
to).
Cheers,
Nick.
t API, it's also fairly easy
to build atop the more explicit one:
def set_cvar(cvar, value):
token = cvar.set(value)
return functools.partial(cvar.reset, token)
reset_cvar1 = set_cvar(cvar1, ...)
...
reset_cvar1()
Che
nature__ as precedent for
using "/" to indicate that the preceding parameters are
positional-only, though.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
ht
empty strings
in the keyword array.
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.pyth
ys,
the preference is more strongly in favour of amending the existing API
if Python offers relevant features that let us hide the existence of
multiple distinct APIs at the OS level.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
streams for the Linux kernel - if a
commercial Python vendor chooses to go beyond those dates they can,
just as they may go beyond python-dev's nominal support dates for
CPython itself.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
t deciding
one way or the other on whether or not to provide a native way to
express signatures like the one for range().
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@pytho
On 22 January 2018 at 20:57, Victor Stinner wrote:
> I created an issue with more information:
> https://bugs.python.org/issue32620
We shouldn't be requiring a pre-existing Python to build CPython
anyway, so it would be nice if we could just delete that step
entirely.
Cheers,
Nick
On 21 January 2018 at 01:56, Barry Warsaw wrote:
> On Jan 05, 2018, at 05:12 PM, Nick Coghlan wrote:
>
>>I think the main reason you're seeing a problem here is because
>>ResourceReader has currently been designed to be implemented directly
>>by loaders, rather than
On 20 January 2018 at 15:00, Guido van Rossum wrote:
> On Fri, Jan 19, 2018 at 8:47 PM, Nick Coghlan wrote:
>>
>> On 20 January 2018 at 07:49, Mario Corchero wrote:
>> > I am happy to put some work into this (and Pablo Galindo in CC offered
>> > to
>> &
switch back to the
current default single process mode?
My rationale for that is to improve the default edit-test cycle in
local development, while still providing a way to force single-process
execution for failure investigation purposes.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
testing options that already explicitly conflict with the
multiprocessing option are:
* -T (tracing)
* -l (leak hunting)
"-j1" would likely also be a better default when the verbosity flags
are set (since the output is incredibly hard to read if you ha
tcome that can be mapped directly to the decorator
"hash" parameter:
- A: not hashable
- B: not hashable
- C: not hashable
- D: not hashable
- E: not hashable
- F: hashable (by field hash)
- G: hashable (by field hash)
- H: hashable (by field hash)
Inheritance of __hash__ could
t; for faster local testing, without risking
backwards compatibility issues with existing test suite invocations in
other contexts.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-
"def __hash__: ..." in the body of the class definition,
and the replacement for "hash=False" would be "__hash__ = None" in the
class body.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 3 Feb. 2018 1:09 am, "Eric V. Smith" wrote:
The problem with dropping hash=True is: how would you write __hash__
yourself? It seems like a bug magnet if you're adding fields to the class
and forget to update __hash__, especially in the presence of per-field
hash=False and eq=False settings. A
y mutable state, then the recommended way
of handling that would be through containment, where the mutable state
is moved out to a subrecord that gets excluded from hashes and
comparisons.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
ation unlikely, even though the true
underlying type is still the mutable version.
That said, if we do provide "unsafe_hash", then the documentation for
that flag becomes a place where we can explicitly suggest using a
frozen subclass instead.
Cheers,
Nick.
--
Nick Coghlan | n
3713081631934410656
So "unsafe_hash=True" would just be a shorthand spelling of that which
skips creating the full frozen version of the class (and with the
explicit parameter, we can better document the risks of making
something hashable without also freezin
stances are frozen), it isn't a surprising defect waiting
to happen the way "frozen=False, hash=True" is in the current
interface.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailin
comparison
support), so your library strikes as being more an advanced
alternative to types.SimpleNamespace rather than an alternative to
data classes.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev
= None
def __post_init__(self, database):
if self.j is None and database is not None:
with mutable(self):
self.j = database.lookup('j')
Using object.__setattr__ explicitly would be clearer, though.
Cheers,
Nick.
--
Nick Cogh
"type(obj)" and "obj.__class__" refer to
different types is a formally supported state for instances, there are
also lots of APIs where it isn't well defined whether an attribute
lookup will use the nominal class or the true underlying type.
Cheers,
Nick.
--
as provisionally 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:
https://mail.python.org/m
#x27;t appear to have been submitted to the PEPs repo:
https://mail.python.org/pipermail/python-dev/2016-September/146043.html)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python
single https://github.com/python/bugs.python.org repo would better
align tracker development with development on other parts of the
infrastructure.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@py
f these tools share a common
problem when applied to CPython: we routinely break them :)
Part of that is permanent breakage in the test suite where we
deliberately test the compiler and interpreter's reaction to invalid
code, while the other part is transient breakage when we introduce
believe we still run Tools/scripts/reindent.py and
Tools/scripts/reindent-rst.py as pre-merge checks. (I actually thought
we add a reindent-c.py script as well, since Py3 switched all the C
code over to using spaces for indentation to match the Python
conventions, but it appears not).
Cheer
setattr
> raise FrozenInstanceError(f'cannot assign to field {name!r}')
> dataclasses.FrozenInstanceError: cannot assign to field 'j'
>
> Maybe it should be an error to declare B as non-frozen?
It would be nice to avoid that, as a mutable subclass of a fro
used to have instructions for setting that up as a
local pre-commit hook in Mercurial. It may make sense to create
similar instructions for git (if we don't already have those
somewhere).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Br
501 - 600 of 6587 matches
Mail list logo
