Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #48922 > unrolled thread

Re: n00b question on spacing

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: n00b question on spacing Joshua Landau <joshua.landau.ws@gmail.com> - 2013-06-22 14:36 +0100
    Re: n00b question on spacing Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-22 08:24 -0700
      Re: n00b question on spacing Joshua Landau <joshua.landau.ws@gmail.com> - 2013-06-22 16:40 +0100
        Re: n00b question on spacing Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-22 08:55 -0700
          Re: n00b question on spacing Joshua Landau <joshua.landau.ws@gmail.com> - 2013-06-22 17:11 +0100
      Re: n00b question on spacing Chris Angelico <rosuav@gmail.com> - 2013-06-23 09:12 +1000
        Re: n00b question on spacing Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-22 17:48 -0700
          Re: n00b question on spacing Chris Angelico <rosuav@gmail.com> - 2013-06-23 12:26 +1000
      Re: n00b question on spacing Dave Angel <davea@davea.name> - 2013-06-22 19:28 -0400
      Re: n00b question on spacing Chris Angelico <rosuav@gmail.com> - 2013-06-23 09:37 +1000
      Re: n00b question on spacing Dave Angel <davea@davea.name> - 2013-06-22 19:56 -0400
      Re: n00b question on spacing Chris Angelico <rosuav@gmail.com> - 2013-06-23 10:27 +1000
      Re: n00b question on spacing Dave Angel <davea@davea.name> - 2013-06-22 20:46 -0400
      Re: n00b question on spacing MRAB <python@mrabarnett.plus.com> - 2013-06-23 02:20 +0100
        Re: n00b question on spacing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-23 02:58 +0000
          Re: n00b question on spacing Roy Smith <roy@panix.com> - 2013-06-22 23:12 -0400
            Re: n00b question on spacing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-23 03:22 +0000
              Re: n00b question on spacing Chris Angelico <rosuav@gmail.com> - 2013-06-23 13:36 +1000
              Re: n00b question on spacing Roy Smith <roy@panix.com> - 2013-06-23 09:43 -0400
          Re: n00b question on spacing Chris Angelico <rosuav@gmail.com> - 2013-06-23 14:09 +1000
      Re: n00b question on spacing Dave Angel <davea@davea.name> - 2013-06-22 21:35 -0400
      Re: n00b question on spacing Terry Reedy <tjreedy@udel.edu> - 2013-06-23 11:40 -0400

Page 1 of 2  [1] 2  Next page →

#48922 — Re: n00b question on spacing

On 21 June 2013 23:26, Gary Herron <gherron@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)

[toc] | [next] | [standalone]

#48927

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.

[toc] | [prev] | [next] | [standalone]

#48929

On 22 June 2013 16:24, Rick Johnson <rantingrickjohnson@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.

[toc] | [prev] | [next] | [standalone]

#48931

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".

[toc] | [prev] | [next] | [standalone]

#48933

On 22 June 2013 16:55, Rick Johnson <rantingrickjohnson@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'.

[toc] | [prev] | [next] | [standalone]

#48952

On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
<rantingrickjohnson@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

[toc] | [prev] | [next] | [standalone]

#48957

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.

[toc] | [prev] | [next] | [standalone]

#48965

On Sun, Jun 23, 2013 at 10:48 AM, Rick Johnson
<rantingrickjohnson@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

[toc] | [prev] | [next] | [standalone]

#48953

On 06/22/2013 07:12 PM, Chris Angelico wrote:
> On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
> <rantingrickjohnson@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

[toc] | [prev] | [next] | [standalone]

#48954

On Sun, Jun 23, 2013 at 9:28 AM, Dave Angel <davea@davea.name> wrote:
> On 06/22/2013 07:12 PM, Chris Angelico wrote:
>>
>> On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
>> <rantingrickjohnson@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

[toc] | [prev] | [next] | [standalone]

#48955

On 06/22/2013 07:37 PM, Chris Angelico wrote:
> On Sun, Jun 23, 2013 at 9:28 AM, Dave Angel <davea@davea.name> wrote:
>> On 06/22/2013 07:12 PM, Chris Angelico wrote:
>>>
>>> On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
>>> <rantingrickjohnson@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

[toc] | [prev] | [next] | [standalone]

#48956

On Sun, Jun 23, 2013 at 9:56 AM, Dave Angel <davea@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

[toc] | [prev] | [next] | [standalone]

#48960

On 06/22/2013 08:27 PM, Chris Angelico wrote:
> On Sun, Jun 23, 2013 at 9:56 AM, Dave Angel <davea@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

[toc] | [prev] | [next] | [standalone]

#48961

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 <davea@davea.name> wrote:
>>> On 06/22/2013 07:12 PM, Chris Angelico wrote:
>>>>
>>>> On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
>>>> <rantingrickjohnson@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! :-)

[toc] | [prev] | [next] | [standalone]

#48967

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

[toc] | [prev] | [next] | [standalone]

#48971

In article <51c66455$0$29999$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#48973

On Sat, 22 Jun 2013 23:12:49 -0400, Roy Smith wrote:

> In article <51c66455$0$29999$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#48974

On Sun, Jun 23, 2013 at 1:22 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sat, 22 Jun 2013 23:12:49 -0400, Roy Smith wrote:
>
>> In article <51c66455$0$29999$c3e8da3$5496439d@news.astraweb.com>,
>>  Steven D'Aprano <steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#48981

In article <51c66a03$0$29999$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#48975

On Sun, Jun 23, 2013 at 12:58 PM, Steven D'Aprano
<steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web