[PATCH 1/2] A function for resolving date format and order

Anne Mulhern amulhern at redhat.com
Thu Oct 9 12:41:09 UTC 2014





----- Original Message -----
> From: "Vratislav Podzimek" <vpodzime at redhat.com>
> To: "anaconda patch review" <anaconda-patches at lists.fedorahosted.org>
> Sent: Thursday, October 9, 2014 5:41:56 AM
> Subject: Re: [PATCH 1/2] A function for resolving date format and order
> 
> On Wed, 2014-10-08 at 08:31 -0400, Anne Mulhern wrote:
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Vratislav Podzimek" <vpodzime at redhat.com>
> > > To: "anaconda patch review" <anaconda-patches at lists.fedorahosted.org>
> > > Sent: Wednesday, October 8, 2014 3:19:50 AM
> > > Subject: Re: [PATCH 1/2] A function for resolving date format and order
> > > 
> > > On Tue, 2014-10-07 at 17:29 -0400, Anne Mulhern wrote:
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Vratislav Podzimek" <vpodzime at redhat.com>
> > > > > To: anaconda-patches at lists.fedorahosted.org
> > > > > Sent: Tuesday, October 7, 2014 12:32:36 PM
> > > > > Subject: [PATCH 1/2] A function for resolving date format and order
> > > > > 
> > > > > It's not that easy to get right order of date fields (year, month,
> > > > > day)
> > > > > and
> > > > > their formats so we should better have it in a standalone function
> > > > > with
> > > > > tests.
> > > > > 
> > > > > Related: rhbz#1044233
> > > > > Signed-off-by: Vratislav Podzimek <vpodzime at redhat.com>
> > > > > ---
> > > > >  pyanaconda/localization.py                  | 64
> > > > >  +++++++++++++++++++++++++++++
> > > > >  tests/pyanaconda_tests/localization_test.py | 21 ++++++++++
> > > > >  2 files changed, 85 insertions(+)
> > > > > 
> > > > > diff --git a/pyanaconda/localization.py b/pyanaconda/localization.py
> > > > > index c95fa1d..efcb66f 100644
> > > > > --- a/pyanaconda/localization.py
> > > > > +++ b/pyanaconda/localization.py
> > > > > @@ -26,6 +26,7 @@ import re
> > > > >  import langtable
> > > > >  import locale as locale_mod
> > > > >  import glob
> > > > > +from collections import namedtuple
> > > > >  
> > > > >  from pyanaconda import constants
> > > > >  from pyanaconda.iutil import upcase_first_letter
> > > > > @@ -469,3 +470,66 @@ def load_firmware_language(lang):
> > > > >  
> > > > >      log.debug("Using UEFI PlatformLang '%s' ('%s') as our
> > > > >      language.", d,
> > > > >      locales[0])
> > > > >      setup_locale(locales[0], lang)
> > > > > +
> > > > > +_DateFieldSpec = namedtuple("DateFieldSpec", ["format", "suffix"])
> > > > > +
> > > > > +def resolve_date_format(year, month, day):
> > > > > +    """
> > > > > +    Puts the year, month and day objects in the right order
> > > > > according to
> > > > > the
> > > > > +    currently set locale and provides format specification for each
> > > > > of
> > > > > the
> > > > > +    fields.
> > > > > +
> > > > > +    :param year: any object or value representing year
> > > > > +    :type year: any
> > > > > +    :param month: any object or value representing month
> > > > > +    :type month: any
> > > > > +    :param day: any object or value representing day
> > > > > +    :type day: any
> > > > 
> > > > Uses of 'any' for type should be changed to 'object'.
> > > Does 'object' involve ints, floats, etc.?
> > > 
> > 
> > Yes. And any() is a function on an iterable.
> Yeah, I know and use any().
> 
> > 
> > [mulhern at localhost ~]$ python
> > Python 2.7.5 (default, Jun 19 2014, 12:16:30)
> > [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> issubclass(int, object)
> > True
> Old-style classes wouldn't work, but whatever, I've changed 'any' to
> 'object'.
> 

That's true, and classes, module definitions, on which your method
also works correctly, certainly don't have type 'object'.
I don't see why instances of old-style classes,
any more than class definitions, should be passed to this method, but it might happen.

I feel that I was unduly influenced by Sphinx's habit
of linking from any entry with a recognizable name, no matter how inappropriate for the context.

I've filed a bug against sphinx
(https://bitbucket.org/birkenfeld/sphinx/issue/1592/type-or-rtype-value-should-only-link-to).

Feel free to revert to 'any', with the caveat that sphinx will put a link to the function any()
there (even though that is obviously not what you mean).

<-- SNIP -->

> 
> --
> Vratislav Podzimek
> 
> Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
> 
> _______________________________________________
> anaconda-patches mailing list
> anaconda-patches at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
> 


More information about the anaconda-patches mailing list