Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #15580

Re: all() is slow?

References (6 earlier) <4ebb08b6$0$29970$c3e8da3$5496439d@news.astraweb.com> <CABicbJ+KkQ8Of4a84TM5nN+ZSh-TBioboLZ9VX1JNzw8G2bToQ@mail.gmail.com> <4EBC1B54.6000308@stoneleaf.us> <mailman.2621.1320957468.27778.python-list@python.org> <4ebc592b$0$29970$c3e8da3$5496439d@news.astraweb.com>
From Devin Jeanpierre <jeanpierreda@gmail.com>
Date 2011-11-10 23:35 -0500
Subject Re: all() is slow?
Newsgroups comp.lang.python
Message-ID <mailman.2638.1320986176.27778.python-list@python.org> (permalink)

Show all headers | View raw


> You will notice both of them keep the field name validation.

There are lots of reasons for that to be the case. To me, the most
likely one just seems to be that you don't want to remove more than
necessary when changing the way something works under the hood -- both
for compatibility reasons, and because you want the patch to get
accepted and want the least number of objectionable changes. I guess
you disagree.

> That is patently untrue. If you were implementing namedtuple without
> exec, you would still (or at least you *should*) prevent the user from
> passing invalid identifiers as attribute names. What's the point of
> allowing attribute names you can't actually *use* as attribute names?

Then why doesn't Python do this anywhere else? e.g. why can I
setattr(obj, 'a#b') when obj is any other mutable type?

I just don't believe this reasoning is what happened, I suppose. And
there's no way for you to convince me, or me to convince you, without
R. Hettinger stepping in here and verifying one side of the story.
This is subjective supposition, and that was supposed to be my most
objective opposition.

To go off on another tangent, though, I don't really understand how
you guys can think this is reasonable, though. I don't get this
philosophy of restricting inputs that would otherwise be perfectly
valid, just for concerns that you have that users might not share --
especially when it's valid everywhere else that the concept shows up.
It seems totally inconsistent with the attitude expressed above (by
you!) towards exec, which is that it's ok to be cautious of something,
but something else to forbid it outright.

Of course, as I said before, I don't agree with core python developers
on lots of things. I guess this is just another thing I just don't
understand.

Devin

On Thu, Nov 10, 2011 at 6:07 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Thu, 10 Nov 2011 15:37:05 -0500, Devin Jeanpierre wrote:
>
>>> '--' not being allowed for a name has *nothing* to do with exec, and
>>> everything to do with `--` not being a valid Python identifier.
>>
>> The only reason valid python identifiers come into it at all is because
>> they get pasted into a string where identifiers would go, and that
>> string is passed to exec().
>
> That is patently untrue. If you were implementing namedtuple without
> exec, you would still (or at least you *should*) prevent the user from
> passing invalid identifiers as attribute names. What's the point of
> allowing attribute names you can't actually *use* as attribute names?
>
> You could remove the validation, allowing users to pass invalid field
> names, but that would be a lousy API. If you want field names that aren't
> valid identifiers, the right solution is a dict, not attributes.
>
> Here's a re-implementation using a metaclass:
>
> http://pastebin.com/AkG1gbGC
>
> and a diff from the Python bug tracker removing exec from namedtuple:
>
> http://bugs.python.org/file11608/new_namedtuples.diff
>
>
> You will notice both of them keep the field name validation.
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list
>

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

all() is slow? "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-11-07 21:00 +0000
  Re: all() is slow? Chris Rebert <clp2@rebertia.com> - 2011-11-07 13:39 -0800
  Re: all() is slow? david vierra <codewarrior0@gmail.com> - 2011-11-07 13:46 -0800
    Re: all() is slow? Chris Angelico <rosuav@gmail.com> - 2011-11-08 09:06 +1100
      Re: all() is slow? Henrik Faber <hfaber@invalid.net> - 2011-11-08 13:09 +0100
        Re: all() is slow? Chris Angelico <rosuav@gmail.com> - 2011-11-08 23:14 +1100
        Re: all() is slow? John Posner <jjposner@optimum.net> - 2011-11-08 17:51 -0500
        Re: all() is slow? Tim Chase <python.list@tim.thechases.com> - 2011-11-08 17:56 -0600
    Re: all() is slow? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-11-08 19:44 -0500
      Re: all() is slow? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-09 02:47 +0000
        Re: all() is slow? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-11-09 18:01 -0500
          Re: all() is slow? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-09 23:11 +0000
            Re: all() is slow? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-11-09 20:26 -0500
              Re: all() is slow? alex23 <wuwei23@gmail.com> - 2011-11-09 19:50 -0800
                Re: all() is slow? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-11-09 23:40 -0500
                Re: all() is slow? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-10 07:35 +0000
              Re: all() is slow? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-10 07:48 +0000
                Re: all() is slow? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-11-10 03:51 -0500
                Re: all() is slow? gene heskett <gheskett@wdtv.com> - 2011-11-10 08:20 -0500
                Re: all() is slow? Terry Reedy <tjreedy@udel.edu> - 2011-11-10 14:25 -0500
            Re: all() is slow? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-11-09 20:35 -0500
            Re: all() is slow? Ian Kelly <ian.g.kelly@gmail.com> - 2011-11-09 19:10 -0700
            Re: all() is slow? Ethan Furman <ethan@stoneleaf.us> - 2011-11-10 10:43 -0800
            Re: all() is slow? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-11-10 15:37 -0500
              Re: all() is slow? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-10 23:07 +0000
                Re: all() is slow? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-11-10 23:35 -0500
                Re: all() is slow? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-12 01:18 +0000
                Re: all() is slow? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-11-13 01:28 -0500
                Re: all() is slow? alex23 <wuwei23@gmail.com> - 2011-11-13 18:50 -0800
                Re: all() is slow? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-11-13 23:48 -0500
              Re: all() is slow? "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-11-11 05:40 +0000
            Re: all() is slow? Ian Kelly <ian.g.kelly@gmail.com> - 2011-11-10 14:19 -0700
              Re: all() is slow? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-10 22:56 +0000
            Re: all() is slow? Ethan Furman <ethan@stoneleaf.us> - 2011-11-10 13:47 -0800
        Re: all() is slow? Chris Angelico <rosuav@gmail.com> - 2011-11-10 10:15 +1100
    Re: all() is slow? Chris Angelico <rosuav@gmail.com> - 2011-11-09 12:19 +1100
    Re: all() is slow? Chris Rebert <clp2@rebertia.com> - 2011-11-08 17:30 -0800
      Re: all() is slow? Hans Mulder <hansmu@xs4all.nl> - 2011-11-09 16:41 +0100
        Re: all() is slow? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-11-09 09:07 -0800
  Re: all() is slow? John Nagle <nagle@animats.com> - 2011-11-09 14:16 -0800
    Re: all() is slow? alex23 <wuwei23@gmail.com> - 2011-11-09 19:52 -0800
    Re: all() is slow? "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-11-10 19:35 +0000
  Re: all() is slow? BOOK-AZ <amalguseynov@gmail.com> - 2011-11-15 08:02 -0800

csiph-web