Re: n00b question on spacing
On 2013-06-25 01:22, Mark Janssen wrote: On Mon, Jun 24, 2013 at 4:48 PM, alex23 wuwe...@gmail.com wrote: On 23/06/2013 3:43 AM, Mark Janssen wrote: There was a recent discussion about this (under implicit string concatenation). It seems this is a part of the python language specification that was simply undefined. It's part of the language reference, not an accidental artifact: http://docs.python.org/2/reference/lexical_analysis.html#string-literal-concatenation When I say specification, I mean specified in the formal notation (BNF, etc). There is quite a bit of Python's lexical analysis that is specified in places other than the formal notation. That does not mean it is undefined. It is well defined in the lexer code and the documentation. You suggest that a rule probably should be added to the lexer to make this explicit. That is not necessary. The rule is already there. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Tue, Jun 25, 2013 at 9:19 PM, Robert Kern robert.k...@gmail.com wrote: There is quite a bit of Python's lexical analysis that is specified in places other than the formal notation. That does not mean it is undefined. It is well defined in the lexer code and the documentation. You suggest that a rule probably should be added to the lexer to make this explicit. That is not necessary. The rule is already there. Be careful; Python is not an implementation-defined language. Python has no lexer code - CPython does, and is probably what you're thinking of. (There are other languages that *are* implementation-defined, meaning that it *is* correct to talk about features in that way. Python just isn't one of them.) Sometimes a rule needs to be clarified to mandate something that was previously left up to the implementation; however, if that's the case, the rule would not be added to the lexer, but to the documentation. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 2013-06-25 12:48, Chris Angelico wrote: On Tue, Jun 25, 2013 at 9:19 PM, Robert Kern robert.k...@gmail.com wrote: There is quite a bit of Python's lexical analysis that is specified in places other than the formal notation. That does not mean it is undefined. It is well defined in the lexer code and the documentation. You suggest that a rule probably should be added to the lexer to make this explicit. That is not necessary. The rule is already there. Be careful; Python is not an implementation-defined language. Python has no lexer code - CPython does, and is probably what you're thinking of. No, that's not what I am thinking of. I said that the rule is defined in both code and the documentation. Mark did suggest adding the rule to the lexer (for which he may have been thinking of just CPython, but you can take that up with him), but of course it is already there. I did not suggest that its presence in the lexer code (of any or all implementations) is sufficient, but the point is moot because it is already both explicitly implemented (several times) and clearly documented in the Python language reference. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Tue, Jun 25, 2013 at 9:59 PM, Robert Kern robert.k...@gmail.com wrote: On 2013-06-25 12:48, Chris Angelico wrote: On Tue, Jun 25, 2013 at 9:19 PM, Robert Kern robert.k...@gmail.com wrote: There is quite a bit of Python's lexical analysis that is specified in places other than the formal notation. That does not mean it is undefined. It is well defined in the lexer code and the documentation. You suggest that a rule probably should be added to the lexer to make this explicit. That is not necessary. The rule is already there. Be careful; Python is not an implementation-defined language. Python has no lexer code - CPython does, and is probably what you're thinking of. No, that's not what I am thinking of. I said that the rule is defined in both code and the documentation. Mark did suggest adding the rule to the lexer (for which he may have been thinking of just CPython, but you can take that up with him), but of course it is already there. I did not suggest that its presence in the lexer code (of any or all implementations) is sufficient, but the point is moot because it is already both explicitly implemented (several times) and clearly documented in the Python language reference. Sure, fair enough. I've just been skimming this thread, lately, so please don't take my post as implying that you're wrong-wrong-wrong... it's just something that seemed to want clarifying :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 23/06/2013 3:43 AM, Mark Janssen wrote: There was a recent discussion about this (under implicit string concatenation). It seems this is a part of the python language specification that was simply undefined. It's part of the language reference, not an accidental artifact: http://docs.python.org/2/reference/lexical_analysis.html#string-literal-concatenation -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Mon, Jun 24, 2013 at 4:48 PM, alex23 wuwe...@gmail.com wrote: On 23/06/2013 3:43 AM, Mark Janssen wrote: There was a recent discussion about this (under implicit string concatenation). It seems this is a part of the python language specification that was simply undefined. It's part of the language reference, not an accidental artifact: http://docs.python.org/2/reference/lexical_analysis.html#string-literal-concatenation When I say specification, I mean specified in the formal notation (BNF, etc). whitespace is not defined (otherwise there would be a line in the token list for linefeed and carriagereturn. -- MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
In article 51c66a03$0$2$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sat, 22 Jun 2013 23:12:49 -0400, Roy Smith wrote: Number 2 on the list is Months have either 30 or 31 days, which was obviously believed by whoever made this sign: http://tinyurl.com/mgv39on Can you link directly to the image? Facebook and my browser don't get on. http://www.panix.com/~roy/429211_490456177653518_2055059398_n.jpg -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 6/22/2013 9:20 PM, MRAB wrote: [snip] One vs not-one isn't good enough. Some languages use the singular with any numbers ending in '1'. Some languages have singular, dual, and plural. Etc. It's surprising how inventive people can be! :-) In the Idle output window for file grepping, I just changed the summary line 'Found %d hit%s' to 'Hits found: %d' to avoid the pluralization problem (even though the language is just English for now). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
Yves S. Garret yoursurrogate...@gmail.com writes:
I have the following line of code:
log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'],
settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider)
[…]
Is this ok? Are there any rules in Python when it comes to breaking up
long lines of code?
PEP 8 is the common denominator; follow its restrictions and your code
will be a lot more readable to just about any Python programmer. So,
indent 4 columns for block structure, preferably 8 columns for
continuation lines, put spaces around binary operators, etc.
As for *where* to break long lines: I prefer the continuation lines to
be a standard indentation (4 or 8 columns), which means the indentation
doesn't need to change when the first line changes later. So I break at
an open paren, brace, bracket (‘(’, ‘{’, ‘[’) etc. and allow Python to
automatically continue the statement until that bracketing is closed.
log.msg(
Item wrote to MongoDB database %s/%s
% (settings['MONGODB_DB'], settings['MONGODB_COLLECTION']),
level=log.DEBUG, spider=spider)
That way, if the first line changes later, you don't need to change any
of the indentation on the continuation lines:
logger.info(
Item wrote to MongoDB database %s/%s
% (settings['MONGODB_DB'], settings['MONGODB_COLLECTION']),
level=log.DEBUG, spider=spider)
--
\ “[W]e are still the first generation of users, and for all that |
`\ we may have invented the net, we still don't really get it.” |
_o__) —Douglas Adams |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 21 June 2013 23:26, Gary Herron gher...@digipen.edu wrote:
On 06/21/2013 02:17 PM, Yves S. Garret wrote:
I have the following line of code:
log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'],
settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider)
...
I was thinking of splitting it up like so:
log.msg(Item wrote to MongoDB database %s/%s
%(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']),
level=log.DEBUG, spider=spider)
This is how I'd do it: (And it's *FAR* clearer -- You win no points for
clarity by having it all in one statement.)
fmt = Item wrote to MongoDB database %s/%s
msg = fmt % (settings['MONGODB_DB'],
settings['MONGODB_COLLECTION'])
log.msg(msg, level=log.DEBUG, spider=spider)
Hear, Hear.
But really, you should be using .format by now :P
My favourite way would be along the lines of:
message = Item wrote to MongoDB database
message += {0[MONGODB_DB]}/{0[MONGODB_COLLECTION]}.format(settings)
log.msg(message, level=log.DEBUG, spider=spider)
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22 June 2013 14:36, Joshua Landau joshua.landau...@gmail.com wrote: message = Item wrote to MongoDB database Pedant's note: Item *written* to MongoDB database -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22/06/2013 14:36, Joshua Landau wrote:
On 21 June 2013 23:26, Gary Herron gher...@digipen.edu wrote:
On 06/21/2013 02:17 PM, Yves S. Garret wrote:
I have the following line of code:
log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'],
settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider)
...
I was thinking of splitting it up like so:
log.msg(Item wrote to MongoDB database %s/%s
%(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']),
level=log.DEBUG, spider=spider)
This is how I'd do it: (And it's *FAR* clearer -- You win no points for
clarity by having it all in one statement.)
fmt = Item wrote to MongoDB database %s/%s
msg = fmt % (settings['MONGODB_DB'],
settings['MONGODB_COLLECTION'])
log.msg(msg, level=log.DEBUG, spider=spider)
Hear, Hear.
But really, you should be using .format by now :P
My favourite way would be along the lines of:
message = Item wrote to MongoDB database
message += {0[MONGODB_DB]}/{0[MONGODB_COLLECTION]}.format(settings)
log.msg(message, level=log.DEBUG, spider=spider)
I'm sticking with C style formatting, which thankfully isn't going away,
.format indeed.
--
Steve is going for the pink ball - and for those of you who are
watching in black and white, the pink is next to the green. Snooker
commentator 'Whispering' Ted Lowe.
Mark Lawrence
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Saturday, June 22, 2013 8:36:43 AM UTC-5, Joshua Landau wrote:
message = Item wrote to MongoDB database
message += {0[MONGODB_DB]}/{0[MONGODB_COLLECTION]}.format(settings)
log.msg(message, level=log.DEBUG, spider=spider)
If you're going to whore out parts of the string to
variables i would suggest going for the gold and actually
make it readable. Plus, your use of the format syntax is
incorrect.
_arg1 = settings['MONGODB_DB']
_arg2 = settings['MONGODB_COLLECTION']
_fmtstr = Item wrote to MongoDB database {0}, {1}
msg = _fmtstr.format(_arg1, _arg2)
log.msg(msg, level=log.DEBUG, spider=spider)
If you want readability, now you got it.
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22 June 2013 16:24, Rick Johnson rantingrickjohn...@gmail.com wrote:
On Saturday, June 22, 2013 8:36:43 AM UTC-5, Joshua Landau wrote:
message = Item wrote to MongoDB database
message += {0[MONGODB_DB]}/{0[MONGODB_COLLECTION]}.format(settings)
log.msg(message, level=log.DEBUG, spider=spider)
If you're going to whore out parts of the string to
variables i would suggest going for the gold and actually
make it readable.
Erm, as you wish.
Plus, your use of the format syntax is
incorrect.
Wut?
_arg1 = settings['MONGODB_DB']
_arg2 = settings['MONGODB_COLLECTION']
_fmtstr = Item wrote to MongoDB database {0}, {1}
msg = _fmtstr.format(_arg1, _arg2)
log.msg(msg, level=log.DEBUG, spider=spider)
If you want readability, now you got it.
If you say so.
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22 June 2013 14:36, Joshua Landau joshua.landau...@gmail.com wrote:
My favourite way would be along the lines of:
message = Item wrote to MongoDB database
message += {0[MONGODB_DB]}/{0[MONGODB_COLLECTION]}.format(settings)
log.msg(message, level=log.DEBUG, spider=spider)
To make a habit of replying to myself, I thought I'd point out I wrote
it this way mostly because I have no idea how big settings is.
If it's not large and only contains keys that are valid identifiers,
it'd be more readable to write:
message = Item wrote to MongoDB database
message += {MONGODB_DB}/{MONGODB_COLLECTION}.format(**settings)
log.msg(message, level=log.DEBUG, spider=spider)
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Saturday, June 22, 2013 10:40:24 AM UTC-5, Joshua Landau wrote: Plus, your use of the format syntax is incorrect. Wut? Well what i mean exactly is not that it's illegal, i just find the use of the getattr sugar, from WITHIN the format string, to be excessively noisy. In short, i don't care to know WHAT is being injected into the format string, i simply need to know WHERE it is being injected. It's about abstractions. It's about not violating the fundamentals of templates. -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22 June 2013 16:55, Rick Johnson rantingrickjohn...@gmail.com wrote: On Saturday, June 22, 2013 10:40:24 AM UTC-5, Joshua Landau wrote: Plus, your use of the format syntax is incorrect. Wut? Well what i mean exactly is not that it's illegal, i just find the use of the getattr sugar, from WITHIN the format string, to be excessively noisy. Sure... So in other words you realised you were wrong but you're too scared to admit it. Eh? That's it, isn't it! You just don't want to loosen your proud persona :P. In short, i don't care to know WHAT is being injected into the format string, i simply need to know WHERE it is being injected. No, I agree. It's never about what you're doing; it's where you are when you do it. It's about abstractions. It's about not violating the fundamentals of templates. Mmhmm, I too treasure these 'fundamentals'. -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sat, 22 Jun 2013 17:11:00 +0100, Joshua Landau wrote: On 22 June 2013 16:55, Rick Johnson rantingrickjohn...@gmail.com wrote: On Saturday, June 22, 2013 10:40:24 AM UTC-5, Joshua Landau wrote: Plus, your use of the format syntax is incorrect. Wut? Well what i mean exactly is not that it's illegal, i just find the use of the getattr sugar, from WITHIN the format string, to be excessively noisy. Sure... So in other words you realised you were wrong but you're too scared to admit it. Eh? That's it, isn't it! You just don't want to loosen your proud persona :P. In this argument I tend to find myself siding with Rick. Considering his general reputation in this forum am I missing something or do I need help? ;-) -- I'm free -- and freedom tastes of reality. -- The Who -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
Also remember when entering long lines of text that strings concatenate within parenthesis. So, (a, b, c d, e, f g, h, i) Is the same as (a, b, cd, e, fg, h, i) There was a recent discussion about this (under implicit string concatenation). It seems this is a part of the python language specification that was simply undefined. (A rule probably should be added to the lexer to make this explicit.) -- MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22 June 2013 18:28, Alister alister.w...@ntlworld.com wrote:
On Sat, 22 Jun 2013 17:11:00 +0100, Joshua Landau wrote:
On 22 June 2013 16:55, Rick Johnson rantingrickjohn...@gmail.com
wrote:
On Saturday, June 22, 2013 10:40:24 AM UTC-5, Joshua Landau wrote:
Plus, your use of the format syntax is incorrect.
Wut?
Well what i mean exactly is not that it's illegal, i just find the use
of the getattr sugar, from WITHIN the format string, to be
excessively noisy.
Sure...
So in other words you realised you were wrong but you're too scared to
admit it. Eh? That's it, isn't it! You just don't want to loosen your
proud persona :P.
In this argument I tend to find myself siding with Rick.
Considering his general reputation in this forum am I missing something
or do I need help? ;-)
I wasn't mocking the preference against it, but rather that that was
completely not what he said originally. One cannot let slip when the
mighty Rick misses his mark.
That said, yes, it is quite a noisy construct. I still prefer it to:
message = Item wrote to MongoDB database {}/{}
message = message.format(
settings['MONGODB_DB'],
settings['MONGODB_COLLECTION']
)
log.msg(message, level=log.DEBUG, spider=spider)
Because this feels undescriptive - the first and second lines feel
detached. Instead of Rick's hilarious unpacking, you could always do:
message = Item wrote to MongoDB database {database}/{collection}
message = message.format(
database=settings['MONGODB_DB'],
collection=settings['MONGODB_COLLECTION']
)
log.msg(message, level=log.DEBUG, spider=spider)
Which is probably as good, if longer. You'll see the real problem is
that MONDODB_DB and MONGODB_COLLECTION are awful names; would you
really have so detested
message = Item wrote to MongoDB database
message +=
{settings[database]}/{settings[collection]}.format(settings=settings)
log.msg(message, level=log.DEBUG, spider=spider)
or even, now,
message = Item wrote to MongoDB database
{settings[database]}/{settings[collection]}
message = message.format(settings=settings)
log.msg(message, level=log.DEBUG, spider=spider)
?
I think those options are quite nice, á mon avis. I could even write a
wrapper (oh noes!):
# Shortened for EMail
class SettingsWrapper:
def uglify_key(self, key): return key if key.startswith(MONGODB)
else MONGODB_ + key.upper()
def __init__(self, settingsdict): self.wrapped = settingsdict
def __len__(self): return self.wrapped.__len__()
def __iter__(self): return self.wrapped.__iter__()
def __getitem__(self, key): return self.wrapped[self.uglify_key(key)]
def __contains__(self, key): return self.uglify_key(key) in self.wrapped
def __setitem__(self, key, value):
self.wrapped[self.uglify_key(key)] = value
def __delitem__(self, key, value): del self.wrapped[self.uglify_key(key)]
settings = SettingsWrapper(settings)
message = Item wrote to MongoDB database {settings[db]}/{settings[collection]}
message = message.format(settings=settings)
log.msg(message, level=log.DEBUG, spider=spider)
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
In article camjelr9iq2yg_yf0csd2a9fk5upsgk42wzenn9r8ee2-rwk...@mail.gmail.com, Mark Janssen dreamingforw...@gmail.com wrote: Also remember when entering long lines of text that strings concatenate within parenthesis. So, (a, b, c d, e, f g, h, i) Is the same as (a, b, cd, e, fg, h, i) There was a recent discussion about this (under implicit string concatenation). It seems this is a part of the python language specification that was simply undefined. (A rule probably should be added to the lexer to make this explicit.) This behavior is explicitly defined in the Python Language Reference: http://docs.python.org/3/reference/lexical_analysis.html#string-literal-c oncatenation -- Ned Deily, n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
_fmtstr = Item wrote to MongoDB database {0}, {1}
msg = _fmtstr.format(_arg1, _arg2)
As a general rule, I don't like separating format strings and their
arguments. That's one of the more annoying costs of i18n. Keep them in
a single expression if you possibly can.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 06/22/2013 07:12 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
_fmtstr = Item wrote to MongoDB database {0}, {1}
msg = _fmtstr.format(_arg1, _arg2)
As a general rule, I don't like separating format strings and their
arguments. That's one of the more annoying costs of i18n. Keep them in
a single expression if you possibly can.
On the contrary, i18n should be done with config files. The format
string is the key to the actual string which is located in the
file/dict. Otherwise you're shipping separate source files for each
language -- blecch.
The program that's intended to be internationalized is written using
programmereze strings. That's a strange inhuman language that's only
approximately comprehensible by the developer and close associates.
Then that gets translated into a bunch of language-specific config
files, with English probably being one of them.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 9:28 AM, Dave Angel da...@davea.name wrote:
On 06/22/2013 07:12 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
_fmtstr = Item wrote to MongoDB database {0}, {1}
msg = _fmtstr.format(_arg1, _arg2)
As a general rule, I don't like separating format strings and their
arguments. That's one of the more annoying costs of i18n. Keep them in
a single expression if you possibly can.
On the contrary, i18n should be done with config files. The format string
is the key to the actual string which is located in the file/dict.
Otherwise you're shipping separate source files for each language -- blecch.
The simplest way to translate is to localize the format string; that's
the point of .format()'s named argument system (since it lets you
localize in a way that reorders the placeholders). What that does is
it puts the format string away in a config file, while the replaceable
parts are here in the source. That's why I say that's a cost of i18n -
it's a penalty that has to be paid in order to move text strings away.
The program that's intended to be internationalized is written using
programmereze strings. That's a strange inhuman language that's only
approximately comprehensible by the developer and close associates. Then
that gets translated into a bunch of language-specific config files, with
English probably being one of them.
Heh. That's one way of looking at it... I don't really know what
language we speak; at what point is it deemed a separate dialect, and
at what point a unique language? Hmmm.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 06/22/2013 07:37 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 9:28 AM, Dave Angel da...@davea.name wrote:
On 06/22/2013 07:12 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
_fmtstr = Item wrote to MongoDB database {0}, {1}
msg = _fmtstr.format(_arg1, _arg2)
As a general rule, I don't like separating format strings and their
arguments. That's one of the more annoying costs of i18n. Keep them in
a single expression if you possibly can.
On the contrary, i18n should be done with config files. The format string
**as specified in the physical program**
is the key to the actual string which is located in the file/dict.
Otherwise you're shipping separate source files for each language -- blecch.
What I was trying to say is that the programmereze format string in the
code is replaced at runtime by the French format string in the config file.
The simplest way to translate is to localize the format string; that's
the point of .format()'s named argument system (since it lets you
localize in a way that reorders the placeholders). What that does is
it puts the format string away in a config file, while the replaceable
parts are here in the source. That's why I say that's a cost of i18n -
it's a penalty that has to be paid in order to move text strings away.
Certainly the reorderability of the format string is significant. Not
only can it be reordered, but more than one instance of some of the
values is permissible if needed. (What's missing is a decent handling
of such things as singular/plural, where you want a different version
per country of one (or a few) words from the format string, based on
whether a value is exactly 1.)
But the language is missing the indirection I described. So you have to
use a (function or whatever) wrapper to look up the actual format string
in the config file. My point is by making that file equivalent to a
dict, you get to have an executable program in programmereze before
creating any config files, but still able to handle any real language
with one config file per language.
This is much preferable to the usual numeric lookup, where somebody
specifies the 17th format string to be used at this place in the code.
Even when you use C++ names, they're still only a crude approximation to
the real purpose of the string.
The program that's intended to be internationalized is written using
programmereze strings. That's a strange inhuman language that's only
approximately comprehensible by the developer and close associates. Then
that gets translated into a bunch of language-specific config files, with
English probably being one of them.
Heh. That's one way of looking at it... I don't really know what
language we speak; at what point is it deemed a separate dialect, and
at what point a unique language? Hmmm.
ChrisA
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 9:56 AM, Dave Angel da...@davea.name wrote: On 06/22/2013 07:37 PM, Chris Angelico wrote: On the contrary, i18n should be done with config files. The format string **as specified in the physical program** is the key to the actual string which is located in the file/dict. Otherwise you're shipping separate source files for each language -- blecch. What I was trying to say is that the programmereze format string in the code is replaced at runtime by the French format string in the config file. But the language is missing the indirection I described. So you have to use a (function or whatever) wrapper to look up the actual format string in the config file. My point is by making that file equivalent to a dict, you get to have an executable program in programmereze before creating any config files, but still able to handle any real language with one config file per language. This is much preferable to the usual numeric lookup, where somebody specifies the 17th format string to be used at this place in the code. Even when you use C++ names, they're still only a crude approximation to the real purpose of the string. What you're saying is that there are ways to ameliorate the problem with i18n. What that means is that you broadly agree with my main point, which is that the format string should be kept as close as possible to the arguments. When you're NOT translating to multiple languages, the string-literal is the most appropriate way to lay this out, imo. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 06/22/2013 08:27 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 9:56 AM, Dave Angel da...@davea.name wrote:
On 06/22/2013 07:37 PM, Chris Angelico wrote:
On the contrary, i18n should be done with config files. The format
string
**as specified in the physical program**
is the key to the actual string which is located in the file/dict.
Otherwise you're shipping separate source files for each language --
blecch.
What I was trying to say is that the programmereze format string in the code
is replaced at runtime by the French format string in the config file.
But the language is missing the indirection I described. So you have to use
a (function or whatever) wrapper to look up the actual format string in the
config file. My point is by making that file equivalent to a dict, you get
to have an executable program in programmereze before creating any config
files, but still able to handle any real language with one config file per
language.
This is much preferable to the usual numeric lookup, where somebody
specifies the 17th format string to be used at this place in the code. Even
when you use C++ names, they're still only a crude approximation to the real
purpose of the string.
What you're saying is that there are ways to ameliorate the problem
with i18n. What that means is that you broadly agree with my main
point, which is that the format string should be kept as close as
possible to the arguments. When you're NOT translating to multiple
languages, the string-literal is the most appropriate way to lay this
out, imo.
Absolutely (very broadly). And when I am, it's still a string literal,
just not the one the customer will see. It still should be next to the
arguments of the format. I'd be replacing something like:
line = Customer's name: {%0}, address {%1}.format(args)
with
line = i18n(current_language, Cussom's name: {%0}, addr {%1}, thename,
theaddr)
And the English config file would look like (not counting any escaping
or whatevers):
#SIG - American English, headerline
Cussom's name: {%0}, addr {%1}
Customer's name: {%0}, addr {%1}
The key has the misspelling's and approximations, while the value has
the actual string to be used as the object of format.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Saturday, June 22, 2013 6:12:50 PM UTC-5, Chris Angelico wrote: As a general rule, I don't like separating format strings and their arguments. Huh? Format strings don't take arguments because Python's built-in string type is not callable. py callable() False Format string is just a generic term we apply to normal string literals that include special markers (called placeholders) that define the final location and specify the specifics of an Object(s) translation into string type. -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 23/06/2013 00:56, Dave Angel wrote:
On 06/22/2013 07:37 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 9:28 AM, Dave Angel da...@davea.name wrote:
On 06/22/2013 07:12 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
_fmtstr = Item wrote to MongoDB database {0}, {1}
msg = _fmtstr.format(_arg1, _arg2)
As a general rule, I don't like separating format strings and their
arguments. That's one of the more annoying costs of i18n. Keep them in
a single expression if you possibly can.
On the contrary, i18n should be done with config files. The format string
**as specified in the physical program**
is the key to the actual string which is located in the file/dict.
Otherwise you're shipping separate source files for each language -- blecch.
What I was trying to say is that the programmereze format string in the
code is replaced at runtime by the French format string in the config file.
The simplest way to translate is to localize the format string; that's
the point of .format()'s named argument system (since it lets you
localize in a way that reorders the placeholders). What that does is
it puts the format string away in a config file, while the replaceable
parts are here in the source. That's why I say that's a cost of i18n -
it's a penalty that has to be paid in order to move text strings away.
Certainly the reorderability of the format string is significant. Not
only can it be reordered, but more than one instance of some of the
values is permissible if needed. (What's missing is a decent handling
of such things as singular/plural, where you want a different version
per country of one (or a few) words from the format string, based on
whether a value is exactly 1.)
[snip]
One vs not-one isn't good enough. Some languages use the singular with
any numbers ending in '1'. Some languages have singular, dual, and
plural. Etc. It's surprising how inventive people can be! :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 06/22/2013 09:20 PM, MRAB wrote: On 23/06/2013 00:56, Dave Angel wrote: SNIP Certainly the reorderability of the format string is significant. Not only can it be reordered, but more than one instance of some of the values is permissible if needed. (What's missing is a decent handling of such things as singular/plural, where you want a different version per country of one (or a few) words from the format string, based on whether a value is exactly 1.) [snip] One vs not-one isn't good enough. Some languages use the singular with any numbers ending in '1'. Some languages have singular, dual, and plural. Etc. It's surprising how inventive people can be! :-) And there are plenty more where that came from. Thanks for the reminder. I guess instead of a format, we need a DWIM. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 10:48 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: On Saturday, June 22, 2013 6:12:50 PM UTC-5, Chris Angelico wrote: As a general rule, I don't like separating format strings and their arguments. Huh? Format strings don't take arguments because Python's built-in string type is not callable. py callable() False Format string is just a generic term we apply to normal string literals that include special markers (called placeholders) that define the final location and specify the specifics of an Object(s) translation into string type. And parameterized SQL queries don't take parameters either, for the same reason. They're extra parameters given to the call that uses it. So? The format string still takes parameters. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, 23 Jun 2013 02:20:56 +0100, MRAB wrote: One vs not-one isn't good enough. Some languages use the singular with any numbers ending in '1'. Some languages have singular, dual, and plural. Etc. It's surprising how inventive people can be! :-) This is a good time to link to these interesting articles: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
In article 51c66455$0$2$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about- time Number 2 on the list is Months have either 30 or 31 days, which was obviously believed by whoever made this sign: http://tinyurl.com/mgv39on -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sat, 22 Jun 2013 23:12:49 -0400, Roy Smith wrote: In article 51c66455$0$2$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: http://infiniteundo.com/post/25326999628/falsehoods-programmers- believe-about- time Number 2 on the list is Months have either 30 or 31 days, which was obviously believed by whoever made this sign: http://tinyurl.com/mgv39on Can you link directly to the image? Facebook and my browser don't get on. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 1:22 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sat, 22 Jun 2013 23:12:49 -0400, Roy Smith wrote: In article 51c66455$0$2$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: http://infiniteundo.com/post/25326999628/falsehoods-programmers- believe-about- time Number 2 on the list is Months have either 30 or 31 days, which was obviously believed by whoever made this sign: http://tinyurl.com/mgv39on Can you link directly to the image? Facebook and my browser don't get on. https://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-frc1/s720x720/429211_490456177653518_2055059398_n.jpg but that still might not work. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 12:58 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sun, 23 Jun 2013 02:20:56 +0100, MRAB wrote: One vs not-one isn't good enough. Some languages use the singular with any numbers ending in '1'. Some languages have singular, dual, and plural. Etc. It's surprising how inventive people can be! :-) This is a good time to link to these interesting articles: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time Thanks for that! I know the one about names, but have just had a good-fun read of the second one. My sister and I are currently playing Dungeons and Dragons together, and the trek through the bee-infested forest took second place to laughing about time. :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
n00b question on spacing
Hi, I have a question about breaking up really long lines of code in Python. I have the following line of code: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Given the fact that it goes off very far to the right on my screen is not terribly pleasing to my eyes (and can be rude for other developers). I was thinking of splitting it up like so: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Is this ok? Are there any rules in Python when it comes to breaking up long lines of code? -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
In mailman.3669.1371849457.3114.python-l...@python.org Yves S. Garret yoursurrogate...@gmail.com writes: Hi, I have a question about breaking up really long lines of code in Python. I have the following line of code: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Given the fact that it goes off very far to the right on my screen is not terribly pleasing to my eyes (and can be rude for other developers). I was thinking of splitting it up like so: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Is this ok? Are there any rules in Python when it comes to breaking up long lines of code? There are guidelines in the PEP8 document: http://www.python.org/dev/peps/pep-0008/ Check out the section entitled 'Code lay-out'. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
- Original Message - From: Yves S. Garret yoursurrogate...@gmail.com To: python-list@python.org Sent: Friday, June 21, 2013 5:17:28 PM Subject: n00b question on spacing Hi, I have a question about breaking up really long lines of code in Python. I have the following line of code: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Given the fact that it goes off very far to the right on my screen is not terribly pleasing to my eyes (and can be rude for other developers). I was thinking of splitting it up like so: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Is this ok? Are there any rules in Python when it comes to breaking up long lines of code? -- http://mail.python.org/mailman/listinfo/python-list Hi Yves: PEP8 is your definitive guide for style questions: http://www.python.org/dev/peps/pep-0008/ and this is an interesting set of notes: http://stackoverflow.com/questions/5931297/how-would-you-properly-break-this-line-to-match-pep8-rules Basic rule is to break within parenthesis -- after that it becomes a matter of personal taste/style. In your specific example, I would do something like: log.msg( Item wrote to MongoDB database %s %s % ( settings['MONGODB_DB'], settings['MONGODB_COLLECTION]), level=log.DEBUG, spider=spider) Though you might want to: a) start your string right after the log.msg( b) put more than one settings on the same line c) put the last two parameters on the same line. I find that once I start breaking up lines for length, that I prefer to break up everything. Also remember when entering long lines of text that strings concatenate within parenthesis. So, (a, b, c d, e, f g, h, i) Is the same as (a, b, cd, e, fg, h, i) --Ray -- Ray Cote, President Appropriate Solutions, Inc. We Build Software 603.924.6079 -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Fri, Jun 21, 2013 at 5:48 PM, Ray Cote rgac...@appropriatesolutions.comwrote: -- *From: *Yves S. Garret yoursurrogate...@gmail.com *To: *python-list@python.org *Sent: *Friday, June 21, 2013 5:17:28 PM *Subject: *n00b question on spacing Hi, I have a question about breaking up really long lines of code in Python. I have the following line of code: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Given the fact that it goes off very far to the right on my screen is not terribly pleasing to my eyes (and can be rude for other developers). I was thinking of splitting it up like so: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Is this ok? Are there any rules in Python when it comes to breaking up long lines of code? -- http://mail.python.org/mailman/listinfo/python-list Hi Yves: PEP8 is your definitive guide for style questions: http://www.python.org/dev/peps/pep-0008/ and this is an interesting set of notes: http://stackoverflow.com/questions/5931297/how-would-you-properly-break-this-line-to-match-pep8-rules Basic rule is to break within parenthesis -- after that it becomes a matter of personal taste/style. In your specific example, I would do something like: log.msg( Item wrote to MongoDB database %s %s % ( settings['MONGODB_DB'], settings['MONGODB_COLLECTION]), level=log.DEBUG, spider=spider) Though you might want to: a) start your string right after the log.msg( b) put more than one settings on the same line c) put the last two parameters on the same line. I find that once I start breaking up lines for length, that I prefer to break up everything. Also remember when entering long lines of text that strings concatenate within parenthesis. So, (a, b, c d, e, f g, h, i) Is the same as (a, b, cd, e, fg, h, i) --Ray -- Ray Cote, President Appropriate Solutions, Inc. We Build Software 603.924.6079 Thanks for your reply Ray. My concern was that if I were to break with something like this: log.msg(Item written to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level = log.DEBUG, spider = spider) I would get some undefined behaviour (the % is a little before the log.msg). I'll read the links that you provided in order to learn more. -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 06/21/2013 02:17 PM, Yves S. Garret wrote: Hi, I have a question about breaking up really long lines of code in Python. I have the following line of code: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Given the fact that it goes off very far to the right on my screen is not terribly pleasing to my eyes (and can be rude for other developers). I was thinking of splitting it up like so: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Is this ok? Are there any rules in Python when it comes to breaking up long lines of code? This is how I'd do it: (And it's *FAR* clearer -- You win no points for clarity by having it all in one statement.) fmt = Item wrote to MongoDB database %s/%s msg = fmt % (settings['MONGODB_DB'], settings['MONGODB_COLLECTION']) log.msg(msg, level=log.DEBUG, spider=spider) Gary Herron -- Dr. Gary Herron Department of Computer Science DigiPen Institute of Technology (425) 895-4418 -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 6/21/2013 5:17 PM, Yves S. Garret wrote: Hi, I have a question about breaking up really long lines of code in Python. I have the following line of code: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Given the fact that it goes off very far to the right on my screen is not terribly pleasing to my eyes (and can be rude for other developers). I was thinking of splitting it up like so: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Is this ok? Are there any rules in Python when it comes to breaking up long lines of code? For function calls, PEP8 suggests either an extra indent or line up as follows. log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) The point is to not look like a normal indent to clue reader that these are continuation lines and not new statements. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Fri, 21 Jun 2013 17:48:54 -0400, Ray Cote wrote: Also remember when entering long lines of text that strings concatenate within parenthesis. So, (a, b, c d, e, f g, h, i) Is the same as (a, b, cd, e, fg, h, i) Technically, you don't need the parentheses. You can also use backslash to continue the lines: s = a, b, c, \ d, e, f, \ g, h, i assert s == a, b, c, d, e, f, g, h, i Or, if the strings are small enough, fit them on one line: s = a b c This *implicit concatenation* only works with string literals, not variables, but it works with any sort of quoting style: s = -'- '--' r\a\b assert s == -'--\-\\a\\b Like most such features, a little goes a long way. Don't over do it, it is quite possible to end up with an unreadable mess if you overuse it. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
Yves S. Garret wrote: Hi, I have a question about breaking up really long lines of code in Python. I have the following line of code: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Given the fact that it goes off very far to the right on my screen is not terribly pleasing to my eyes (and can be rude for other developers). I was thinking of splitting it up like so: log.msg(Item wrote to MongoDB database %s/%s %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider) Is this ok? Are there any rules in Python when it comes to breaking up long lines of code? You can move the goal posts and change your API (to one similar to the logging module in the standard library, for example): log.debug( Wrote item to MongoDB database %s/%s, settings[MONGODB_DB], settings[MONGODB_COLLECTIONS], spider=spider) -- http://mail.python.org/mailman/listinfo/python-list
