entially even just "str") to instead accepting "os.PathLike"
doesn't count as fixing a genuine bug in the earlier releases - it
just means we made the API more permissive in a maintenance release.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
nouncement yet.
Antoine's request was for me to update PEP *538* to eliminate the
"this will need to change if PEP 540 is accepted" aspects, and I think
your suggestion to make the "C.UTF-8 -> surrogateescape on standard
streams by default" behaviour independent of the
hat it isn't unusual for related PEPs to
have non-sequential PEP numbers)
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 5 May 2017 at 16:01, Victor Stinner <victor.stin...@gmail.com> wrote:
> Le 5 mai 2017 6:31 AM, "Nick Coghlan" <ncogh...@gmail.com> a écrit :
>
> The note just needs to say that folks that care about doing "complete"
> builds need to adjust their co
nguishable at runtime (aside from the stderr warning in the
latter case).
It will then be up to Victor to state in PEP 540 how locale coercion
will interact with Python UTF-8 mode (with my recommendation being the
one currently in PEP 538: it should implicitly set the environment
variable, so the
ike shutil that I put into the same
category as third party libraries for now: Python 3.6 users shouldn't
expect implicit use of the fspath protocol to be universal yet, so
they may still need some explicit calls to os.fspath() in their own
code to get different APIs to work well together.
Cheers,
Nick
s should also make bootstrapping easier, since bootstrap builds can
skip the "make regen-all" step and instead rely on the checked in
pre-generated files.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
nt that we could have
deferred to the next feature release.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-de
e.
That makes me more confident in making that change, as it would be
rather counterproductive if our changes gave base image developers an
incentive *not* to set C.UTF-8 as their default locale.
> Anyway, I think https://bugs.python.org/issue15216 should be fixed in
> Python 3
's a docs limitation which should be
addressed.
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
pointer to a pre-allocated
instance" cases can then be documented on the affected public API
functions.
So +1 from me for making pre-allocation a CPython C API guarantee, -1
for making it a language level singleton commitment.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisban
On 1 May 2017 at 17:13, Martin Panter <vadmium...@gmail.com> wrote:
> On 1 May 2017 at 06:37, Nick Coghlan <ncogh...@gmail.com> wrote:
>> Hi folks,
>>
>> I'm trying to write a NEWS entry that explains that the
>> ":func:`bytes`" cross-references
entries. Use ``\:ref\:\`func-bytes\```
and ``\:ref\:\`func-bytes\``` to reference the latter.
My fallback plan is to just include the unescaped markup in the NEWS
entry (rather than trying to make it readable even in rendered form),
but I figured I'd ask for advice here first.
Cheers,
Nick.
en
reviewing them so far, and they look sensible to me, but I don't
personally know the profile code base at all, so there's a strong
chance I'll miss subtle details.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
e upstream Roundup project is also interested in offering that
capability by default: http://issues.roundup-tracker.org/issue2550734
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https
update the
headers on both PEPs accordingly.
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
What are
they hiding?"), but that's OK - different services are provided for
different audiences.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
tenance releases, and add some automated testing to
avoid accidental changes and oversights (similar to the pending test
to ensure magic number stability for cached bytecode files)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
ish before 2020, with Canonical being a "maybe" on 2023 (depending on
what happens in Ubuntu 18.04).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
release-end-of-life
>
As far as I'm aware, Samba is the main remaining challenge for Fedora
Server on that front, but at least all of the libraries it depends on have
received the necessary updates to make them Python 2/3 compatible:
http://fedora.portingdb.xyz/pkg/samba/
Cheers,
Nic
ibute like
"sys._raw_argv" to get the full details of how Python was invoked.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
On 16 March 2017 at 00:30, Barry Warsaw <ba...@python.org> wrote:
> On Mar 15, 2017, at 12:29 PM, Nick Coghlan wrote:
>
> >From a mainstream Linux point of view, it's not common - on
> systemd-managed
> >systems, for example, the only way to get the C locale these d
alent to sorting the decoded text by
the Unicode code point values, which means that "LC_COLLATE=C" sorting by
byte value, and "LC_COLLATE=C.UTF-8" sorting by "Unicode code point value"
give the same results.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Bris
On 15 March 2017 at 00:17, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 13 March 2017 at 23:31, Random832 <random...@fastmail.com> wrote:
>
>> On Mon, Mar 13, 2017, at 04:37, INADA Naoki wrote:
>> > But locale coercing works nice on platforms like android.
>
on Android also show up when you do either "LANG=C
python2" or "LANG=C python3" on traditional Linux and attempt to *edit*
lines containing multi-byte characters), so you really need to know what
you're doing in order to operate under those constraints.
Chee
ose with a more conventional use case (i.e. running an up
to date \*nix OS using UTF-8 or another universal encoding for both local
and remote interfaces).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
On 12 March 2017 at 22:57, Nick Coghlan <ncogh...@gmail.com> wrote:
> However, I'm also open to having [PYTHONCOERCECLOCALE=0] also disable the
> runtime warning from the shared library.
>
Considering this a little further, I think this is going to be necessary in
order to
none of the above seems possible to correctly
> implement in Python.
>
The first case remains unchanged, the other two will need to use Python 2.7
or Tauthon. I'm fine with that.
> * Nick Coghlan <ncogh...@gmail.com>, 2017-03-05, 17:50:
>
> While this PEP ensures that develo
an informational PEP, why withdraw it?
The PEP Index organises itself by status, so withdrawing it moves it down
into the historical PEPs section, and out of the active section. (We're
probably due for a PEP "spring clean" in general, but doing that is about
as exciting as actual spri
On 9 March 2017 at 07:58, Guido van Rossum <gu...@python.org> wrote:
> On Wed, Mar 8, 2017 at 4:35 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>
>>
>> On 5 March 2017 at 17:50, Nick Coghlan <ncogh...@gmail.com> wrote:
>>
>>> Late last ye
te
to Withdrawn, so it doesn't actually break any links. It's helpful to add a
short "PEP Withdrawal" section to say why it's withdrawn though, and you'd
be able to link to the wiki.python.org page from there.
Cheers,
Nick.
--
Nick Coghlan | ncog
On 5 March 2017 at 17:50, Nick Coghlan <ncogh...@gmail.com> wrote:
> Hi folks,
>
> Late last year I started working on a change to the CPython CLI (*not* the
> shared library) to get it to coerce the legacy C locale to something based
> on UTF-8 when a suitable locale is
ws is unexpectedly leaving the parent directory of the given directory
or archive on sys.path when running directories and zip archives on other
platforms).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev maili
work everywhere" approach, where the async protocol methods use
"await obj.aclose()" if the latter is defined, and a synchronous
"obj.close()" otherwise.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
zations. I *think* it will be universally positive
(because the status quo really is broken), but it also wouldn't be the
first time I've learned something new and confusing about the locale
subsystem only after releasing software that relied on an incorrect
assumption about it :)
Cheers,
Nick.
--
N
you still need to be consistent with the
platform settings).
Cheers,
Nick.
==
PEP: 538
Title: Coercing the legacy C locale to a UTF-8 based locale
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan <ncogh...@gmail.com>
Status: Draft
Type: Standards Tr
sions, but this would be more about using Python's benchmark suite
to investigate the performance of *gcc*, since it appears that may be the
culprit here.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev ma
cedent for any other modules like itertools - the trade-offs there are
going to be different, and there are already third party modules like
https://github.com/asyncdef/aitertools that provide equivalent APIs for the
asynchronous programming model.
Cheers,
Nick.
--
Nic
r (with a
cross-reference from the synchronous contextlib docs), rather than the
current approach of adding it directly to contextlib?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@pyth
readers will have *some* ability
to read English, they just prefer to read their native language.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
etails, like the internal structure of co_code and
co_lnotab, where they may change arbitrarily between CPython feature
releases. The generator and coroutine ABCs were also specifically added so
they could be replaced with objects that don't have __code__.co_flags
attributes (e.g. by Cython) with
n" refers to
the upstream repo), but it would be good if folks could try it out with
other configurations before we merge it (in particular, it *should* handle
the case where the upstream remote is called "upstream", but I don't use
that arrangement myself).
Cheers,
Nick.
-
going to be better handled
inline (e.g. "On versions older than 3.x, ") rather than by maintaining
multiple distinct versions of the document.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Pytho
ntroduction to
programming workshop).
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.p
d credible
potential customers (i.e. folks that have the ability to affect
redistributor revenue directly) rather than from redistributor staff or
community volunteers (as we're pretty much limited to using risk management
and hiring pipeline based lines of argument, rather than being able to push
the &qu
.
In addition to the case of folks that struggle to read the English
documentation at all, I'd assume that there are also folks that would
appreciate the chance to check their own understanding against someone
else's translation of various topics.
Cheers,
Nick.
--
Nick Coghlan | ncogh
the PEP process, so your planned
approach makes a lot of sense to me.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python
add a "Fixed In"
column to the summary table to get a quick overview of which versions were
affected.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
Python *before* they learn English
(even if learning English remains a pre-requisite for tapping into the full
capabilities of both the language and its ecosystem).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev m
ming the latter case, I think it may make sense for Christian to handle
the BDFL-Delegate responsibilities as well - I know he's a co-author of the
PEP, but I also think he's the most qualified to make the final decision on
the suitability of this design.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@
On 30 January 2017 at 15:26, Barry Warsaw <ba...@python.org> wrote:
> On Jan 30, 2017, at 12:38 PM, Nick Coghlan wrote:
>
>>I think there are 3 main candidates that could fit that bill:
>>
>>- requests
>>- setuptools
>>- regex
>
> Actually, I think
rning in 3.7
- Py3k warning in 2.7.x
- SyntaxError in 3.8
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:
htt
On 28 January 2017 at 18:07, Barry Warsaw <ba...@python.org> wrote:
> On Jan 28, 2017, at 03:43 PM, Nick Coghlan wrote:
>
>>I still think it could be a good candidate for a first "bundled"
>>module, where we don't migrate it fully into the CPython development
&g
, which are available for a range of Python versions.
I still think it could be a good candidate for a first "bundled"
module, where we don't migrate it fully into the CPython development
process, but *do* officially bless it and provid
ar as I can tell, wrapt doesn't currently support "closing" a
proxy by replacing the reference to the internal object with a
reference to None (adding that might be possible, but I don't
personally know wrapt well enough to guess the feasibility of doing
so).
Cheers,
Nick.
--
Nick
houldn't be
difficult, and it's a nice courtesy for anyone that *is* somehow currently
getting it to work.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python
That suggests the tests would need to check the headers with all stable
ABI versions from 3.2 up to the current release and ensure they match the
current C API documentation)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
ideas/2012-October/016768.html
--
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/
rectly declare the destination storage as a const pointer will still
compile against the old API variants that return a mutable pointer, so any
problems this finds in third party code are likely to be resolved for older
3.x releases as well.
Cheers,
Nick.
--
Nick C
structure as soon as possible (the fact that Django is structured primarily
as an object oriented framework likely helped with that, as it has a lot of
control over the data types user applications end up encountering).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Au
On 13 December 2016 at 02:12, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Dec 13, 2016 at 12:18 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> It absolutely *is* relevant, as is how diligent the redistributors are
>> in differentiating between the
d the PSF Board rather than python-dev), so if you'd like to learn
more about trademark law and how it applies to open source projects in
general, I'd suggest taking advantage of the extensive material
available online rather than posting further here (the history of the
Firefox/Iceweasel disagreement betw
superset"), which is always OK.
In this particular case, there just happened to be an obvious name for
the project (courtesy of PEP 404) that was nevertheless problematic on
the "potential for confusion" trademark front. Fortunately, there have
been a few interesting alternative
t its a fork,
>>like Stackless.
>
> Yes, exactly right. It's not sanctioned by the PSF and should not be called
> "Python" anything.
NorwegianBlue would be thematically appropriate ;)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
rcGIS, Maya, etc) that already build
their own Python from source with the same C/C++ compiler that they
use to build the rest of the application (so arbitrary Python C
extensions aren't supported).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
efault/Lib/test/crashers/ (if any
of the crashers can't be readily resolved).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-de
d give folks a few weeks
to start preparing launch binaries if they want to do so, rather than
the single week planned between the rc and the final release.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mai
maybe_pyexpr: (atom | TEXT)+
That isn't quite right, since it doesn't properly account for brace
nesting, but it gives the general idea - there's an initial really
simple tokenising pass that picks out the potential Python
expressions, and then those are run through the AST parser's
equivalent of
On 25 October 2016 at 17:25, Nick Coghlan <ncogh...@gmail.com> wrote:
> as well as Yury's new
> libuv-based ``uvloop`` asyncio event loop implementation.
Oops, I phrased that badly - the default asyncio event loop
implementation is still pure Python, but uvloop is a drop-in
r level buffer
manipulation library between now and the Python 3.7 feature freeze in
12+ months, as I think that will have longer term pay-offs well beyond
the scope of the original use cases :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 22 October 2016 at 16:05, Nathaniel Smith <n...@pobox.com> wrote:
> On Fri, Oct 21, 2016 at 8:32 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> But PEP 442 already broke all that :-). Now weakref callbacks can
> happen before __del__, and they can happen on o
fically here, as Armin Ronacher recently wrote an excellent post
about that in relation to some performance improvement work they were
doing at Sentry:
https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
ng a strong
reference means losing the main "reasoning about software" benefit
that weakref callbacks offer: they currently can't resurrect the
object they relate to (since they never receive a strong reference to
it), so it nominally doesn't matter
?"
By contrast, if we instead say "We want Python to natively support
efficient. readily discoverable, IO buffer manipulation", then folks
can ask "What's preventing us from providing an `iobuffers` module
today?" and start working towards that end goal (just as
the&
start being
useful for troubleshooting
- the SSL/TLS changes mean that some redistributed versions of Python
2.7 are starting to accumulate significant backports that aren't
indicated in the nominal upstream version number, but are conveyed in
the full REPL header (which has redistributor b
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
www.curiousefficiency.org/posts/2015/10/languages-to-improve-your-python.html
which looks at some other ways in which dismissing ecosystems out of
hand can inhibit our ability to learn from both their mistakes and
their successes.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 13 October 2016 at 12:54, Nick Coghlan <ncogh...@gmail.com> wrote:
> Method proliferation on builtins is a Big Deal(TM)
I wanted to quantify this concept, so here's a quick metric that helps
convey how every time we add a new builtin method we're immediately
making Python harder to c
. The notion of "we shouldn't need to define our own domain
specific helper libraries" isn't a given for standard library modules
any more than it is for 3rd party ones.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
/offset API design is also problematic due to the way
it differs from range() & slice(), but I don't think it makes sense to
get into that kind of detail before discussing the larger question of
adding a new helper module for working efficiently with memory buffers
vs further widening the method AP
ics, and the rules for GIL-independent
source code would become:
- new references must be decref'ed using the normal APIs
- borrowed references must be decref'ed using the PyBorrowed* APIs
(with a no-op compatibility shim for older GIL-only CPython versions)
Regards,
Nic
hurn and improving cross-version and
cross-implementation compatibility, doing that also lets the *reader*
of the code know that the key iteration order matters.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Pytho
*is* documented under __future__, but not under
> exec/eval. I'm just suggesting adding another cross-reference.
The most appropriate cross-reference would probably be to the
compile() docs rather than the language reference though:
https://docs.python.org/2/library/functions.html#comp
?
>>
> An alternative might be a subclass of int.
It could make sense to use a subclass of int that emitted deprecation
warnings for integer arithmetic, and then eventually disallowed it
entirely.
Cheers,
Nick.
--
Nick Coghlan | ncogh...
r how trivial the specific change needed is if
getting it resolved and a new version published turns out to require a
transfer of project ownership - the cost is in the ownership change
rather than the software change itself.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Aust
o *3.5* (or Python 3 at all in the case of Jython and
IronPython), I think we still have a good few years to ponder the
question before this particular concern starts cropping up in practise
:)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
mework developers, and application developers that support "bring
your own Python runtime" deployments, *not* on interpreter
implementers.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
P
On 11 September 2016 at 13:05, Nick Coghlan <ncogh...@gmail.com> wrote:
> VOC & Batavia *should* be OK (worst case, they return
> collections.OrderedDict from __prepare__ and also use it for __dict__
> attributes), but I'm less certain about MicroPython (since I don't
> kno
de for cross-version and
cross-implementation compatibility - the popularity of explicit
context management being one of the most significant examples of that,
as it's far more necessary on implementations that don't use automatic
reference counting the way CPython does.
Cheers,
Nick.
--
Nick Coghlan | ncog
On 11 September 2016 at 07:26, Guido van Rossum <gu...@python.org> wrote:
> On Sat, Sep 10, 2016 at 10:57 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> On 11 September 2016 at 03:08, Guido van Rossum <gu...@python.org> wrote:
>>> So I'm happy to contin
On 11 September 2016 at 05:20, Christian Heimes <christ...@python.org> wrote:
> On 2016-09-10 17:24, Nick Coghlan wrote:
>> On 11 September 2016 at 00:22, Christian Heimes <christ...@python.org> wrote:
>>> First I like to deprecated some old APIs and favor of SSLCot
st time around in thinking it would still
be necessary even if class namespaces became order preserving :)
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mail
Nick.
P.S. Although in this case, it may have just been a direct link to the
3.2 version of the 3.2 What's New - there isn't a lot we can do about
that, as when a branch goes unsupported, we usually stop updating the
docs as well (even when external links break)
--
Nick Coghlan | ncogh...@gm
cular goal is from a
broader industry perspective, people don't tend to react to API breaks
by fixing their code - they react by not upgrading at all.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev maili
On 10 September 2016 at 19:27, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 10 September 2016 at 17:49, Ethan Furman <et...@stoneleaf.us> wrote:
>> The "mostly" is what concerns me. Much like having a custom __dir__ lets
>> a class fine-tune what is of in
st as well for
config files as it does for module and attribute names.
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
Unsu
ulty -
__definition_order__ wasn't just there as a CPython implementation
detail, it was there as a way to allow class and metaclass developers
to hide their *own* irrelevant implementation details.
Since __definition_order__ was already accepted, and the rationale for
removing it is incor
On 8 September 2016 at 03:37, Guido van Rossum <gu...@python.org> wrote:
> On Sun, Sep 4, 2016 at 11:58 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> While calling system native apps that way will still have many
>> portability challenges, there are also plen
of access to asyncio internals are currently needed to
implement 3rd party Transport classes, and perhaps lead to related
future additions to the public API.
Pending Amber's response, a definite thumbs up from me for removing
the provisional caveat, and congratulations on a provisional
experiment pro
more automated refactorings that simplify their
code.
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://
801 - 900 of 6273 matches
Mail list logo
