On 25 juillet 11:32, Torsten Marek wrote:
> > 28fb5be7df58: .messages property could simply return ._messages.values,
> > right?
> >
> > Also, couldn't we have former id/symbolic name in the optional message
> > dictionary already containing extra information?
> >
>
> I thought about that, but it can be a bit more complicated than that,
> especially when there's a 1:n mapping between new and old messages. We
> could of course have something like
>
> {'old_names': [('C123', 'old-name')]}
>
> Also, I don't want our (Google's) warning names to leak into the public
> (because nobody cares about them), and in the case of line-too-long,
> there's on point in pylint containing information that somebody used to
> call this g-line-too-long.
FormatChecker.MSGS['line-to-long']['old_names'].append('g-line-too-long') ?
> > Or I may miss your purpose. IMO we (may) want to:
> >
> > * support deprecating a symbolic name(s?) in favor of a new one (in which
> > case
> > we should emit deprecation warning when an old name is used
> >
>
> Yes, I'll also work on emitting a warning for an old name being used, but
> it's currently outside my scope.
fair enough
> > * stop using numerical id, hence there is no point in renaming them, we
> > shall
> > rather stop using it and emit deprecation warning when they are used
> >
> I don't think we're ready yet to deprecated numerical IDs, maybe in 1.1?
I agree, that was just a goal reminder :)
--
Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure: http://www.logilab.fr/services
CubicWeb, the semantic web framework: http://www.cubicweb.org
_______________________________________________
Python-Projects mailing list
Python-Projects@lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
