[FRPythoneers] Some newbie observations

Sean Reifschneider jafo at tummy.com
Wed Sep 24 11:12:54 MDT 2003


On Wed, Sep 24, 2003 at 03:03:53PM +0530, Rahul Kumar wrote:
>1. if my program has "import string" first, later i replace that line
>with "from string import split, join", then i need to remove the
>"string." from my entire program, otherwise it gives an error.

You don't have to REPLACE that line.  You could have:

   from string import join, split
   import string

However, if you *DO* replace one with the other, you are importing the
join and split names directly into your current name-space.  This means
that they can be accessed without the leading "string.".  If you want to
continue to access them with "string.", don't import members directly
into your current name-space.

Why are you suprised that renaming "string.join" to "join" causes an
error when you try to access it using "string.join"?

Also note that using the string module is being deprecated in favor of
using methods on strings.  For example:

   >>> 'this is a test'.split()
   ['this', 'is', 'a', 'test']
   >>> ':'.join(['foo', 'bar', 'baz'])
   'foo:bar:baz'

>2. I am studying some source of other projects to improve my knowledge.
>I have a problem figuring out argument types to methods and return
>types. I understand this is how it is in a language that is not strongly
>typed, but do you face this problem too ? How to you get around it ?

My docstring will usually include information about what type I'm
expecting.  The trick is that Python is more concerned with what an
argument can do rather than what literal type it is.  It's less
important that it's truely a list, than that you can iterate over the
elements in it.

I don't really find that, when looking at other code, it's super
important that I know exactly what type it is.  Sometimes it is,
however, and you end up tracking down where it's called to get more
information about the objects that are passed in.

>3. I wrote a file with many "def"s (functions). Then i wanted to convert
>it into a class. In Python, that seems to require a lot more effort than
>in other OOP languages. One reason was all the "self"'s that had to be
>added. (I know that i cd have used "s.", but still they have to be added
>all over the place, and you keep getting errors till its done. Any easy
>way or script for that ?

Not that I know of.

>a) Built-in functions are great but can confuse the newbie in the sense
>that you look for a length or cmp method in string. Now i have to
>remember to keep looking through the builtin list.
>For some objects, we say "del a[i]", for some its "a.del(i)". Shoudlnt
>that latter be provided also ?

Adding a "del" method to every object?  I don't know about that.  If
everything is going to have it, it's probably best to have it not have
to be added to every object's name-space.

>b) Another one that keeps getting me is having to say
>string.split(mystring, ...) rather than mystring.split(..). i believe
>both styles are correct but for different classes.

Strings and string-like objects should have a .split() method with them.
If they aren't strings, you'll probably need to convert them to strings
first using str(), then you can call .split() on them.  mystring.split()
should work, and is now the preferred way.

>c) Am i right in saying that variables declared in an if block, are not
>part of that scope ? 

I don't think so.  First of all, Python doesn't really have variables,
it has names which are bound to objects.  If a name is bound in a block,
it is available in that scope:

   >>> if 1:
   ...    s = 'foo'
   ...    print s
   ... 
   foo

The name "s" is available in the scope of the if statement.  It also
spills out of it:

   >>> print s
   foo

The same does not happen for functions:

   >>> def test():
   ...    s = 'baz'
   ...    print s
   ... 
   >>> test()
   baz
   >>> print s
   foo

Sean
-- 
 Hi, my name's Sean, but my friends call me...  Actually, my friends USUALLY
 e-mail me...  -- Sean Reifschneider, 2000
Sean Reifschneider, Member of Technical Staff <jafo at tummy.com>
tummy.com, ltd. - Linux Consulting since 1995.  Qmail, Python, SysAdmin



More information about the FRPythoneers mailing list