On Tue, 12 May 2020 at 07:53, Brandt Bucher wrote:
> > > However, zip_longest is really another beast entirely
> > No, it isn't.
>
> It has a completely independent implementation, a different interface, lives
> in a separate namespace, and doesn't even reference zip in its documentation.
> So
On Tue, May 12, 2020 at 5:20 PM Paul Moore wrote:
>
> On Tue, 12 May 2020 at 07:53, Brandt Bucher wrote:
> > > > Another proposed idiom, per-module shadowing of the built-in zip with
> > > > some subtly different variant from itertools, is an anti-pattern that
> > > > shouldn't be encouraged.
>
On Tue, 12 May 2020 06:48:32 -
"Brandt Bucher" wrote:
>
> > > A good rule of thumb is that "mode-switches" which change return types or
> > > significantly alter functionality are indeed an anti-pattern,
> > Source?
>
> This was based on a chat with someone who has chosen not to become
Hi All,
# Too long didn't read:
In 3.9 inspect.getdoc(instance) behavior was changed and does not return the
documentation of type(instance) or it's superclass(es) – I think this is a
problematic change of for some project and interactive use to get info on
objects that get rarely directly co
On 05/11/2020 11:48 PM, Brandt Bucher wrote:
On 05/10/2020 14:39 PM, Ethan Furman wrote:
On 05/10/2020 09:04 AM, Brandt Bucher wrote:
However, zip_longest is really another beast entirely
No, it isn't.
It has a completely independent implementation, a different interface, lives in
a sep
On 05/11/2020 11:48 PM, Brandt Bucher wrote:
On 05/10/2020 14:39, Ethan Furman wrote:
On 05/10/2020 09:04 PM, Brandt Bucher wrote:
the author has counted dozens of other call sites in Python's standard library
and
tooling where it would be appropriate to enable this new feature immediately.
On Wed, May 13, 2020 at 4:38 AM Ethan Furman wrote:
>
> > -
> > https://github.com/python/cpython/blob/27c0d9b54abaa4112d5a317b8aa78b39ad60a808/Lib/os.py#L510
>
> Wow -- I don't even know how to parse that!
>
Wow, that's quite an example. Of something, I'm not sure what, but
definitely an exampl
Hello there,
I would like to discuss a proposal regarding one aspect which AFAIK is
currently missing from cPython's test suite: the ability to detect memory
leaks of functions implemented in the C extension modules.
In psutil I use a test class/framework which calls a function many times,
and fail
