On Tue, Jun 23, 2020 at 9:45 PM Neil Girdhar wrote:
> This is awesome!
>
> What I love about this is that it strongly encourages people not to do
> EAFP with types (which I've seen many times), which causes problems when
> doing type annotations. Instead, if they use patte
This is awesome!
What I love about this is that it strongly encourages people not to do EAFP
with types (which I've seen many times), which causes problems when doing
type annotations. Instead, if they use pattern matching, they're
essentially forced to do isinstance without even realizing it. I
Thanks for clarifying.
On Tue, Jul 19, 2016 at 10:34 AM Nick Coghlan wrote:
> On 19 July 2016 at 16:41, Neil Girdhar wrote:
> > Yes, I see what you're saying. However, I don't understand why
> > __init_subclass__ (defined on some class C) cannot be used to implement
d with
any metaclass or no metaclass at all provided you inherit from C.
On Tue, Jul 19, 2016 at 12:21 AM Nick Coghlan wrote:
> On 19 July 2016 at 09:26, Neil Girdhar wrote:
> > Yes, I'm very excited about this!
> >
> > Will this mean no more metaclass conflicts if us
Yes, I'm very excited about this!
Will this mean no more metaclass conflicts if using @abstractmethod?
On Sun, Jul 17, 2016 at 12:59 PM Guido van Rossum wrote:
> This PEP is now accepted for inclusion in Python 3.6. Martin,
> congratulations! Someone (not me) needs to review and commit your
> c
definitely interested in meeting any Python developers for coffee
or drinks. I know the city pretty well. :)
Best,
Neil
On Tue, Mar 17, 2015 at 9:49 AM, Brett Cannon wrote:
>
>
> On Mon, Mar 16, 2015 at 7:11 PM Neil Girdhar
> wrote:
>
>> Hi everyone,
>>
>&g
Ever since I updated, I am getting:
In file included from Objects/dictobject.c:236:0:
Objects/clinic/dictobject.c.h:70:26: fatal error: stringlib/eq.h: No such
file or directory
#include "stringlib/eq.h"
But, Objects/stringlib/eq.h exists. Replacing the include with
"Objects/stringlib/eq.h" see
he value is for
people who are new to the codebase.
Best,
Neil
On Fri, Mar 20, 2015 at 10:35 PM, Brian Curtin wrote:
> On Fri, Mar 20, 2015 at 7:54 PM, Neil Girdhar
> wrote:
> > If ever someone wants to clean up the repository to conform to PEP 7, I
> > wrote a program th
If ever someone wants to clean up the repository to conform to PEP 7, I
wrote a program that catches a couple hundred PEP 7 violations in ./Python
alone (1400 in the whole codebase):
import os
import re
def grep(path, regex):
reg_obj = re.compile(regex, re.M)
res = []
for root, dirs,
Wow, this is an excellent review. Thank you.
My only question is with respect to this:
I think there ought to be two opcodes; one for unpacking maps in
function calls and another for literals. The whole function location
thing is rather hideous.
What are the two opcodes? BUILD_MAP_UNPACK and B
Hi everyone,
I was wondering what is left with the PEP 448 (
http://bugs.python.org/issue2292) code review? Big thanks to Benjamin,
Ethan, and Serhiy for reviewing some (all?) of the code. What is the next
step of this process?
Thanks,
Neil
On Sun, Mar 8, 2015 at 4:38 PM, Neil Girdhar
Totally agree
On 9 Mar 2015 19:22, "Nick Coghlan" wrote:
>
> On 10 Mar 2015 06:51, "Neil Girdhar" wrote:
> >
> >
> >
> > On Mon, Mar 9, 2015 at 12:54 PM, Serhiy Storchaka
> wrote:
> >>
> >> On 09.03.15 17:48, Neil Girdhar
On Mon, Mar 9, 2015 at 12:54 PM, Serhiy Storchaka
wrote:
> On 09.03.15 17:48, Neil Girdhar wrote:
>
>> So you agree that the ideal solution is composition, but you prefer
>> inheritance in order to not break code?
>>
>
> Yes, I agree. There is two advantages in th
It may be that the comparison that you do is between two elements that are
almost always in the same cache line whereas the binary search might often
incur a cache miss.
On Mon, Mar 9, 2015 at 2:49 PM, nha pham wrote:
> I do not know exactly, one thing I can imagine is: it turns the worst case
>
On Mon, Mar 9, 2015 at 11:11 AM, Serhiy Storchaka
wrote:
> понеділок, 09-бер-2015 10:18:50 ви написали:
> > On Mon, Mar 9, 2015 at 10:10 AM, Serhiy Storchaka
> wrote:
> > > понеділок, 09-бер-2015 09:52:01 ви написали:
> > > > On Mon, Mar 9, 2015 at 2:07 AM, Serhiy Storchaka <
> storch...@gmail.c
On Mon, Mar 9, 2015 at 11:46 AM, Steven D'Aprano
wrote:
> On Mon, Mar 09, 2015 at 09:52:01AM -0400, Neil Girdhar wrote:
>
> > Here is a list of methods on
> > int that should not be on IntFlags in my opinion (give or take a couple):
> >
> > __abs__, __add__,
On Mon, Mar 9, 2015 at 2:07 AM, Serhiy Storchaka
wrote:
> On 09.03.15 06:33, Ethan Furman wrote:
>
>> I guess it could boil down to: if IntEnum was not based on 'int', but
>> instead had the __int__ and __index__ methods
>> (plus all the other __xxx__ methods that int has), would it still be a
>
Anyone have time to do a code review?
http://bugs.python.org/issue2292
On Mon, Mar 2, 2015 at 4:54 PM, Neil Girdhar wrote:
> It's from five days ago. I asked Joshua to take a look at something, but
> I guess he is busy.
>
> Best,
>
> Neil
>
> —
>
> The late
On Fri, Mar 6, 2015 at 1:11 PM, Brett Cannon wrote:
>
>
> On Fri, Mar 6, 2015 at 1:03 PM Mark Shannon wrote:
>
>>
>> On 06/03/15 16:34, Brett Cannon wrote:
>> > Over on the import-sig I proposed eliminating the concept of .pyo files
>> > since they only signify that /some/ optimization took plac
, Mar 2, 2015 at 3:18 PM, Neil Girdhar wrote:
> http://bugs.python.org/issue2292
>
> On Mon, Mar 2, 2015 at 3:17 PM, Victor Stinner
> wrote:
>
>> Where is the patch?
>>
>> Victor
>>
>> Le lundi 2 mars 2015, Neil Girdhar a écrit :
>>
>>
http://bugs.python.org/issue2292
On Mon, Mar 2, 2015 at 3:17 PM, Victor Stinner
wrote:
> Where is the patch?
>
> Victor
>
> Le lundi 2 mars 2015, Neil Girdhar a écrit :
>
> Hi everyone,
>>
>> The patch is ready for review now, and I should have time this week
Hi everyone,
The patch is ready for review now, and I should have time this week to make
changes and respond to comments.
Best,
Neil
On Wed, Feb 25, 2015 at 2:42 PM, Guido van Rossum wrote:
> I'm back, I've re-read the PEP, and I've re-read the long thread with "(no
> subject)".
>
> I think G
= modified_args_for_D(args, kwargs)
else:
return super().__make_me_cls__(arg_cls, args, kwargs)
if cls is C:
return C(*args, **kwargs)
return cls.__make_me_cls__(C, *args, **kwargs)
On Sat, Feb 14, 2015 at 3:15 PM, Neil Girdhar wrote:
> I th
D'Aprano
wrote:
> On Fri, Feb 13, 2015 at 06:03:35PM -0500, Neil Girdhar wrote:
> > I personally don't think this is a big enough issue to warrant any
> changes,
> > but I think Serhiy's solution would be the ideal best with one additional
> > parameter: the cal
I think it works as Isaac explained if __make_me__ is an instance method
that also accepts the calling class type.
On Fri, Feb 13, 2015 at 8:12 PM, Ethan Furman wrote:
> On 02/13/2015 02:31 PM, Serhiy Storchaka wrote:
> > On 13.02.15 05:41, Ethan Furman wrote:
> >> So there are basically two cho
You're right.
On Fri, Feb 13, 2015 at 7:55 PM, Isaac Schwabacher
wrote:
> On 15-02-13, Neil Girdhar wrote:
> > Unlike a regular method, you would never need to call super since you
> should know everyone that could be calling you. Typically, when you call
> super, you have
might not know about C.
Best,
Neil
On Fri, Feb 13, 2015 at 7:00 PM, Isaac Schwabacher
wrote:
> On 15-02-13, Neil Girdhar wrote:
> > I personally don't think this is a big enough issue to warrant any
> changes, but I think Serhiy's solution would be the ideal best with on
tially the caller is identifying himself so that the receiver knows
how to interpret the arguments.
Best,
Neil
On Fri, Feb 13, 2015 at 5:55 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> On Fri, Feb 13, 2015 at 4:44 PM, Neil Girdhar
> wrote:
>
>> Intere
Interesting:
http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle
On Fri, Feb 13, 2015 at 3:37 PM, Isaac Schwabacher
wrote:
> On 15-02-13, Guido van Rossum wrote:
> > Are you willing to wait 10 days for an answer? I'm out of round
> tuits
With Python's cooperative inheritance, I think you want to do everything
through one constructor sending keyword arguments up the chain. The
keyword arguments are popped off as needed. With this setup I don't think
you need "overloaded constructors".
Best,
Neil
On Fri, Feb 13, 2015 at 4:44 AM,
ah, sorry… forget that I said "just as it is now" — I am losing track of
what's allowed in Python now!
On Tue, Feb 10, 2015 at 2:29 AM, Neil Girdhar wrote:
>
>
> On Tue, Feb 10, 2015 at 2:20 AM, Victor Stinner
> wrote:
>
>> To be logic, I expect [(*item)
On Tue, Feb 10, 2015 at 2:20 AM, Victor Stinner
wrote:
> To be logic, I expect [(*item) for item in mylist] to simply return mylist.
>
If you want simply mylist as a list, that is [*mylist]
> [*(item) for item in mylist] with mylist=[(1, 2), (3,)] could return [1,
> 2, 3],
>
right
> as just [*
On Tue, Feb 10, 2015 at 2:08 AM, Victor Stinner
wrote:
>
> Le 10 févr. 2015 03:07, "Ethan Furman" a écrit :
> > That line should read
> >
> > return func(*(args + fargs), **{**keywords, **fkeywords})
> >
> > to avoid the duplicate key error and keep the original functionality.
>
> To me, thi
On Tue, Feb 10, 2015 at 1:31 AM, Donald Stufft wrote:
>
> > On Feb 10, 2015, at 12:55 AM, Greg Ewing
> wrote:
> >
> > Donald Stufft wrote:
> >> However [*item for item in ranges] is mapped more to something like
> this:
> >> result = []
> >> for item in iterable:
> >>result.extend(*item)
> >
On Mon, Feb 9, 2015 at 7:53 PM, Donald Stufft wrote:
>
> On Feb 9, 2015, at 7:29 PM, Neil Girdhar wrote:
>
> For some reason I can't seem to reply using Google groups, which is is
> telling "this is a read-only mirror" (anyone know why?) Anyway, I'm going
>
Just an FYI:
http://www.reddit.com/r/Python/comments/2v8g26/python_350_alpha_1_has_been_released/
448 was mentioned here (by Python lay people — not developers).
On Mon, Feb 9, 2015 at 7:56 PM, Neil Girdhar wrote:
> The admonition is against syntax that currently exists.
>
> On M
The admonition is against syntax that currently exists.
On Mon, Feb 9, 2015 at 7:53 PM, Barry Warsaw wrote:
> On Feb 09, 2015, at 07:46 PM, Neil Girdhar wrote:
>
> >Also, regarding calling argument order, not any order is allowed. Regular
> >arguments must precede other
Yes, that's exactly right. It does not affect the callee.
Regarding function call performance, nothing has changed for the originally
accepted argument lists: the opcodes generated are the same and they are
processed in the same way.
Also, regarding calling argument order, not any order is allow
licate keyword arguments
would remain an error (for now at least). If you want to merge the
dictionaries with overriding, then you can still do:
function(**{**kw_arguments, **more_arguments})
because **-unpacking in dicts overrides as you guessed.
—
On Mon, Feb 9, 2015 at 7:12 PM, Donald Stufft wrote:
That wording is my fault. I'll update the PEP to remove the word
"currently" after waiting a bit to see if there are any other problems.
Best,
Neil
On Mon, Feb 9, 2015 at 6:16 PM, Benjamin Peterson
wrote:
>
>
> On Mon, Feb 9, 2015, at 17:12, Neil Girdhar wrote:
>
Right,
Just to be clear though: **-args must follow any *-args and position
arguments. So at worst, your example is:
f(x, y, *k, *b, c, **w, **d)
Best,
Neil
On Mon, Feb 9, 2015 at 5:10 PM, Benjamin Peterson
wrote:
>
>
> On Mon, Feb 9, 2015, at 16:32, Guido van Rossum wrote:
> > FWIW, I've
Hello all,
The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
implemented now based on some early work by Thomas Wouters (in 2008) and
Florian Hahn (2013) and recently completed by Joshua Landau and me.
The issue tracker http://bugs.python.org/issue2292 has a working patch.
Woul
Hello all,
PEP 448 (https://www.python.org/dev/peps/pep-0448/) is mostly implemented
now based on some early implementations by twouters (in 2008) and fhahn
(2013) and recently by Joshua and I.
The issue tracker http://bugs.python.org/issue2292 has:
* a working patch, and
* discussion and update
Perfect, thanks!
On Sun, Jan 25, 2015 at 7:08 AM, Petr Viktorin wrote:
> On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar
> wrote:
> > How do I disassemble a generated comprehension?
> >
> > For example, I am trying to debug the following:
> >
> >>>&g
How do I disassemble a generated comprehension?
For example, I am trying to debug the following:
>>> dis.dis('{**{} for x in [{1:2}]}')
1 0 LOAD_CONST 0 ( at
0x10160b7c0, file "", line 1>)
3 LOAD_CONST 1 ('')
6 MAKE_FUNCTION
That makes sense. Thanks for explaining.
On Sun, Jan 25, 2015 at 4:55 AM, Thomas Wouters wrote:
>
>
> On Sun, Jan 25, 2015 at 5:05 AM, Neil Girdhar
> wrote:
>
>> But you can remove Python/graminit.c and "make clean && make" works,
>> right?
Coghlan wrote:
> > > On 20 January 2015 at 10:53, Benjamin Peterson
> > > wrote:
> > > >
> > > >
> > > > On Mon, Jan 19, 2015, at 19:40, Neil Girdhar wrote:
> > > >> I was also wondering why files like Python/graminit.c are in the
,' (test ':'
> test | '**' test))* [','])) |
>(test (comp_for | (',' test)* [','])) )
>
> Also I presume you want a similar treatment for the set branch (replace
> both tests with (test | '*' test).
&
To finish PEP 448, I need to update the grammar for syntax such as
{**x for x in it}
and
{1:2, 3:4, **a}
It's been a long time since I've looked at grammars and I could really use
the advice of an expert. I'm considering replacing:
dictorsetmaker: ( (test ':' test (comp_for | (',' test ':' te
gt; On 20 Jan 2015, at 17:34, Neil Girdhar wrote:
>
> > My question first:
> > test_ast is mostly generated code, but I can't find where it is being
> > generated. I am pretty sure I know how to fix most of the introduced
> > problems. Who is generating test_ast??
Building argument lists and dicts in python entails the following opcode
pattern:
1 0 BUILD_MAP3
3 LOAD_CONST 0 (2)
6 LOAD_CONST 1 (1)
9 STORE_MAP
10 LOAD_CONST 2 (4)
Okay, I think it's ready for a code review. Would anyone be kind enough to
offer comments?
On Tue, Jan 20, 2015 at 12:10 PM, Neil Girdhar
wrote:
> Thanks!
>
> On Tue, Jan 20, 2015 at 12:09 PM, Benjamin Peterson
> wrote:
>
>> $ ./python Lib/test/test_ast.py -g
>&
27;Module', [('FunctionDef', (1, 0), 'f', ('arguments', [], ('arg', (1,
> 7), 'args', None), [], [], None, []), [('Pass', (1, 14))], [], None)]),
> ('Module', [('FunctionDef', (1, 0), 'f', ('ar
Best,
Neil
On Tue, Jan 20, 2015 at 11:36 AM, Benjamin Peterson
wrote:
>
>
> On Tue, Jan 20, 2015, at 11:34, Neil Girdhar wrote:
> > My question first:
> > test_ast is mostly generated code, but I can't find where it is being
> > generated. I am pretty sur
My question first:
test_ast is mostly generated code, but I can't find where it is being
generated. I am pretty sure I know how to fix most of the introduced
problems. Who is generating test_ast??
Update:
So far, I've done the following:
Updated the patch to 3.5
Fixed the grammar to accept fin
(in fact, it was Python/getargs.c)
On Tue, Jan 20, 2015 at 10:01 AM, Neil Girdhar
wrote:
> Okay, found it thanks.
>
> On Tue, Jan 20, 2015 at 9:59 AM, Neil Girdhar
> wrote:
>
>> Good eye! I did the following grep:
>>
>> ~/cpython: grep -R takes.exac *
>&
Okay, found it thanks.
On Tue, Jan 20, 2015 at 9:59 AM, Neil Girdhar wrote:
> Good eye! I did the following grep:
>
> ~/cpython: grep -R takes.exac *
> Doc/c-api/bytes.rst: Identical to :c:func:`PyBytes_FromFormat` except
> that it takes exactly two
> Doc/c-api/unicode.r
en)",
Python/ceval.c.orig: "%.200s() takes exactly one
argument (%d given)",
Binary file Python/ceval.o matches
Binary file libpython3.5dm.a matches
Binary file python.exe matches
I'll keep searching…
On Tue, Jan 20, 2015 at 9:52 AM, Stefan Ring wrote:
> On Tue, Jan 2
Sorry, I should have provided more context.
Best,
Neil
On Tue, Jan 20, 2015 at 9:55 AM, Brett Cannon wrote:
>
>
> On Tue Jan 20 2015 at 9:53:52 AM Benjamin Peterson
> wrote:
>
>>
>>
>> On Tue, Jan 20, 2015, at 09:51, Brett Cannon wrote:
>> > This is a mailing to discuss the development *of* P
> On Tue, Jan 20, 2015 at 8:35 AM, Neil Girdhar
> wrote:
> >
> > I get error:
> >
> > TypeError: init_builtin() takes exactly 1 argument (0 given)
> >
> > The only source file that can generate that error is
> Modules/_ctypes/_ctypes.c, but when I make cha
I get error:
TypeError: init_builtin() takes exactly 1 argument (0 given)
The only source file that can generate that error
is Modules/_ctypes/_ctypes.c, but when I make changes to that file such as:
PyErr_Format(PyExc_TypeError,
"call takes exactly %d arguments XYZA
Hi everyone,
I tried to work on PEP 448 and updated the latest patch to Python 3.5. I
uploaded the new diff here: http://bugs.python.org/issue2292. I don't know
how to debug further. Is there a way to view the compiled output despite
Python not starting up?
I was also wondering why files like
On Sat, Jun 7, 2014 at 5:50 AM, Nick Coghlan wrote:
> On 7 June 2014 19:36, Ram Rachum wrote:
> > My need is to have an infinite immutable sequence. I did this for myself
> by
> > creating a simple `count`-like stateless class, but it would be nice if
> that
> > behavior was part of `range`.
>
>
63 matches
Mail list logo
