n applying the lessons they've already
learned to the CPython experience)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an
On Sat, 15 May 2021, 6:35 am Paul Moore, wrote:
> On Fri, 14 May 2021 at 21:18, Senthil Kumaran wrote:
>
> > > In other words, this isn't a technology problem, it's a people
> > > problem.
> >
> > Both. I didn't suggest this is technology problem. We, have to
> > choose one as per majority conve
On Tue, 9 Feb 2021, 8:18 am Terry Reedy, wrote:
>
> The one thing I think needs to be discussed and not been much, at least
> not publicly that I have seen, is whether we really want to go down the
> road of contextual keywords. There are some negatives as well as
> positives. Just because the
On Tue, 9 Feb 2021, 6:21 am Python Steering Council, <
steering-coun...@python.org> wrote:
> After much deliberation, the Python Steering Council is happy to announce
> that we have chosen to accept PEP 634, and its companion PEPs 635 and 636,
> collectively known as the Pattern Matching PEPs. We
I think you had good reason to call it EnumMeta though: to better
distinguish "the enum meta type" (i.e. EnumMeta) from "enum types" (i.e.
instances of EnumMeta).
Cheers,
Nick.
On Sat, 23 Jan 2021, 9:17 am Ethan Furman, wrote:
> The question:
>
>Can we change the name of classes if we keep
Congratulations, all!
Regards,
Nick.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archiv
As the PEP notes, the PyPA devs already assumed this is what would happen
for ambiguous version numbers, so it looks good to me.
Cheers,
Nick.
On Thu., 22 Oct. 2020, 5:58 am Brett Cannon, wrote:
> https://www.python.org/dev/peps/pep-0641/ (once the cron job runs)
>
>
> https://discuss.python.or
Thank you, Larry!
Cheers,
Nick.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
Enabling that workaround for embedders using threads without coroutines
while figuring out the real underlying contextvars issue seems like a
reasonable change to make in the maintenance branches.
Cheers,
Nick.
___
python-committers mailing list -- pytho
g to being marked as inactive that this was happening
(as it had to be inferred from the absence of your name, rather than
being called out as a list of voters that had been flagged as
potentially inactive since the last voter roll was generated).
Cheers,
Nick.
--
Nick Coghlan | ncogh
esulted in my not being
able to be as active and constructive a participant in the SC as I
would have wished.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list -- python-committers@pytho
Huzzah!
Thank you to you and the rest of the release team for coordinating this,
and to everyone that contributed changes and fixes :)
Cheers,
Nick.
On Tue., 15 Oct. 2019, 6:24 am Łukasz Langa, wrote:
> On behalf of the Python development community and the Python 3.8 release
> team, I’m pleas
we'll be
> seeing RC1 out tonight.
I've filed https://bugs.python.org/issue38326 as a release blocker, as
I don't think we should be cutting RCs when changes have been made to
a PEP-approved API without any pre-merge design discussion.
Cheers,
Nick.
--
Nick
On Tue., 12 Feb. 2019, 7:18 am Brett Cannon
>
> On Mon, Feb 11, 2019 at 10:26 AM Victor Stinner
> wrote:
>
>> Le lun. 11 févr. 2019 à 18:58, Carol Willing a
>> écrit :
>> > PS Copying the steering council in case someone has a different view.
>>
>> So you chose a mailing list and not Discourse?
in a position to handle the uncertainty associated
with being accepted as a speaker, but then having to wait to see if
their financial aid was approved before they could accept the speaking
slot.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
t page, or the preceding page with the final
submit button).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/pyt
LTS :-) We
>> would need a group of people reviewing individual 3.6 pull requests to
>> decide to pick them or not. I would volunteer to review these PRs and
>> merge them.
>>
>> The idea isn't new, Nick Coghlan proposed a "ELPython" last year:
>>
e just in
bugs.python.org (which is necessarily linked on GitHub usernames, as
otherwise the CLA check wouldn't pass).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-c
ach other or the status quo for it to be likely
that a significant proportion of the folks voting will find any of
them completely unacceptable)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-comm
On Sat., 29 Sep. 2018, 7:40 pm Łukasz Langa, wrote:
>
> On Sep 29, 2018, at 09:53, Nick Coghlan wrote:
>
> Especially on the eve of critical governance discussions that will heavily
> impact the future of python-dev.
>
>
> Ironically it's the very gravity of those u
On Sat., 29 Sep. 2018, 11:19 am Barry Warsaw, wrote:
> On Sep 28, 2018, at 17:45, Łukasz Langa wrote:
>
> > Do you use NNTP? Like with IRC, you won't find the next generation of
> core developers on it. And no, there is no support for it in Discourse.
> >
> > We could probably figure something o
l collation orders, but if we find
one where it isn't, then we'd just specify a collation order to use
for Python version comparisons)
Cheers,
Nick.
[1] https://www.python.org/dev/peps/pep-0425/#python-tag
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
gs (either already including an "X.Y" separator,
or stating that "X_Y" should be used when "XY" would be ambiguous), we
can expect actually making such a release to find latent defects in
assorted different pieces of software. However, unlike the
re to help BDFL-Delegates out
when it came time to end discussion of a proposal and make their
decision (whether for or against) stick.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing lis
On Sat, 15 Sep 2018 at 05:28, Raymond Hettinger
wrote:
>
> At the developer sprints this week, we collectively decided to grant core
> committer status to Emily and Lisa.
Congratulations, and welcome!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane,
On Sat, 15 Sep 2018 at 07:02, Zachary Ware wrote:
>
> Hi all,
>
> Most of my effort this week has gone into improving the state of
> buildbot.python.org, which has largely gone into improving Buildbot
> itself.
[snip]
Very nice!
Cheers,
Nick.
--
Nick Coghlan |
like keeping
weeds away and helping to provide water and appropriate amounts of
sunlight, rather than trying to tell the individual plants how to grow
leaves and flowers :)
[1] http://community.redhat.com/blog/2017/05/let-the-river-flow/
[2] https://community.redhat.com/blog/2017/05/seeds-
ld be different, but the
overall tone would be similar.
And I think that's inevitable in an environment driven primarily by
volunteer and sponsored development: the time to pursue particular
activities has to come from somewhere, and that's either going to be
the intrinsic motivations of indiv
should be thinking about how to reduce the demand for language
level churn rather than worrying too much about how to enable more of
it does mean that I'm entirely comfortable with the idea of postponing
any further syntax changes beyond PEP 572 to Python 3.9 or later.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
On 14 July 2018 at 19:36, Paul Moore wrote:
> On 14 July 2018 at 08:05, Nick Coghlan wrote:
>> So stealing Brett's excellent suggestion of "Design Steward" as a
>> BDFL-independent term for the current BDFL-Delegate role, a potential
>> PEP 1 amendment
EP is due to a
generally supported change's design complexity, rather than due to it
being a particularly controversial decision on whether or not to do
anything at all.
Cheers,
Nick.
[1] https://www.python.org/dev/peps/pep-0001/#pep-review-resolution
[2] https://www.pypa.io/en/latest/spe
llows you to
rediscover the fun parts of contributing without the burden of always
needing to be the ultimately responsible decision maker :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing
efinitely good to be
careful, we also have lots of systems in place to help us correct
course when we inevitably do make mistakes :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing li
gave instructions on how
to request reactivation (likely just "Check the developer guide to
ensure you're up to speed with any changes since you were last active,
then past to python-committers requesting that your credentials be
reactivated").
Cheers
oad old Microsoft swag ;)
>
I was going to suggest you ask the Azure dev advocates to come up with
something involving their mascot Bit, and then I noticed the last entry on
https://github.com/ashleymcnamara/Developer-Advocate-Bit#find-me-on-twitter
:)
Cheers,
Nick.
--
Nick Coghlan |
On 3 June 2018 at 17:00, Nick Coghlan wrote:
> I'll also email Maciej & EW Durbin ([1]) to see if they've had a chance to
> discuss the rehosting plans for bugs.python.org yet.
>
The status update here is that Maciej has been bringing Ernest up to speed
on the preparator
et.
Cheers,
Nick.
[1] the PSF's new Director of Infrastructure [2], who some folks may
already know from his extensive work on PyPI and other parts of the PSF
infrastructure, as well as chairing Python US in 2018/19
[2] https://twitter.com/EWDurbin/status/10015
making them more thorough?).
Cheers,
Nick.
[1] https://www.openhub.net/p/python
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
e a release blocker and
asking the RM to take a look it at
The RM then makes their decision by either commenting to say they're
accepting the issue as a blocker, bumping it down to deferred blocker (if
they don't think it's a blocker *yet*),
use regularly
- meeting our original GitHub migration commitment to continue offering a
way of engaging with the core development process without requiring
accounts with any entity other than the PSF
It's far from being a foregone conclusion that migrating to a new issue
tracker will be the preferr
ufficient further concerns to push the whole
concept back into python-ideas territory. (I do think the discussions have
clarified the nature of the cases where the current lack of any form of
inline binding support can be genuinely irritating, though)
--
Nick Coghlan | ncogh...@gmail.com |
, and
this mailing list.
Welcome, Petr! :)
Cheers,
Nick.
P.S. When adjusting the nosy list on the issue tracker, you'll find
there's also a new "extension modules" topic, which can be selected to
subscribe both Petr and I to the issue :)
--
Nick Coghlan | ncogh...@gmail
EL, and CentOS (he's the current
Python maintenance team lead at Red Hat), and he also has a lot of
practical Python 2->3 porting experience (as a result of coordinating
much of the migration effort for Fedora and RHEL, including leading
the creation of
https://portingguide.readthedocs.io/
l that's
> needed!)
>
You didn't miss it - https://devguide.python.org/committing/ is still
pretty much written for the old approach of merging on the command line.
So a devguide issue would definltely be appropriate, and if you're so
inclined, even a PR with the docs that you wish had
t;
Huzzah, thank you!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https
do the backport PR reviews as soon as
Miss Islington creates them means I'll still have the original review
fresh in my mind. (I know I can theoretically do that now, but I
currently tend not to look at the details of the backport PRs until
the CI run is finished)
Cheers,
Nick.
--
Nick Coghlan
that we don't backport to
3.7.
Whereas the cherry picking just outright failed on 3.6 because the
current state of the frozen importlib on that branch is different.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
may be able to at least have CI fail if
"make regen-all" actually changes any file contents for checked in
files.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-com
will also have a fair incentive to solve the problem (although
in that case, their resolution might be "switch back to using OpenSSL given
the improvement over the past couple of years").
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.co
I was still running, and then never got back to actually merge
them).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/list
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
ey're not
available to search engines).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
jectively data-driven - when volunteers are mentoring and managing
other volunteers, it's even easier for unconscious biases to come into
play than it is in a more explicitly professional setting.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
step in triage for problems
encountered with redistributor builds: if a problem only shows up in
the distro version, then distro specific patches would be the first
place to look.
Cheers,
Nick.
P.S. This thread would probably be better located on python-dev
, "For most users, if it isn't documented, it may as well not
exist" :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.pytho
t;> 2007: around 783k lines
>> 2010: around 683k lines
>
> What happened between 2007 and 2010 that the source shrank by nearly
> 13%?
My guess would be that it's a consequence of Python 3 becoming the
default branch.
Cheers,
Nick.
-
im completely.
+1 from me - I found him very receptive to feedback and easy to work
with when discuss his proposed changes to the runtime typing
machinery.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers ma
behaviour that it addresses has been around for a decade and a half,
so I don't think anyone is really going to care all that much whether
it gets fixed in 2018 or in 2019.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
pyth
On 6 November 2017 at 02:02, Yury Selivanov wrote:
> On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan wrote:
>> The current lack of DeprecationWarnings in 3.6 is a fairly major
>> oversight/bug, though:
>
> There's no oversight. We had PendingDeprecationWarning for
>
lp", "copyright", "credits" or "license" for more information.
>>> await = 1
>>> async = 1
>>> print(async, await)
1 1
So if we're going to go ahead with making them real keywords in 3.7
(as specified in PEP 4
cess. Currently,
that tends to only happen informally, by virtue of an existing core
dev reviewing quite a few of a contributor's patches, and then asking
if becoming a core developer themselves is a goal they've considered.
There are some additional responsibilities liste
or I'm
working on a separate change that would end up conflicting with their
PR if I left theirs open.
That way if they think of an alternative approach that they'd prefer
to use, they can still just amend their existing PR and ask for an
additional review, rather than having t
static set of machines that work through
the merged commits.
Cheers,
NIck.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo
> users mapping with last rules trumps all semantic. We have
> to be careful to not override parts of a previous rules. I believe teams
> reduce the burden.
+1 for setting up teams, and +1 for an importlib-team :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
eboot our
client machine. As Inada-san notes, the password prompt when
accidentally doing a direct push to a HTTPS clone then serves as a
reminder that you probably meant to push to a different remote that's
set up for read/write access over SSH.
There's no functional difference on the se
if the result changed), or deleting the new one
(if it is the same as the original).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.
that (it doesn't allow self-review
at all, not even to mark your own PRs as still requiring further
changes).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers
to thanking the folks working on the migration and the
associated automation, I'd also like to explicitly thank Mariatta,
Terry, Zachary, and everyone else that has contributed to the git
cheatsheet and other workflow documentation updates in the developer's
guide.
Cheers,
Nick.
--
Nick C
ack before (or in parallel with) scheduling
the CI run itself.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-co
y're close enough in spirit that folks familiar with
one won't have any problems adapting to the other.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@pyt
y really want to do
so. The Developer Guide has the necessary details:
https://docs.python.org/devguide/committing.html#what-s-new-and-news-entries
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committe
On 15 June 2017 at 19:35, Nick Coghlan wrote:
> On 15 June 2017 at 00:40, Victor Stinner wrote:
>> A recent example is Nick Coghlan's implementation of the PEP 538:
>> basically, it broke all buildbots... except of Linux and Windows :-)
>> And it will take a few mor
likely to be intermittent for a while, so the buildbot for
may be unreliable until ".
That way, other folks that care about the platform may be more alert
to resolving platform specific issues during that time (and may even
be able to take over the lead platf
backport
> PR that triggered the label removal.
Very cool, thank you!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman
On 15 June 2017 at 23:38, Victor Stinner wrote:
> 2017-06-15 5:31 GMT+02:00 Nick Coghlan :
>> For example, something that would be genuinely helpful would be a bot
>> monitoring PR comments that could automate the "custom-build" dance
>> for core developers (i.e.
ps://bugs.python.org/issue30672
[3] https://bugs.python.org/issue30565#msg296006
[4] https://bugs.python.org/issue30647
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https:
the change
2. Post a "BuildBot: test custom build" comment on the offending PR
3. Original PR author, committer, and anyone else interested continues
the issue resolution process based on the specific links posted back
by the helper bot
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail
th the sprint name.
Cheers,
Nick.
[1] https://public.etherpad-mozilla.org/p/pycon-pune-2017-cpython-sprint
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.p
" alias mentioned there is detailed a few entries
earlier in the cheat sheet
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/py
finite +1 from me (I was actually thinking of emailing Carol about
the idea before I saw this thread)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://m
fers-payment-to-port-to-python.html
I know at least one former upstream Roundup developer recently moved
into freelance software development & consulting, so I'll chat to him
to see if he has any suggestions for possible ways forward here.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gm
ntially
reported Code of Conduct concerns. Handling of the latter will remain
with the PSF Board or their appointed representatives, independently
of how we handle moderation of the development channels.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
ationale for retaining the latter relates to maintaining URL
stability, avoiding breaking our own and third party integrations,
preserving current email-based individual workflows, and maintaining a
PSF controlled archive of significant design decisions, rather than
any particular flaws in alter
ly than the nosy list on BPO, since it's based on the
actual files touched by a PR).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.pytho
kflow/issues/44)
>
> Added --abort/--continue options to address
> https://github.com/python/core-workflow/issues/45
>
> Lastly, I added --status option, which will just perform `git status` for
> the cpython directory.
Thank you for the enhancements!
Cheers,
Nick.
--
Nick Cog
On 15 April 2017 at 03:15, Serhiy Storchaka wrote:
> On 14.04.17 17:02, Nick Coghlan wrote:
>> That was exactly my reaction when Serhiy pointed it out - I started to
>> argue the point, but then invalidated all my own arguments before
>> actually posting anything :)
>
&
On 12 April 2017 at 01:57, Guido van Rossum wrote:
> On Tue, Apr 11, 2017 at 7:42 AM, Nick Coghlan wrote:
>>
>> Since we do the squash & merge to get an atomic commit at the end, it
>> doesn't make sense to do any force pushes along the way.
>
>
> I w
gt;
> Some of our core committers need to learn to do this :)
Technically coming up with a meaningful message when committing
patches isn't a new requirement, but I admit it's a lot easier to
forget to clean things up when there's a big green button right in
front of you waiting to
confidential discussion of
sensitive matters
6. The Board are in a good position to request PSF staff assistance in
handling such matters when it seems appropriate to do so
If we started out by formalising that existing two level model of
resource-specific moderators + the PSF (as repres
spectful, and kind" guidance in the CoC would then
mostly apply to the channel moderators responsible for enforcing those
Rules for Active Participation, since CoC violations on the
communication channels themselves would *also* break the suggested
rules 1 & 2 a
ductive noise on GitHub
issues aren't anywhere near as well developed as those for email). If
there was finer granularity available on GitHub, the suspension would
presumably have only been from the core-workflow repo specifically,
but that's not currently an available option.
Regards,
Nick.
-
On 26 March 2017 at 03:54, Antoine Pitrou wrote:
>
> Le 25/03/2017 à 16:27, Nick Coghlan a écrit :
>>
>> However, from the point of view of making it easier for Windows devs to
>> debug *nix debug errors, it probably makes more sense to use clang for
>> the main *nix
e gcc to do the coverage run.
That setup would give:
- all 3 default compilers running in CI (MSVC in Appveyor, clang for the
main Travis tests, gcc for the coverage run)
- Windows devs getting the friendlier clang error messages when they're
trying to debug a cross-platform compilation probl
rrent notifications to be more
useful, mainly by including the GitHub PR URL, rather than the
internal-to-roundup numeric PR ID.
I'd just forgotten about them until Paul mentioned them, as they're not
particularly useful right now :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.
herry-picking automation, I've been very happy with Mariatta's
utility, and I believe that with a few robustness tweaks and a
conflict-avoiding approach to handling Misc/NEWS it would be up to the task
of generating the actual PRs as well. (The other side of the bot that
actua
lpha", the base branch is
"/master"
- otherwise it is "/X.Y" (also based on sys.version_info)
Note that this works fine for "make patchcheck" (since it uses the just
built Python to run Tools/scripts/patchcheck.py), but anyone running the
tool directly rather than through
On 10 March 2017 at 04:32, Brett Cannon wrote:
>
>
> On Thu, 9 Mar 2017 at 04:07 Nick Coghlan wrote:
>
>> On 9 March 2017 at 19:30, Victor Stinner
>> wrote:
>>
>> Do we need need a kind of sandbox repository for experiments?
>>
>>
>> Mi
ork if you have merge access on the main repo).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
C
s 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-committers
n/cpython/blob/master/.mention-bot (as Guido has)
- if you want to find your own reviewers for your PRs, add yourself to the
PR blacklist in the same file (as Benjamin has)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
1 - 100 of 369 matches
Mail list logo
