Depricated String Functions in Python

Discussion in 'Python' started by Anoop, Jul 20, 2006.

  1. Anoop

    Anoop Guest

    Hi All

    Can any one help me out with the various depricated string functions
    that is followed in Python.

    For example how will be string.lower depricated.

    As far as string.lower('PYTHON') is concerned it is depricated as
    'PYTHON'.lower(). Both of them would return an output : >>> python

    Thanks for your inputs

    Regards

    Anoop
    Anoop, Jul 20, 2006
    #1
    1. Advertising

  2. Anoop wrote:
    > Can any one help me out with the various depricated string functions
    > that is followed in Python.
    >
    > For example how will be string.lower depricated.
    >
    > As far as string.lower('PYTHON') is concerned it is depricated as
    > 'PYTHON'.lower(). Both of them would return an output : >>> python


    I don't quite see the question in your post, but, yes, the module level
    functions of the "string" module are deprecated in favour of the methods of
    the str and unicode objects.

    Stefan
    Stefan Behnel, Jul 20, 2006
    #2
    1. Advertising

  3. Anoop

    Steve Holden Guest

    Anoop wrote:
    > Hi All
    >
    > Can any one help me out with the various depricated string functions
    > that is followed in Python.
    >
    > For example how will be string.lower depricated.
    >
    > As far as string.lower('PYTHON') is concerned it is depricated as
    > 'PYTHON'.lower(). Both of them would return an output : >>> python
    >
    > Thanks for your inputs
    >

    I wonder if this isn't just an English problem: the fact that the
    functions of the string module is depracated just means that you are
    encouraged to use the string objects' methods instead, as the string
    module is likely to be removed at some time in the future.

    regards
    Steve
    --
    Steve Holden +44 150 684 7255 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://holdenweb.blogspot.com
    Recent Ramblings http://del.icio.us/steve.holden
    Steve Holden, Jul 20, 2006
    #3
  4. Anoop

    John Machin Guest

    On 20/07/2006 5:18 PM, Steve Holden wrote:
    > Anoop wrote:
    >> Hi All
    >>
    >> Can any one help me out with the various depricated string functions
    >> that is followed in Python.
    >>
    >> For example how will be string.lower depricated.
    >>
    >> As far as string.lower('PYTHON') is concerned it is depricated as
    >> 'PYTHON'.lower(). Both of them would return an output : >>> python
    >>
    >> Thanks for your inputs
    >>

    > I wonder if this isn't just an English problem: the fact that the
    > functions of the string module is depracated


    "depracated"? "functions ... is"? Yup, sure looks like an English
    problem to me :)

    Perhaps the docs should use simpler words like "outdated" or "not
    preferred" or such-like instead of "depr*e*cated".

    Cheers,
    John
    John Machin, Jul 20, 2006
    #4
  5. Anoop

    Steve Holden Guest

    John Machin wrote:
    > On 20/07/2006 5:18 PM, Steve Holden wrote:
    >
    >>Anoop wrote:
    >>
    >>>Hi All
    >>>
    >>>Can any one help me out with the various depricated string functions
    >>>that is followed in Python.
    >>>
    >>>For example how will be string.lower depricated.
    >>>
    >>>As far as string.lower('PYTHON') is concerned it is depricated as
    >>>'PYTHON'.lower(). Both of them would return an output : >>> python
    >>>
    >>>Thanks for your inputs
    >>>

    >>
    >>I wonder if this isn't just an English problem: the fact that the
    >>functions of the string module is depracated

    >
    >
    > "depracated"? "functions ... is"? Yup, sure looks like an English
    > problem to me :)
    >

    Nobody likes a smartarse :)

    > Perhaps the docs should use simpler words like "outdated" or "not
    > preferred" or such-like instead of "depr*e*cated".
    >

    That probably wouldn't be a bad idea. Please note, however, that even if
    the documentation spelled everything correctly I would doubtless
    continue to mangle the spellings through typos.

    regards
    Steve
    --
    Steve Holden +44 150 684 7255 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://holdenweb.blogspot.com
    Recent Ramblings http://del.icio.us/steve.holden
    Steve Holden, Jul 20, 2006
    #5
  6. Steve Holden enlightened us with:
    >> Perhaps the docs should use simpler words like "outdated" or "not
    >> preferred" or such-like instead of "depr*e*cated".

    >
    > That probably wouldn't be a bad idea.


    I don't think it'll help much. If someone can program a computer,
    he/she certainly should be able to look up a word in a dictionary.

    Sybren
    --
    The problem with the world is stupidity. Not saying there should be a
    capital punishment for stupidity, but why don't we just take the
    safety labels off of everything and let the problem solve itself?
    Frank Zappa
    Sybren Stuvel, Jul 20, 2006
    #6
  7. Anoop

    Anoop Guest

    Thanks Stefen

    let me be more specific how would i have to write the following
    function in the deprecated format

    map(string.lower,list)

    Thanks Anoop


    Stefan Behnel wrote:
    > Anoop wrote:
    > > Can any one help me out with the various depricated string functions
    > > that is followed in Python.
    > >
    > > For example how will be string.lower depricated.
    > >
    > > As far as string.lower('PYTHON') is concerned it is depricated as
    > > 'PYTHON'.lower(). Both of them would return an output : >>> python

    >
    > I don't quite see the question in your post, but, yes, the module level
    > functions of the "string" module are deprecated in favour of the methods of
    > the str and unicode objects.
    >
    > Stefan
    Anoop, Jul 20, 2006
    #7
  8. Anoop

    Steve Holden Guest

    Anoop wrote:
    > Thanks Stefen
    >
    > let me be more specific how would i have to write the following
    > function in the deprecated format
    >
    > map(string.lower,list)
    >

    To avoid the deprecated usage you would use the unbound method of the
    str type (that's the type of all strings):

    >>> lst = ['Steve', 'Holden']
    >>> map(str.lower, lst)

    ['steve', 'holden']
    >>>


    regards
    Steve
    --
    Steve Holden +44 150 684 7255 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://holdenweb.blogspot.com
    Recent Ramblings http://del.icio.us/steve.holden
    Steve Holden, Jul 20, 2006
    #8
  9. Anoop

    Simon Forman Guest

    Anoop wrote:
    > Thanks Stefen
    >
    > let me be more specific how would i have to write the following
    > function in the deprecated format
    >
    > map(string.lower,list)
    >
    > Thanks Anoop


    Ah. This is easy enough:

    lower_list = [s.lower() for s in str_list]

    Or, if you really like map() (or really don't like list comprehensions
    ;P ) you could use this:

    lower_list = map(lambda s : s.lower(), str_list)


    Hope this helps,
    ~Simon
    Simon Forman, Jul 20, 2006
    #9
  10. Anoop

    Duncan Booth Guest

    Anoop wrote:

    > let me be more specific how would i have to write the following
    > function in the deprecated format
    >
    > map(string.lower,list)


    What you just wrote is the deprecated format.

    There are plenty of ways to write it in an undeprecated format. The
    simplest is probably:

    [ s.lower() for s in list ]
    Duncan Booth, Jul 20, 2006
    #10
  11. Anoop

    Guest

    Steve Holden ha scritto:

    > Anoop wrote:
    > > Thanks Stefen
    > >
    > > let me be more specific how would i have to write the following
    > > function in the deprecated format
    > >
    > > map(string.lower,list)
    > >

    > To avoid the deprecated usage you would use the unbound method of the
    > str type (that's the type of all strings):
    >
    > >>> lst = ['Steve', 'Holden']
    > >>> map(str.lower, lst)

    > ['steve', 'holden']
    > >>>


    This isn't exactly equal to use string.lower, because this work with
    just encoded strings, when string.lower works with unicode too.
    I'm used to have a "lower" func like this one
    def lower(x): return x.lower()
    to use in map. Of course it's a problem when you need many different
    methods.

    A solution could be something like this
    >>> def doit(what):

    .... def func(x):
    .... return getattr(x,what)()
    .... return func
    ....
    >>> map(doit('lower'),['aBcD',u'\xc0'])

    ['abcd', u'\xe0']
    >>> map(doit('upper'),['aBcD',u'\xc0'])

    ['ABCD', u'\xc0']

    The best is to use in advance just unicode or encoded strings in your
    program, but this is not always possible :-/

    Riccardo Galli
    , Jul 20, 2006
    #11
  12. Anoop

    Donn Cave Guest

    In article <>,
    Steve Holden <> wrote:

    > Anoop wrote:
    > > Thanks Stefen
    > >
    > > let me be more specific how would i have to write the following
    > > function in the deprecated format
    > >
    > > map(string.lower,list)
    > >

    > To avoid the deprecated usage you would use the unbound method of the
    > str type (that's the type of all strings):
    >
    > >>> lst = ['Steve', 'Holden']
    > >>> map(str.lower, lst)

    > ['steve', 'holden']


    Oh, excellent - the string module is dead, long live
    the string module! I can replace string.join with
    str.join, and never have to defile my code with that
    ' '.join(x) abomination.


    Donn Cave,
    Donn Cave, Jul 20, 2006
    #12
  13. Donn Cave enlightened us with:
    > Oh, excellent - the string module is dead, long live the string
    > module! I can replace string.join with str.join, and never have to
    > defile my code with that ' '.join(x) abomination.


    It's not an abomination. It's a very clear way of telling those two
    apart:

    ' '.join(x)
    u' '.join(x)

    Sybren
    --
    The problem with the world is stupidity. Not saying there should be a
    capital punishment for stupidity, but why don't we just take the
    safety labels off of everything and let the problem solve itself?
    Frank Zappa
    Sybren Stuvel, Jul 20, 2006
    #13
  14. Anoop

    Steve Holden Guest

    Donn Cave wrote:
    [...]
    >
    > Oh, excellent - the string module is dead, long live
    > the string module! I can replace string.join with
    > str.join, and never have to defile my code with that
    > ' '.join(x) abomination.
    >
    >>> lst = ['Steve', 'Holden']
    >>> str.join(' ', lst)

    'Steve Holden'
    >>>


    Just so long as you don't complain about the arguments being in the
    wrong order ...

    regards
    Steve
    --
    Steve Holden +44 150 684 7255 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://holdenweb.blogspot.com
    Recent Ramblings http://del.icio.us/steve.holden
    Steve Holden, Jul 20, 2006
    #14
  15. Anoop

    Duncan Booth Guest

    Sybren Stuvel wrote:

    > Donn Cave enlightened us with:
    >> Oh, excellent - the string module is dead, long live the string
    >> module! I can replace string.join with str.join, and never have to
    >> defile my code with that ' '.join(x) abomination.

    >
    > It's not an abomination. It's a very clear way of telling those two
    > apart:
    >
    > ' '.join(x)
    > u' '.join(x)


    I don't understand that comment. Are you saying that str.join vs
    unicode.join isn't a clear distinction?

    I like using str.join/unicode.join myself, but one advantage of using
    separator.join directly is that you can save the bound method:

    joinlines = '\n'.join
    joinwords = ' '.join

    you can't do that by calling the method on the type.
    Duncan Booth, Jul 21, 2006
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sweety
    Replies:
    1
    Views:
    398
    Christophe Vanfleteren
    Oct 23, 2003
  2. Xiangliang Meng
    Replies:
    1
    Views:
    1,591
    Victor Bazarov
    Jun 21, 2004
  3. Hitesh
    Replies:
    3
    Views:
    296
    Hitesh
    Aug 16, 2006
  4. korean_dave
    Replies:
    2
    Views:
    317
    John Machin
    Jun 17, 2008
  5. py
    Replies:
    5
    Views:
    301
    Daniel DeLorme
    Mar 24, 2007
Loading...

Share This Page