stract.h" and into their own
"call.h" file (while leaving the concrete object API headers alone).
That gives a solid correlation between Include/call.h and
Objects/call.c, and I don't believe it's ever been the case that
abstract.h declared all the API f
g with that :)
> On Mon, Jun 25, 2018 at 4:44 AM Nick Coghlan wrote:
>>
>> Right, the proposed blunt solution to "Should I use 'NAME = EXPR' or
>> 'NAME := EXPR'?" bothers me a bit, but it's the implementation
>> implications of parent
that LSB drop Python entirely (similar to
what they did for Java, albeit for different reasons), and instead
recommend that portable applications requiring Python bundle their own
interpreter.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 27 June 2018 at 23:38, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> actually made those semantics available as an explicit
>> "parentlocal NAME" declaration ...:
>>
>> def _list_comp(_outermost_iter):
>> parentlocal item
>>
tends to somewhat user (and IDE!)
unfriendly.
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
On 23 May 2015 07:45, "Eric Snow" wrote:
>
> Hi all,
>
> After extended discussion over the last several months on import-sig,
> the resulting proposal for multi-phase (PEP 451) extension module
> initialization has finalized. The resulting PEP provides a clean,
> straight-forward, and backward-c
On 23 May 2015 01:15, "André Freitas" wrote:
>
> Hi there,
> My name is André Freitas, I'm 22 years old and I live in Portugal
(Porto). I'm currently finishing my Masters in Informatics and Computer
Science with a thesis in Mining Software Repositories, where I am able to
predict defects in Softwa
;s on the bug tracker as Berker
> described.
I filed http://bugs.python.org/issue24270 to track this, but there's a
fair bit of work to be done to integrate the changes into the existing
math module's code, tests and documentation.
And corr
execution mistake that
3.5's PEP 441 aimed to resolve :)
PEP 487 could then be updated to reference that PEP as part of the
rationale for dropping the "easy namespace customisation" aspect of
the proposal.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane,
On 24 May 2015 at 12:04, Nick Coghlan wrote:
> On 24 May 2015 at 11:15, Eric Snow wrote:
>> tl;dr Are there any objections to making making the default
>> cls.__prepare__ return OrderedDict instead of dict (and preserve that
>> order in a list on the class)?
>>
>
te the class body switched from being a basic dictionary to an
ordered one would be a hidden implementation detail, rather than
making all type objects a little bigger.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
P
On 24 May 2015 at 19:44, Mark Shannon wrote:
> On 24/05/15 10:35, Nick Coghlan wrote:
>> If we leave __definition_order__ out for the time being then, for the
>> vast majority of code, the fact that the ephemeral namespace used to
>> evaluate the class body switched from bei
On 25 May 2015 07:26, "Guido van Rossum" wrote:
>
> On Sun, May 24, 2015 at 1:36 PM, Eric Snow
wrote:
>>
>> My premise for storing the definition order on the class is that Guido
was okay with using OrderedDict for cls.__dict__, which is a bigger
change. Regardless, there are two reasons why it
On 26 May 2015 05:41, "Eric Snow" wrote:
>
> Regardless, I know there were a few folks (e.g. Yury) that wanted to
> see C OrderedDict in 3.5 and there may be others that would really
> like OrderedDict-by-default in 3.5 (Nick?).
I think it's the combination with PEP 487 that makes OrderedDict-by-
On 26 May 2015 23:25, "Paul Moore" wrote:
>
> On 26 May 2015 at 13:55, Steve Dower wrote:
> > The builds I am responsible for include it because someone reported an
issue
> > and was persistent and helpful enough that I fixed it for them.
> >
> > That said, until MinGW agrees on a stable branch/v
On 27 May 2015 18:18, "Antoine Pitrou" wrote:
>
> On Mon, 25 May 2015 17:30:02 -0700
> Larry Hastings wrote:
> >
> > So, in all three cases it's work that's been under development for a
> > while. These people did this work out of the kindness of their hearts,
> > to make Python better. As a co
CPython, but have them be truly independently versioned using the
standard Python package management tools (this might even be an
appropriate approach to consider for some existing standard library
modules, such as ssl, unittest, idlelib or distutils).
Regards,
Nick.
[1]
https://hel
On 28 May 2015 07:48, "Guido van Rossum" wrote:
>
> On Wed, May 27, 2015 at 2:34 PM, Barry Warsaw wrote:
>>
>> On May 27, 2015, at 05:15 PM, Terry Reedy wrote:
>>
>> >How about a feature release once a year, on a schedule we choose as
best for
>> >us.
>>
>> We discussed timed releases ages ago an
On 28 May 2015 08:31, "Nick Coghlan" wrote:
>
>
> On 28 May 2015 07:48, "Guido van Rossum" wrote:
> >
> > On Wed, May 27, 2015 at 2:34 PM, Barry Warsaw wrote:
> >>
> >> On May 27, 2015, at 05:15 PM, Terry Reedy wrote:
> >>
&g
at the bottom of this email).
>
+1 from me, for basically the same reasons Guido gives: Python 2.7 is going
to be with us for a long time, and this particular change shouldn't have
any externally visible impacts at either an ABI or API level.
Cheers,
Nick.
--
Nick Co
es, but
the bug is actually going to block a *lot* of potential testing of the
beta release - anything that requires a C extension module that isn't
a top level module isn't going to work with 3.5b1.
Cheers,
Nick.
--
Nick Coghlan | ncogh..
rtunately going to limit the amount of 3.5b1 testing
the community can do in those 6 weeks :(
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mai
e it helps
them influence the direction of upstream development in ways that help
them and their customers. (And sometimes it's a mix of all 3 of those
factors)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python
On 28 May 2015 at 19:47, Nick Coghlan wrote:
> That's going to be a negotiation process - companies don't typically
> contribute paid development time to open source projects out of the
> kindness of their hearts, they do it either because they're using the
> project t
On 28 May 2015 at 23:37, Nick Coghlan wrote:
> On 28 May 2015 at 22:00, Matthias Klose wrote:
>> On 05/28/2015 02:17 AM, Parasa, Srinivas Vamsi wrote:
>>> Hi All,
>>>
>>> This is Vamsi from Server Scripting Languages Optimization team at Intel
>>>
t;> Python 2.7.10 (original) vs Computed Goto performance
>> Benchmark
>
> -1
>
> As Gregory pointed out, there are other options to build the interpreter, and
> we
> are missing data how these compare with your patch.
That's shifting the goal posts: suggesting that
ernative to CPython->Go migrations than the more
modest performance improvements we can make to the CPython runtime
itself. (I still think the latter are a good idea, though - there's no
point leaving Python 2.7 slower than it needs to be given the offer of
assista
7;t* be exposed (the ones that rely on FILE pointers), but the
others should be OK.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listi
On 29 May 2015 05:25, "Chris Barker" wrote:
>
> OK, I'm really confused here:
>
> 1) what the heck is so special about go all of a sudden? People have been
writing and deploying single file executables built with C and ++, and
whatever else? forever. (and indeed, it was a big sticking point for me
On 29 May 2015 01:04, "Steve Dower" wrote:
>
> Paul Moore wrote:
> > On 28 May 2015 at 15:28, Steve Dower wrote:
> >> I don't have the issue number handy, but it should be near the top of
> >> the recently modified list.
> >
> > I recall seeing that issue. I'm fine with that - getting the two in
On 29 May 2015 00:52, "Paul Moore" wrote:
>
> +1. The new embeddable Python distribution for Windows is a great step
> forward for this. It's not single-file, but it's easy to produce a
> single-directory self-contained application with it. I don't know if
> there's anything equivalent for Linux/O
On 29 May 2015 2:16 am, "Barry Warsaw" wrote:
>
> Go seems to be popular where I work. It is replacing Python in a number
of
> places, although Python (and especially Python 3) is still a very
important
> part of our language toolbox.
>
> There are several reasons why Go is gaining popularity. S
On 29 May 2015 9:17 am, "Antoine Pitrou" wrote:
>
> On Thu, 28 May 2015 08:48:11 +1000
> Nick Coghlan wrote:
> > After all, the real difference between the alphas and the final releases
> > isn't about anything *we* do, it's about the testing *other peop
On 29 May 2015 9:48 am, "Donald Stufft" wrote:
>
>
>
> On May 28, 2015 at 7:40:26 PM, Nick Coghlan (ncogh...@gmail.com) wrote:
> > >
> > > One thing I've seen more than once is that new development happens
> > in Python
> > > un
On 29 May 2015 11:01 am, "Victor Stinner" wrote:
>
> Why not continue to enhance Python 3 instead of wasting our time with
> Python 2? We have limited resources in term of developers to maintain
> Python.
>
> (I'm not talking about fixing *bugs* in Python 2 which is fine with me.)
I'm actually OK
On 29 May 2015 20:24, "Stephen J. Turnbull" wrote:
>
> Nathaniel Smith writes:
>
> > DVCS back in the day :-). Unfortunately hg makes this a little
> > trickier than it could be, because in hg the same commit can't be in
> > two different branches; but this just means you have to insert some
>
On 30 May 2015 07:14, "Gregory P. Smith" wrote:
>
>
> On Fri, May 29, 2015 at 12:24 AM Nick Coghlan wrote:
>>
>>
>> On 29 May 2015 11:01 am, "Victor Stinner"
wrote:
>> >
>> > Why not continue to enhance Python 3 instead of wasti
On 29 May 2015 22:50, "Donald Stufft" wrote:
>
> This might be something that people could have done before with C/C++ but
with
> a nicer language behind it... but that's kind of the point? You don't
need to
> be stuck with a terrible language to get a nice single file executable
anymore,
> you ca
On 30 May 2015 09:21, "Barry Warsaw" wrote:
>
> On May 29, 2015, at 04:04 PM, Guido van Rossum wrote:
>
> >There are a fair number of people on this thread whose employer pays
them to
> >work on Python.
>
> My guess is that as Python 2.7 gets longer in the tooth, and it becomes
harder
> to motivat
On 30 May 2015 09:57, "Antoine Pitrou" wrote:
>
> On Sat, 30 May 2015 01:49:10 +0200
> Christian Heimes wrote:
> > For performance patches we have to consider our responsibility for the
> > environment. Every improvement means more speed and less power
> > consumption. Python runs of hundreds of
On 30 May 2015 10:46, "Alexander Walters" wrote:
>
> Python is a giant cache-miss generator. A little performance boost on the
> opt-code dispatch isn't going to change that much. If we really do care
> about improving python to do less environmental damage, then that is a
> discussion we sho
On 30 May 2015 at 20:35, Antoine Pitrou wrote:
> On Sat, 30 May 2015 10:34:15 +1000
> Nick Coghlan wrote:
>> On 30 May 2015 09:57, "Antoine Pitrou" wrote:
>> >
>> > On Sat, 30 May 2015 01:49:10 +0200
>> > Christian Heimes wrote:
>&
On 30 May 2015 at 20:58, Antoine Pitrou wrote:
> On Sat, 30 May 2015 18:55:20 +1000
> Nick Coghlan wrote:
>> On 30 May 2015 10:46, "Alexander Walters" wrote:
>> >
>> > Python is a giant cache-miss generator. A little performance boost on the
>>
On 30 May 2015 at 21:37, Antoine Pitrou wrote:
> On Sat, 30 May 2015 21:20:56 +1000
> Nick Coghlan wrote:
>> Given the extensive complaints about the lack of corporate
>> contribution to upstream CPython maintenance, the hostile reaction to
>> a concrete proposal for su
On 31 May 2015 04:20, "Ludovic Gasc" wrote:
>
> For now, I'm following the mailing-lists from a spy-glass: I don't read
most of the e-mails.
> However, this thread seems to be "infected": I can smell from here your
emotions behind your words.
>
> Why to push a lot of emotions inside a technical di
l see things change
for the better not just in terms of Python in particular, but in terms
of institutional infrastructure as a whole.
Cheers,
Nick.
[1] https://caremad.io/2015/04/a-year-of-pypi-downloads/
[2] http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html
[3] http://www.holi
On 31 May 2015 at 08:37, Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> We've long had a requirement that certain kinds of proposal come with
>> at least nominal support commitments from the folks proposing them
>> (e.g. adding modules to the standard library
ad some good opportunities to discuss that at PyCon),
although there are still some significant rough edges to figure out
(such as coming up with a coherent cross-platform story for what we're
going to do with the Python symlink), as well as a few more key
projects to either migrate e
dded complexity of needing to deal with the Windows registry).
Portable installations are often good for developers, but they come at
the cost of failing to integrate properly with the underlying
operating system.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Thanks Larry, and my apologies to the release team for the extra work!
Regards,
Nick.
___
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/a
need to be refactored/frozen/moved
to C to handle it after the simpler case is working.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
ot;yield from" expressions
* clearing it when resuming in "await" and "yield from" expressions
(This would be a read-only borrowed reference from a Python level
perspective, so it shouldn't be necessary to alter the reference count
- we'd just be aliasing the
From a learnability perspective, there's also nothing about an
"f_stack" attribute that says "you can use this to find out where a
generator or coroutine has delegated control", while attributes like
"gi_delegate" or "cr_del
On 14 Jun 2015 03:35, "Guido van Rossum" wrote:
>
> On Sat, Jun 13, 2015 at 9:21 AM, Nick Coghlan wrote:
>> From a learnability perspective, there's also nothing about an
>> "f_stack" attribute that says "you can use this to find out where a
On 14 Jun 2015 10:01, "Ben Leslie" wrote:
>
> If this seems like a good approach I'll try and work it in to a
> suitable patch for contribution.
I think it's a good approach, and worth opening an enhancement issue for.
I expect any patch would need some adjustments after Yury has finished
revisi
e of the system state when using coroutines in the
current beta.
Cheers,
Nick.
>
> On Sat, Jun 13, 2015 at 6:16 PM, Nick Coghlan wrote:
>>
>>
>> On 14 Jun 2015 10:01, "Ben Leslie" wrote:
>> >
>> > If this seems like a good approach I'll
king through some of those possible implications of
offering an asynchronous assignment syntax, the explicit method based
"await table.set(key, value)" construct may not look so bad after all
:)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
our exception
to disable the implicit exception chaining in 3.6+ in a way that
remains entirely compatible with older Python versions"
Given that significant difference in relative usability, +1 from me
for changing the default behaviour.
Cheers,
Nick.
--
Nick Coghla
do* write code like "name = name" at class
scope and expect it to "do the right thing", it seems reasonable to me
to just make this work properly, rather than having to explain why it
doesn't work as one might expected based on the behaviour of module
level class de
Updating the build system to better handle changes in underlying platforms
is one of the "standard exemptions" arising from Python 2.7's long term
support status, so if this change makes things easier for contributors on
Windows, +1 from me.
Cheers,
Nick.
__
On 23 Jun 2015 04:12, "Ethan Furman" wrote:
>
> -1 on auto-chaining.
>
> +1 on chaining helper functions so it's dirt-simple.
Chiming in again since I wasn't clear on this aspect last time: I'd also be
+1 on parallel APIs that handle the chaining.
Since the auto-chaining idea seems largely unpop
ms can consume as a trigger
for their own testing
It's not at the top of my todo list right now, but if nobody beats me
to it I'll try to see what I can set up in Kallithea some time in the
next few months :)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Austr
more
level playing field; and b) I asked if I could use Java instead, since
I already knew that at the time (he said no, and Python really *was*
very easy to pick up for the assignments we needed to do. It made it
up again an easy choice several years later)
--
Nick Coghlan | ncogh...@gmai
ld their own) should have no idea that anything
> has changed at all.
I'd suggest explicitly reaching out to the Stackless folks to get
their feedback. As I believe the switched to a newer compiler and VC
runtime for Windows a while back, I suspect it will make their lives
easier rather t
On 26 Jun 2015 05:15, "Andrew Svetlov" wrote:
>
> > Another issue that bothers me, is code reuse. Independent from whether
the
> > 'async def' makes sense or not, it would not allow us to reuse asyncio
> > functions as if they were normal functions and vice versa (if I
understood
> > that correctl
On 26 Jun 2015 10:46, "Greg Ewing" wrote:
>
> Sven R. Kunze wrote:
>> So, we would have to implement things twice for the asyncio world and
the classic world.
>
>
> Not exactly; it's possible to create a wrapper that takes an
> async function and runs it to completion, allowing it to be
> called f
ubroutines and coroutines are not the same thing:
https://en.wikipedia.org/wiki/Coroutine#Comparison_with_subroutines
They're *related*, but they're still not the same thing.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
have
been some good recent progress on Python 3 compatibility:
https://github.com/gevent/gevent/issues/38
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://
n change in
response to beta feedback: https://hg.python.org/peps/rev/0c963fa25db8
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/list
as utility functions, so we can
wait and see how strong the demand is for them as adapters. (They may
also be potentially useful to have as recipes in the documentation)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
P
ting changes in recommended development practices to Python
educators, so ensuring we do a good job with that can have a big
multiplier effect on all the other work that goes into creating each
new release.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
ension may occur as
part of any function call (whether an explicit call or as part of a
syntactic protocol). These approaches provide parallel execution at
the expense of the ability to reason locally about code correctness,
which then causes all sorts of *other* problems.
That said, I think the
question - some things are better modelled
as complex numbers, others as real numbers, so the only reasonable
answer is to ask "What are you trying to model?". "Are coroutines
better than subroutines?" is the same kind of question, just applied
to algorithm design rather than numeric
ideline for what's likely to be
> needed).
That would be very helpful! I'd definitely be able to find the time to
review and merge updates, it's the research-and-writing side that
poses a problem for me (appreciating a task is worth doing isn't the
same thing as wantin
ision$
Last-Modified: $Date$
Author: Nick Coghlan ,
Robert Kuska ,
Marc-André Lemburg
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 10-May-2015
Post-History: 06-Jul-2015
Abstract
PEP 476 updated Python's default handling of HTTPS certifica
On 6 Jul 2015 20:23, "Antoine Pitrou" wrote:
>
> On Mon, 6 Jul 2015 14:22:46 +1000
> Nick Coghlan wrote:
> >
> > The main change from the last version discussed on python-ideas
>
> Was it discussed there? That list has become totally useless, I've
> s
all_async(open('big.file').read)
future2 = asyncio.call_async(open('huge.file').read)
content1 = asyncio.wait_for_result(future1)
content2 = asyncio.wait_for_result(future2)
return content1 + content2
Cheers,
Nick.
--
Nick Coghlan | ncogh...@g
hat work within my salaried
> hours... so having time isn't a problem).
Huzzah - thanks for offering, and thanks Travis/Continuum for granting
you the paid time :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
they
tried it.
It would mean yet another piece of workflow infrastructure to set up
and maintain, though :(
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.
On 7 July 2015 at 21:49, s.krah wrote:
>
>
> Erik Bray wrote:
>
>> On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou
>> wrote:
>>> On Mon, 6 Jul 2015 14:22:46 +1000
>>> Nick Coghlan wrote:
>>>>
>>>> The main change from the las
his is
> a subtle corner of the RFC and an unexpected regression from Python 3.4.
That strikes me as just the kind of
not-quite-as-finished-as-we-thought case that the beta cycle is
designed to flush out, so the minor further enhancement sounds like a
good idea to me.
Cheers,
Nick.
--
Nick Co
ors and
omissions you've already found :)
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
tails for
the different phases in the release PEPs themselves? Larry sent a good
summary to python-committers for 3.5 a while back, but they'd be
easier to find in the PEPs, and it would also make it clear which
aspects a new RM was keeping, and which they wanted to try doing
differently.
Chee
On 14 July 2015 at 17:19, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > I wonder: should we start putting some of these process details for
> > the different phases in the release PEPs themselves? Larry sent a good
> > summary to python-committers for 3.5 a w
n't the one Kushal and
Michael made, and there isn't a compelling argument in favour of
changing the implementation of the new guard to allow the typo'ed
prefix.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 14 July 2015 at 22:53, Xavier Morel wrote:
>
> On 2015-07-14, at 14:39 , Nick Coghlan wrote:
>
>> On 14 July 2015 at 22:06, Dima Tisnek wrote:
>>> Thus the question, how far should Python go to detect possible
>>> erroneous user behaviour?
>>>
&g
e
> any mapping object).
I was about to post about that. exec used to also require that locals
be exactly a dictionary, so my suspicion is that we simply missed
updating the PyRun_SimpleString docs when the constraint was removed
from the underlying frame execution code.
Cheers,
Nick.
--
Nick C
member:
* it's almost certainly not urgent
* tolerating the occasional design decision we dislike won't ruin our lives
* a red bikeshed will still shelter our bikes, even if we'd have preferred blue
* it's just software, so we can put a blue wrapper around the re
On 15 July 2015 at 12:07, Steven D'Aprano wrote:
> On Wed, Jul 15, 2015 at 10:59:50AM +1000, Nick Coghlan wrote:
>
>> Remember folks, "Why wasn't I consulted?!?!?!?" is one of the more
>> obnoxious behavours we can inflict on fellow open source maintainers
&
p the OS pipe buffer as the pipes are
not being read from."
I think Chris is right that it's a docs bug - the warning is
applicable to subprocess.call and subprocess.check_call (which use
Popen.wait), but not to subprocess.check_output (which uses
Popen.communicate).
Cheers,
Nick.
--
N
ugh
the apparent obsession over such a minor detail has made it abundantly
clear that this kind of helper simply isn't worth the distraction it
creates for maintainers, *regardless* of whether or not it helps end
users.
Regards,
Nick.
--
Nick Coghlan | ncogh...
ect will throw
AttributeError in 3.5+. The only way to get it to *work* is to spell
it properly.
The specific typo that is checked is the only one that changes the
spelling without also changing the overall length and shape of the
word.
Regards,
Nick.
--
Nick Cogh
On 18 Jul 2015 8:13 am, "Ethan Furman" wrote:
>
> On 07/16/2015 11:30 PM, Nick Coghlan wrote:
>
>> On 17 July 2015 at 08:30, Ben Finney wrote:
>
>
>>> By definition, advocating to not add cruft to an API is going to be in
>>> advance of being bi
On 18 Jul 2015 10:40 am, "Ben Finney" wrote:
>
> Nick Coghlan writes:
>
> > On 17 July 2015 at 08:30, Ben Finney wrote:
> > > By definition, advocating to not add cruft to an API is going to be in
> > > advance of being bitten by those additions.
>
On 18 Jul 2015 1:19 pm, "Nick Coghlan" wrote:
> I'm with Antoine in wondering why we even bother with contributing when
the thanks we can expect is for people to feel entitled to demand we spend
hours of our time debating trivial details
Sorry, I crossed a line there - I know e
ructural separation of
the two kinds of Mock method, but the existing merged API is one a lot
of folks actually like.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
ht
mples we can (and are)
learning from, improving the support structures for an already wildly
successful open source project without alienating existing
contributors isn't a task that comes with an instruction manual :)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisban
ore developers, it's a "Right, so you trust me to
build the nuclear power plant, but not to choose the colour of the
bike shed behind it" situation. Knowing we're trusted to build power
plants, but will get grief for working on smaller things creates an
even greater incentive to
, but
rather with well-intentioned messages that nevertheless have the
effect of causing folks to feel unappreciated and resentful. A
practical quick start guide is likely to be more effective in
addressing that aspect than a more explicit CoC (although I still
think the latter would be a
e near term, of course, but it does
mean we know there's a relatively large pool of paid development time
currently being directed elsewhere that may be brought more directly
to bear upstream in the future.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
701 - 800 of 6587 matches
Mail list logo
