On Fri, Dec 6, 2019 at 12:14 PM Paul Moore <p.f.mo...@gmail.com> wrote:
> On Fri, 6 Dec 2019 at 09:33, Steven D'Aprano <st...@pearwood.info> wrote:
> >
> > Although I am cautiously and tentatively in favour of setting limits
> > if the benefits Mark suggests are correct, I have thought of at least
> > one case where a million classes may not be enough.
> >
> > I've seen people write code like this:
> >
> > for attributes in list_of_attributes:
> > obj = namedtuple("Spam", "fe fi fo fum")(*attributes)
> > values.append(obj)
> >
> >
> > not realising that every obj is a singleton instance of a unique class.
> > They might end up with a million dynamically created classes, each with
> > a single instance, when what they wanted was a single class with a
> > million instances.
>
> But isn't that the point here? A limit would catch this and prompt
> them to rewrite the code as
>
> cls = namedtuple("Spam", "fe fi fo fum")
> for attributes in list_of_attributes:
> obj = cls(*attributes)
> values.append(obj)
>
This assumes two things: you actually hit the limit as you are testing or
developing the code (how likely is that?), and the person hitting the limit
has control over the code that does this. If it's in a library where it's
usually not a problem, a library you don't directly control but that you're
using in a way that triggers the limit -- for example, mixing the library
with *other* library code you don't control -- the limit is just a burden.
>
> > Could there be people doing this deliberately? If so, it must be nice
> > to have so much RAM that we can afford to waste it so prodigiously: a
> > namedtuple with ten items uses 64 bytes, but the associated class uses
> > 444 bytes, plus the sizes of the methods etc. But I suppose there could
> > be a justification for such a design.
>
> You're saying that someone might have a justification for deliberately
> creating a million classes, based on an example that on the face of it
> is a programmer error (creating multiple classes when a single shared
> class would be better) and presuming that there *might* be a reason
> why this isn't an error? Well, yes - but I could just as easily say
> that someone might have a justification for creating a million classes
> in one program, and leave it at that. Without knowing (roughly) what
> the justification is, there's little we can take from this example.
>
> Having said that, I don't really have an opinion on this change.
> Basically, I feel that it's fine, as long as it doesn't break any of
> my code (which I can't imagine it would) but that's not very helpful!
> https://xkcd.com/1172/ ("Every change breaks someone's workflow")
> comes to mind here.
>
> Paul
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/YDMTJXAPYRHG3HQZ7ERYBTPYXNLU67ZZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Thomas Wouters <tho...@python.org>
Hi! I'm an email virus! Think twice before sending your email to help me
spread!
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/D4PIUUJJG2UUVG4JEC2BAWQU2G6WPLNM/
Code of Conduct: http://python.org/psf/codeofconduct/
