On 23 Jul 2015 01:36, "Nikolaus Rath" wrote:
>
> On Jul 22 2015, Nick Coghlan wrote:
> > On 22 July 2015 at 13:23, Nikolaus Rath wrote:
> >> If it were up to me, I'd focus all the resources of the PSF on reducing
> >> this backlog - be that by
onale for me, although I also wonder if it might be useful for
making some interesting COM and dbus based API wrappers.
Ronald, could you dig up a reference to the last thread (or threads)
on this? My recollection is that we were actually pretty happy with
it, and it was just set aside through l
ns is a better option for automated daily posts.
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://m
orld of pain as you try to figure out
the source of any related bugs.
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
ms plausible to me
that such an approach may also work well for datetime arithmetic that
presents the appearance of all datetime arithmetic taking place in
terms of UTC, that's a guess based on general principles, not
something based on a detailed knowledge of datetime in particular
(and, in
ort.c (Py2) and moduleobject.c (Py3) regarding how a module
>> obtains it's fully qualified package name (see item 1).
Yes, these weird limitations were the genesis of Petr Viktorin's
efforts in implementing a new approach to import extension modules for
Python 3.5: https://www.pyth
27;t think that would be the right way to create such a guide for a
volunteer driven project like CPython, but steering a more
collaborative community discussion would require substantially more
time than it took me to put the Beaker one together.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@
ld* be made.
Whether or not to do that would be up to the folks with a specific
interest in working with dates and times, though.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python
atible API
change*, reducing the practical long term design risk of postponing a
particular aspect of a decision to near zero.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.
dditional options related to whether the build
dependencies should be installed or not, and give downstream vendors a
free pass to exclude the build dependencies from the default
installation set.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
int on production systems, the wheel package itself has no
business being installed anywhere other than developer systems and
build servers.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing lis
On 6 August 2015 at 09:29, Victor Stinner wrote:
> Le 5 août 2015 17:12, "Nick Coghlan" a écrit :
>> A hard dependency on wheel wouldn't fit into the same category - when
>> folks are using a build pipeline to minimise the installation
>> footprint on producti
On 6 August 2015 at 19:04, Robert Collins wrote:
> On 6 August 2015 at 15:04, Nick Coghlan wrote:
> When I consider the harm to a production pipeline that using
> setuptools can cause (in that it triggers easy_install, and
> easy_install has AFAIK none of the security improvements p
option name might be something like
"--no-build-tools", and could also be added to the public pyvenv and
virtualenv interfaces.
Downstream in Fedora, now that we have weak dependency support, I'd
advocate for switching the python->setuptools dependency over to
Recommends, and a
for cases where you have your own code you want to build, but can't go
to the internet to get a build toolchain.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://
OS X is at risk of falling by the wayside in the Python
community, but if those of us that care specifically about the
viability of desktop Linux as a platform for open source development
stand by and let that happen, then we'll *deserve* the consequences.
Regards,
Nick.
--
Nick Coghlan
ython-3 'u' prefix also finds new life as
a way of always requesting the default string interpolation, even if
__interpolate__ has been overridden in the current namespace to mean
something else (like il8n string translation).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | B
lane for the US in a few hours, so I'll be aiming
to be bad at responding to emails until the 17th or so. We'll see how
well I stick to that plan :)
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing l
On 8 August 2015 at 19:34, Nick Coghlan wrote:
> On 8 August 2015 at 11:39, Eric V. Smith wrote:
>> Following a long discussion on python-ideas, I've posted my draft of
>> PEP-498. It describes the "f-string" approach that was the subject of
>> the "Bri
n (__interpolateu__ instead of __interpolate__).
There's no change to the semantics of u"" - those remain identical to
"".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing lis
"
target that enables PGO with an appropriate training set from
regrtest, and also complains if "--with-pydebug" is configured?
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-
not going to be taking it out, but it's also the case that a
comparatively broad API like asyncio may take a couple of feature
release cycles to settle down to a point where we can declare it
sufficiently complete that we're only going to add new interfaces in
fu
ng maintenance and release
management model, and then apply that new approach to at least asyncio
for 3.5.x, and consider modularising the development and release
cycles for other components of interest in 3.6+ (and potentially 2.7.x
in some cases).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.c
- the most I see us
doing is potentially shifting to a "bundled 3rd party library" update
model if there's still a high churn rate in the API after another
release cycle.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
eventually realised it made more sense as an optional extension to PEP
498 that exposed the inner workings of the scope aware interpolation
machinery to Python code.
As part of that, I'm +1 on PEP 498's literal string interpolation syntax.
Regards,
Nick.
--
Nick Coghlan | nc
On 1 Sep 2015 07:35, "Eric V. Smith" wrote:
>
> But back to PEP 498: I can't imagine accepting either PEP 501 or 502
> without also accepting PEP 498. And once you've accepted 498, are i- or
> e-strings sufficiently powerful and useful enough, and are they likely
> to be used in the correct way? I
hat pattern wouldn't actually call a
system shell, it would invoke something like Julia's command system.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
ht
king our time and seeing how far we can get with just eager
rendering. If cases emerge where the lack of delayed rendering support
is keenly felt, then it isn't hard to resurrect a deferred PEP.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
n as Terry, but you're right,
seeing the warning under 3.x will suffice in these cases.
So +1 for simple deprecation without removal until after 2.7 enters
security fix only mode.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 16 Sep 2015 7:43 am, "Larry Hastings" wrote:
>
>
> I don't follow. Because you're an advocate of Python switching to git
and GitHub, we should have a git tutorial committed as a Python Enhancement
Proposal?
>
> I'm not attempting to stir up a conversation about git vs hg. I only
question the
On 16 Sep 2015 18:48, "Paul Moore" wrote:
>
> On 16 September 2015 at 06:10, Stephen J. Turnbull
wrote:
> > The only thing that hg really lost badly on
> > IMO was "named branches", and that's been fixed with bookmarks.
>
> FWIW, I still find bookmarks confusing to use compared to git
> branche
hat "pyvenv"
will still run even if you're in an activated Python 2 virtual
environment, while "python -m venv" fails. The answer is to use a
qualified Python version in the latter call.
I assume the change to the script will include forcing that particular
deprecation warning
On 19 September 2015 at 01:16, Barry Warsaw wrote:
> On Sep 18, 2015, at 07:53 PM, Nick Coghlan wrote:
>
>>I currently use pyvenv directly, but I agree with starting a migration
>>to only supporting the more explicit "python -m venv". There's always
>
On 19 Sep 2015 15:40, "Stephen J. Turnbull" wrote:
>
> Mark Lawrence writes:
>
> > I agree very strongly with your point here. Raising umpteen issues
> > over installation failures when a full release comes out strikes me
> > as below the belt when there have been multiple previous releases
>
t; ever).
Does this mean overriding format at the module level or in builtins
will affect the way f-strings are evaluated at runtime? (I don't have
a strong preference one way or the other, but I think the PEP should
be explicit as to the expected behaviour rath
details of the
unfortunately manual Windows installation testing process at the end.
It might be interesting to see if running the installs at least in
quiet mode could be automated on Appveyor to reduce the manual testing
requirements.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.c
On 21 September 2015 at 05:22, Eric V. Smith wrote:
>
>> On Sep 20, 2015, at 11:15 AM, Serhiy Storchaka wrote:
>>
>>> On 20.09.15 16:51, Eric V. Smith wrote:
>>>> On 9/20/2015 8:37 AM, Nick Coghlan wrote:
>>>>> On 19 September 2015 at 21
age)" function that's implemented as:
def warn_deprecated(message, stacklevel=1):
return warnings.warn(message, DeprecationWarning,
stacklevel=(2+stacklevel)).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
On 22 Sep 2015 03:16, "Serhiy Storchaka" wrote:
>
> On 21.09.15 12:05, Nick Coghlan wrote:
>>
>> As Victor notes, though, that's not the right default for *scripts*
>> that are issuing deprecation warnings to end users - there, they
>> really are de
e conflict between container membership invariants and floating
point NaN values (and this one is even more subtle).
I'm reading through the full PEP now, and really appreciating the
thorough write up. Thanks to Alexander and Tim, and to all the folks
involved in the extensive discussions!
On 22 September 2015 at 13:33, Nick Coghlan wrote:
> On 22 September 2015 at 08:03, Guido van Rossum wrote:
>> Just so people know, over at the datetime-sig I've accepted PEP 495, which
>> adds a fold flag to datetime objects to distinguish ambiguous times. This
>&g
(dt.timestamp())
For unambiguous times and times in the fold, that's a subset of the
stronger invariant:
dt == dt.astimezone(utc).astimezone(dt.tzinfo) ==
datetime.fromtimestamp(dt.timestamp())
That stronger invariant is the one that *doesn't* hold for times in
the gap, as with fold=0
On 24 Sep 2015 01:21, "Tim Peters" wrote:
>
> Guido's reply gave a clearer invariant:
>
> dt.timestamp() ==
> dt.astimezone(utc).timestamp() ==
> dt.astimezone().timestamp()
>
> That's the key point. If the timestamps are equivalent, then it
> follows that conversions to UTC are equi
e discussion, review and pronouncement on the PEP
will occur.
=
(From https://www.python.org/dev/peps/pep-0001/#pep-review-resolution )
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing li
On 2 October 2015 at 17:18, Victor Stinner wrote:
> What do you think? Should we add sys.debug_build?
Spell it as "sys.implementation.debug_build" and I'm in favour.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | B
, I dug up the original Arch announcement
linked from PEP 394:
https://www.archlinux.org/news/python-is-now-python-3/
'twas a mere 5 years ago :)
Cheers,
Nick.
[1] https://fedoraproject.org/wiki/Releases/24/Schedule
--
Nick Coghlan | ncogh...@gm
while the
developers and other users of those projects were still running Python
2 based distributions themselves), as well as in revising distro
packaging policies to mandate Python 3 support for new projects.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
gration, and assure them that we'll help
them manage the shift in a minimally disruptive way.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
wanting to simulate die rolls should be using the random module
rather than the secrets module anyway, so the "only offer
secrets.randbelow()" approach Guido suggested in his last email makes
sense to me.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Austr
ass__ should *always* give the same answer,
even in subclasses.
Cheers,
Nick.
P.S. Proxy types are actually quite hard to right correctly, so if
anyone *does* need to implement one, they're likely to be best served
by starting with an existing library like wrapt:
http://wrapt.re
On 20 October 2015 at 11:33, Victor Stinner wrote:
> 2015-10-20 11:11 GMT+02:00 Nick Coghlan :
>> Folks wanting to simulate die rolls should be using the random module
>> rather than the secrets module anyway,
>
> Hum, why? Dices are used in Casino where security matters bec
o complement the existing
functools.singledispatch) rather than "typing.overload", this seems
like a reasonable short term solution to me.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing
rious b/r combinations:
['fB', 'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fb', 'fbR', 'fbr', 'fr',
'frB', 'frb']
I don't think it would ever be worth the compatibility break to
requi
ane Wirtel - http://wirtel.be - @matrixise
> ___
> 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/ncoghlan%40gmail.com
>
--
before it even
has a chance to start getting out of hand.
> one of the few undeniably good choices made in python 3.
There's no need here for passive aggressive snark directed at the
designers providing you with a free programming language. Folks have
the entire internet to complain abou
tion efforts :)
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/mailman/opt
that
still need improvement :)
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/mailma
import ConfigParser
config = ConfigParser.RawConfigParser()
config.read(_cert_verification_config)
try:
verify_mode = config.get('https', 'verify')
except (ConfigParser.NoSectionError, ConfigParser.NoOptionError):
verify_mode = 'pla
prompted me to do an update pass over
https://wiki.python.org/moin/Python3LinuxDistroPortingStatus, adding
these background links to the Python symlink section, and updating the
Fedora porting status link to refer to the recently published porting
DB: http://portingdb-encukou.rhcloud.com/
Regards,
Ni
entially be affected
by the changes to RHEL & CentOS 7.
Regards,
Nick.
[1] FreeIPA is an open source Identity Management & Authentication
system: http://www.freeipa.org/
>
> On Tue, Nov 10, 2015 at 4:47 PM, Nick Coghlan wrote:
>> Hi folks,
>>
>> I have a confessio
t approach available
(albeit as a PEP 466+476+493 patch set in the RHEL/CentOS system
Python 2.7.5 package) prompts other distro security teams to
reconsider those initial assessments, that would be a nice outcome,
but it isn't my own main priority (so Guido makes a good point in
favouring finding
ory
string, direct script execution is currently the odd one out in *not*
reading the entire source file into memory first, so Serhiy's proposed
simplification of the implementation makes sense to me.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
hange like this in a maintenance release, but for
a new feature release, the consistency gain is definitely worth it.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python
On 11 November 2015 at 10:47, Nick Coghlan wrote:
> Our last discussion back in July seemed to show that folks either
> didn't care about the question (because they're using unmodified
> upstream versions so the PEP didn't affect them), or else thought the
> approa
at browsers have provided a pretty good
forcing function in getting folks to use properly signed certificates,
at least on the public internet, but self-signed and improperly signed
certificates are still significantly more common for other protocols.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@
;s
available, and otherwise has its own implementation.
Cheers,
Nick.
[1] https://pythonhosted.org/setuptools/history.html#id159
[2] https://pythonhosted.org/setuptools/history.html#id80
[3] https://pythonhosted.org/setuptools/history.html#id123
--
Nick Coghlan | ncogh...@gmail.com | Br
fecycle, that has the potential to reach quite a few systems that
otherwise wouldn't benefit from the change until well after Ubuntu
16.04 is released next year.
Regards,
Nick.
[1] http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-9365.html
--
Nick Coghlan | ncogh..
On 24 November 2015 at 12:05, Barry Warsaw wrote:
> On Nov 17, 2015, at 11:44 PM, Nick Coghlan wrote:
>
>>For Debian, Ubuntu and SUSE, their original determinations for the
>>relevant CVE were "too intrusive to backport", so folks currently need
>>to upgrade to
On 24 November 2015 at 11:59, Barry Warsaw wrote:
> On Nov 24, 2015, at 10:18 AM, Nick Coghlan wrote:
>
>>Since we already know Red Hat are OK with the draft recommendations,
>>and I missed the RHEL 7.2 release date anyway, perhaps Barry or
>>Matthias might be interested
On 24 Nov 2015 8:12 pm, "Paul Moore" wrote:
>
> On 24 November 2015 at 03:46, Nick Coghlan wrote:
> > I think there are three relevant categories here:
> >
> > 1. Folks who assume that "https" means the same thing in Python that
> > it means
patching - you know there are risks
with doing it, but also judge the near term benefits to outweigh those
longer term risks in your particular situation.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev m
On 25 Nov 2015 05:42, "Toshio Kuratomi" wrote:
> >
>
> Yeah, I think you are correct in your understanding of what actual
> changes to the python distrribution are being proposed for
> redistributors in the PEP. Reading through the PEP again, I'm not
> sure if I'm correct in thinking that this o
f the
setattr slot in the proxy.
So it looks to me like replicating the NULL-handling behaviour of the
slots in the public Set* APIs was intentional, and it's just the
documentation of that detail that was missed (since most folks
presumably use the Del* convenience APIs instead).
Regards
that PEP, then the fact that SELinux
offers "setenforce 0" and AppArmor can be turned off with a kernel
boot option can be used as examples of platform developers letting end
users make their own security decisions, even if the platform provider
recommends leaving the more opinionated
ot;
for Python 2.7.12, 3.4.4, 3.5.2 and 3.6 upstream would be fine by me,
since that would also significantly clarify the fact that the two
ideas are entirely orthogonal to each other (except for the need to
define a relative priority when you combine the two).
Regards,
Nick.
--
Nick Coghlan
On 27 November 2015 at 03:15, Barry Warsaw wrote:
> On Nov 26, 2015, at 03:06 PM, Nick Coghlan wrote:
>
>>I'm not a big fan of it either, but it's the way sustainable
>>commercial open source distribution works in practice:
>
> While it's inevitable t
On 27 November 2015 at 10:52, Nick Coghlan wrote:
> On 27 November 2015 at 03:15, Barry Warsaw wrote:
>> On Nov 26, 2015, at 03:06 PM, Nick Coghlan wrote:
>>>In this particular case, the migration problems were already raised in
>>>the PEP 476 discussions, and th
On 27 November 2015 at 17:42, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > This is a significant rewrite that switches the PEP to a Standards
> > Track PEP proposing two new features for 2.7.12+: an
> > "ssl._verify_https_certificates()&q
ectly) from
__main__.
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/option
On 2 December 2015 at 01:50, Serhiy Storchaka wrote:
> On 25.11.15 08:39, Nick Coghlan wrote:
>> So it looks to me like replicating the NULL-handling behaviour of the
>> slots in the public Set* APIs was intentional, and it's just the
>> documentation of that detail t
in "we can't do it" territory,
since the benefit on offer through the deprecation process is only a
much easier debugging session when someone is trying to track down the
root cause of an unexpectedly missing attribute on an object.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail
On 3 December 2015 at 02:35, Guido van Rossum wrote:
> On Wed, Dec 2, 2015 at 7:32 AM, Emanuel Barry wrote:
>>
>> Nick Coghlan made a pretty elaborated blog post about that here:
>> http://opensource.com/life/14/9/why-python-4-wont-be-python-3
>
> I wholeheartedly
al() docs would need a slight adjustment to refer to
"literals (excluding container comprehensions and generator
expressions)", rather than the current "literals and container
displays".
Regards,
Nick.
[1] https://docs.python.org/dev/reference/lexical_analysis.html#literals
--
(Oops, I had a version of this reply sitting in my Drafts folder for a
week, and only noticed after pushing the most recent PEP update that
it had never been sent)
On 1 December 2015 at 06:32, Barry Warsaw wrote:
> On Nov 27, 2015, at 04:04 PM, Nick Coghlan wrote:
>
>>New draft p
ering as a class
decorator to "fill in" the other comparison implementations based on
the ones in the class body.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
h
aving "minimum supported version" for Windows and Mac OS X in the
"using" guide would likely make sense. For Linux, supported versions
are handled by redistributors, so the most we could do is offer
guidance to folks on checking their version and ensuring they're
looking at
ts and protocols (callback based API)
* 18.5.5. Streams (coroutine based API)
That's based on a sample size of one though (a friend for whom light
dawned once I explained that low-level=callbacks and
high-level=coroutines), which is why I hadn't written a patch for it.
Cheers,
Nick.
--
e to
another object, not just attributes
> 6. Py_REPLACE_REF
-0: this is like 3, only with a slightly longer name
I'm also in favour of Serhiy claiming the casting vote if there's no
clear consensus :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
f date is
likely to still be a challenge - for example, even considering just
the legacy distutils docs, the "3.1" and "2" docs appear in the
results at
https://www.google.com/search?q=registering+with+the+package+index+site%3Apython.org&ie=utf-8&oe=utf-8,
but the latest
he future.
So perhaps the combination that makes the most sense is to add
Py_REPLACE (uses Py_DECREF on destination) & Py_XREPLACE (uses
Py_XDECREF on destination) to the existing Py_CLEAR?
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
ne so in
Python yet (moving references in Rust isn't the same thing we're
talking about here - this is just normal runtime reference counting).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev
the docs build process, rather than
maintaining them by hand - something like that could be experimented
with outside CPython, and potentially incorporated into the dis module
docs if folks are able to figure out something that works well.
Regards,
Nick.
--
Nic
shouldn't* be necessary (it's why there's a separate
build step to freeze the import system), but it can be a useful
exercise to help figure out the source of the "unknown opcode"
problem.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 3 January 2016 at 16:32, Nick Coghlan wrote:
> For folks that are interested in that, folks that aren't following
> import-sig in addition to python-dev may want to take a look at
> Brett's design for the importlib.resources API:
> http://nbviewer.jupyte
folks that aren't following
import-sig in addition to python-dev may want to take a look at
Brett's design for the importlib.resources API:
http://nbviewer.jupyter.org/gist/brettcannon/9c4681a77a7fa09c5347
Cheers,
Nick.
P.S. If anyone actually *does* want a full "virtual fil
PEP text, and
keep their extensions to optional settings.
A similar approach may work for PEP 257, by clarifying which aspects
tools should be leaving to human judgement (beyond the question of
whether or not to opt in to following PEP 257 at all - it's far less
universal than PEP
f the nicest examples of this I've
seen (someone mentioned it last time this question came up):
http://php.net/supported-versions.php
Like a lot of things though, "yes, that's a good idea" is easy, having
it actually get to the top of someone's todo list is a different
question
that should exhibit any
Initialize/Finalize leaks:
https://github.com/python/cpython/blob/master/Programs/_testembed.c#L36
However, if there is one, our existing automated leak monitoring
unfortunately wouldn't pick it up, as the embedding tests run in a
subprocess rather than the ma
involves implementing PEP 489.
The actual multi-phase extension module import system from 489 was
implemented for 3.5, but indeed, the modules with stashed global state
haven't been converted yet.
I didn't think we loaded any of those by default, though...
Cheers,
Nick.
--
Nick
if it did, there'd be segfaults rather than memory growth when modules
keep pointers across Initialize/Finalize cycles).
Building with PYMALLOC_DEBUG and setting PYTHONMALLOCSTATS in the
environment will cause it to dump debugging info during Py_Finalize.
Building with Py_TRACE_REFS and setti
801 - 900 of 6587 matches
Mail list logo
