syntax questions
Philippe Gendreau
I'm fairly new to python and there a thing I don't understand in the
syntax. What is it with the "_". I have seen it used in many places for
what seems to be different puposes like:
from x import _
Also, I'd like to understand this syntax: "((_(name),))"
here's an example where it's used:
# stuff a list
for dir in os.listdir('/usr/share/themes'):
row = self.theme.append ((_(dir),))
self.theme.set_row_data (row, dir)
More precisely, what are the comma and underscore for?
Thanks
--
Philippe Gendreau
Chris Liechti
news:mailman.1027526320...@python.org:
you want to call "append" on the variable "self.theme" which seems to be a
list, therefore the outher parantheses:
self.theme.append(...)
you want to add a tuple to the list:
(...,)
a tuple with just one argument needs a coma at the end, otherwise it would
be an arithmetic expression ans no tupple.
and finaly you call a function with the name "_":
_(dir)
that is sometimes used to localize names i.e. the "_" function translates
the given string to the local language. to be sure what it does you have to
search for the implementation in you current sourcecode.
note that "dir" is somewhat a bad name for that variable because
a) there is a builtin function that name that you hide
b) its not a directory name but a filename without path in the above case
in the intercative prompt "_" is bound to the last result so that you can
do further calculations:
>>> 1+1
2
>>> _*3
6
chris
--
Chris <clie...@gmx.net>
Fredrik Lundh
> I'm fairly new to python and there a thing I don't understand in the
> syntax. What is it with the "_". I have seen it used in many places for
> what seems to be different puposes like:
>
> from x import _
here, you're importing something named "_" (most likely
a function) from the x module.
judging from your example, the "_" function is probably
used to translate strings from english to the local language.
for some reason, people doing internationalization (i18n) and
localization (l10n) stuff seem to prefer to use functions called
"_", probably only to confuse people like you and me.
> Also, I'd like to understand this syntax: "((_(name),))"
the _(name) part is simply a call to the translation function.
it could have been written like, say
local_name = _(name)
or even
local_name = translate(name)
the (x,) part creates a tuple containing a single item (see the
tutorial and the language reference for more info on tuples).
a_tuple = (local_name,)
the outermost () belongs to the append method call:
theme.append(a_tuple)
(according to the python style guide, and common sense, it's
bad style to put a space between the function/method name
and the parentheses...)
</F>
Philippe Gendreau
> you want to call "append" on the variable "self.theme" which seems to be a
> list, therefore the outher parantheses:
> self.theme.append(...)
>
> you want to add a tuple to the list:
> (...,)
>
> a tuple with just one argument needs a coma at the end, otherwise it would
> be an arithmetic expression ans no tupple.
The imbrication of those structures can sometime be confusing...
Thanks for clearing that out.
> and finaly you call a function with the name "_":
> _(dir)
> that is sometimes used to localize names i.e. the "_" function translates
> the given string to the local language. to be sure what it does you have to
> search for the implementation in you current sourcecode.
Ah! this is a function name?
As you say, I will have to look
into the code to see what it does...
> note that "dir" is somewhat a bad name for that variable because
> a) there is a builtin function that name that you hide
> b) its not a directory name but a filename without path in the above case
Note taken.
I know about the dir() function, but I'm surprised that my list object
hides a function object (even if they have the same name).
Is that how python treats names all the time? Does it mean you can't
have a class, def and variable of the same name?
> in the intercative prompt "_" is bound to the last result so that you can
> do further calculations:
> >>> 1+1
> 2
> >>> _*3
> 6
Nice, this is probably why It seemed to be used for many purpose.
if I understand well, this behavior is just in the interactive mode.
If I use '_' in a module it is just an identifier.
Thank you.
--
Philippe Gendreau
Daniel Fackrell
> > a) there is a builtin function that name that you hide
> > b) its not a directory name but a filename without path in the above
case
>
> Note taken.
> I know about the dir() function, but I'm surprised that my list object
> hides a function object (even if they have the same name).
> Is that how python treats names all the time? Does it mean you can't
> have a class, def and variable of the same name?
At least not in the same scope. For example, you could have a function foo
in a class instance foo:
foo.foo()
but having that, doing foo=3 would reassign foo so that the class instance
is no longer accessible (unless it's referenced elsewhere), while foo.foo=3
would do the same thing to the function for the instance.
On the bright side, this is related to the fact that python tries to treat
everything as equally as possible, which leads to useful behaviors as being
able to pass functions or classes, along with other objects, to functions.
--
Daniel Fackrell (dfac...@linuxmail.org)
When we attempt the impossible, we can experience true growth.
Philippe Gendreau
> Philippe Gendreau wrote:
> > I'm fairly new to python and there a thing I don't understand in the
> > syntax. What is it with the "_". I have seen it used in many places for
> > what seems to be different puposes like:
> >
> > from x import _
>
> here, you're importing something named "_" (most likely
> a function) from the x module.
>
> judging from your example, the "_" function is probably
> used to translate strings from english to the local language.
>
> for some reason, people doing internationalization (i18n) and
> localization (l10n) stuff seem to prefer to use functions called
> "_", probably only to confuse people like you and me.
lol, it is indeed a translation function.
>
> > Also, I'd like to understand this syntax: "((_(name),))"
>
> the _(name) part is simply a call to the translation function.
> it could have been written like, say
>
> local_name = _(name)
>
> or even
>
> local_name = translate(name)
>
> the (x,) part creates a tuple containing a single item (see the
> tutorial and the language reference for more info on tuples).
>
> a_tuple = (local_name,)
>
> the outermost () belongs to the append method call:
>
> theme.append(a_tuple)
>
> (according to the python style guide, and common sense, it's
> bad style to put a space between the function/method name
> and the parentheses...)
I agree, I didn't write this code, but it just felt wrong.
I'll have a look at the styleguide, thanks for the help.
--
Philippe Gendreau
Michael Chermside
> hides a function object (even if they have the same name).
> Is that how python treats names all the time? Does it mean you can't
> have a class, def and variable of the same name?
Yes, that's how it works all the time.
Actually, the ADVANTAGE of this is that you aren't required to memorize
the entire list of all built-in functions and things. For instance, if
you NEVER, EVER use the "input" function (as well you shouldn't), then
it's not going to hurt you if you use a line like:
for input in sys.stdin:
process(input)
Of course, it's still not a good idea, but you aren't forced to memorize
the list of built-in stuff, nor does old code break when a new built-in
function is added (which happens rarely, but does happen).
As for having a class, a "def" (ie, function), and a variable all with
the same name, no... not in the same namespace. And this is good.
Because in Python (unlike some languages), a function, a class, and a
"variable", are all objects, and can be used interchangably.
Consider the map() function. It is normally passed a function as its
first argument and applies it to the items in a list:
>>> def add5(x):
return x + 5
>>> map( add5, range(4) )
[5, 6, 7, 8]
But classes are instantiated by calling them, as if they were functions.
So we can pass a class in, where it expects a function, and it all works
just fine:
>>> from UserString import UserString
>>> map( UserString, range(4) )
['0', '1', '2', '3']
We could even use a variable to store the item to pass... resulting in
code like this:
>>> f1 = add5
>>> f2 = UserString
>>> [ map(f, range(4)) for f in f1, f2]
[[5, 6, 7, 8], ['0', '1', '2', '3']]
So the fact that all things are just "objects" and don't have separate
namespaces is highly useful, since it comes closer to making
"everything" first class objects, giving the language more power.
-- Michael Chermside
Sean 'Shaleh' Perry
> for some reason, people doing internationalization (i18n) and
> localization (l10n) stuff seem to prefer to use functions called
> "_", probably only to confuse people like you and me.
>
1) it is guaranteed not to clash with the local namespace and in languages like
C that is all you have. Once this became common in C it moved to other
languages because that way the coder need only learn one style.
2) it is short and so remains inconspicuous and does not hurt people trying to
fit code onto 78 char screens. For the jerks fighting the l10n effort it was
much harder to fight _() than say translate().
One of the projects I work on uses i18n(string) which I like.
François Pinard
> for some reason, people doing internationalization (i18n) and localization
> (l10n) stuff seem to prefer to use functions called "_", probably only
> to confuse people like you and me.
The habit came into Python from C, and it came into C from me! :-)
In C, `_()' is implemented as a C pre-processor macro, as a short form for
the `gettext()' macro which, we soon discovered, was visually obtrusive.
Marking strings for localisation should consume as little horizontal space
as possible, and not be too distracting for people reading source code,
while not conflicting with other usages. For example, using a single
letter would surely have been source for a lot of conflicts! :-)
In C, `_' had no previous meaning. To check it, I implemented `_()' in a
few widely ported packages (the `tar' program among others), and since no
user complained for a few releases, we took this as a kind of proof that
it was safe to use more generally, and the habit sprout from there.
I'm not sure `_' is ideal in Python, even if not bad. `_' in Python has
already the meaning, in interactive mode, of the last computation. Moreover,
by fully being a run-time function, it is a bit late to get help from the
Python compiler, if more sophisticated usages ever asks for such help.
--
François Pinard http://www.iro.umontreal.ca/~pinard
Philippe Gendreau
Thanks it makes sense, I see where it can be useful.
I think I'm gonna like python...
--
Philippe Gendreau
Andreas Kostyrka
> I'm not sure `_' is ideal in Python, even if not bad. `_' in Python has
> already the meaning, in interactive mode, of the last computation. Moreover,
> by fully being a run-time function, it is a bit late to get help from the
> Python compiler, if more sophisticated usages ever asks for such help.
from gettext import _ as i18n
Not sure how this works out with the "string collecting" utility.
Andreas