Hello!
I think
for i in range(10):
is more readable than a while loop with explicit incrementation of i.
However, range(10) in the command interpreter obviously returns a list. Is
this list optimized away in the code above, or is it actually constructed
internally? (With, say, CPython in
John Coleman <[EMAIL PROTECTED]> skrev:
> John Salerno wrote:
>> John Coleman wrote:
>>> John Coleman wrote:
Greetings,
I am currently trying to learn Python through the excellent
"Learning Python" book.
>>
>> me too!
>>
>>> It isn't just #hash, but also things like #dict, #int,
Scott David Daniels wrote:
> Blackbird wrote:
>> I think
>>
>> for i in range(10):
>>
>>
>> is more readable than a while loop with explicit incrementation of i.
>
>> However, range(10) in the command interpreter obviously returns a
>> li
ted a "key"
>> argument the way that the sorting functions do.
>
> Using a variant of DSU (Decorate-Sort-Undecorate) with max for S,
> rather than sort:
>
> print max((len(words), words) for words in d.itervalues())
> or:
> size, words = max((le
[EMAIL PROTECTED] wrote:
> Hi Duncan,
>
> thanks for the reply. I figured that this was a technical problem
> associated with the parser.
>
> This one is going on my Python gotchas list. It is really silly from
> an end user perspective to have \ not special in raw strings _except_
> if it is the
Slightly OT, but here is a crazy little program that shows the power of
using raw strings:
s=r'print "s=r\'%s\'\n%s"%(s,s)'
print "s=r\'%s\'\n%s"%(s,s)
When run, this program will print an exact copy of itself.
Blackbird
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh wrote:
> "Blackbird" <[EMAIL PROTECTED]> wrote:
>
>> Slightly OT, but here is a crazy little program that shows the power
>> of using raw strings:
>>
>> s=r'print "s=r\'%s\'\n%s"%(s,s)'
>> print &qu
I'm trying to get a complete grip on %r. Is it true that the two programs
a = '*anything the parser accepts*'
print '%r' % a
vs.
a = r'*anything the parser accepts*'
print "'%s'" % a
always produce the same output, where *anything the parser accepts* can be
replaced with, well, anything the pa
Duncan Booth wrote:
> Blackbird wrote:
>
>> [...]
>
>>>> a = 'I don\'t think so'
>>>> print '%r' % a
> "I don't think so"
>>>> a = r'I don\'t think so'
>>>> print "'
Peter Hansen wrote:
> Blackbird wrote:
>> I'm trying to get a complete grip on %r. Is it true that the two
>> programs
>>
>> a = '*anything the parser accepts*'
>> print '%r' % a
>>
>> vs.
>>
>> a = r'*anythi
John Salerno wrote:
> KraftDiner wrote:
>
>> [[1][2][3], [4][5][6], [7][8][9]]
>
> I'm confused. Is that a valid list?
No. I'm assuming he meant [[1, 2, 3], [4, 5, 6], [7, 8, 9]].
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh wrote:
> "Blackbird" <[EMAIL PROTECTED]> wrote:
>
>>>> [...]
>>>
>>>>>> a = 'I don\'t think so'
>>>>>> print '%r' % a
>>> "I don't think so"
>>>>
with the other
primitive types, but anything that repr to something like '' will crash, since it's not a valid Python expression.
Is the interpreter in fact using repr(), or parts of it, to generate output
when you type an expression at the command prompt? The results sure look
simil
Blackbird <[EMAIL PROTECTED]> skrev:
>>
> Is the interpreter in fact using repr(), or parts of it, to generate
> output when you type an expression at the command prompt? The
> results sure look similar.
Let me clarify this: The interpreter uses eval. No doubt about t
Blackbird wrote:
> Blackbird <[EMAIL PROTECTED]> skrev:
>
>>>
>> Is the interpreter in fact using repr(), or parts of it, to generate
>> output when you type an expression at the command prompt? The
>> results sure look similar.
>
> Let me clarify this
15 matches
Mail list logo
