[IPython-dev] New display methods, should we fine-tune our naming decision?
MinRK
benjaminrk at gmail.com
Tue Feb 1 21:16:52 EST 2011
On Tue, Feb 1, 2011 at 18:05, Paul Ivanov <pivanov314 at gmail.com> wrote:
> MinRK, on 2011-02-01 17:13, wrote:
> > On Tue, Feb 1, 2011 at 16:21, Brian Granger <ellisonbg at gmail.com> wrote:
> > > Let's find a different naming convention for these. What do
> > > people prefer?
> >
> > My vote might be for '__htmlrepr__',
> > I like 'htmlrepr' more than 'repr_html' because it's 'html
> representation'
> > not 'representation html', despite the tab-completion friendliness of the
> > latter pattern.
>
> I'd vote the other way, since obj.__repr_<tab> is a lot nicer to use
> than writing a one-liner to get everything with a 'repr'
> substring to see in what manner you can represent a given object.
> Also, I don't think I'm alone in poking around an object I don't
> know much about using just obj.<tab>, and the __repr_html__
> convention would keep all of the reprs listed next to each other,
> instead of sprinkled about.
>
> I read __repr_html__ as "representation: html", or "represented
> as html", which makes sense from a course-to-fine /
> general-to-specific type of convention. Consider how annoying it
> would be if get_foo and set_foo methods of some object swapped
> the order of the verb and the noun and you couldn't easily figure
> out what all the things you could get and set were. The same goes
> for IPython.iplib.InteractiveShell.magic_*, which is easier to
> wrap one's head around than .*_magic
>
Well put, I'm convinced.
I still don't like having underscores in the middle of __x_y__ method names.
I think it's ugly, but I also think PEP8 is terrible, so maybe ignore me on
that point.
An alternative to developers writing methods in their classes would be for
the Display system to use its own lookup table for representation methods,
and provide an extension API for modules, IPython, third-parties, or users
to register additional methods for classes. This would be more elaborate,
but would make the display system a better Python citizen, and would
eliminate the possiblity of collision with other projects' private
conventions.
-MinRK
>
> best,
> --
> Paul Ivanov
> 314 address only used for lists, off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1Iu9kACgkQe+cmRQ8+KPeVVQCfdgts2XwnsnKosaW1J3Aae7v+
> URMAn2qm+98LxbGpnV+8Bvmr58X3lWrL
> =QE5n
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110201/6283923c/attachment-0001.html>
More information about the IPython-dev
mailing list