How much does Python optimize?
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 one of the recent versions.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Does '#hash' mean anything in IDLE?
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, #len at the >>> start of a comment line which defeats IDLE's colorization algorithm. >>> Interestingly, things like #while or #for behave as expected so it >>> seems to be built-ins rather than keywords which are the problem. To >>> answer my own question - this is pretty clearly a (harmless) bug. >> >> also notice that putting a space after # stops the problem > > How do you like Python so far? I like dictionary objects the best so > far. I'm coming to Python from VBScript, so I already knew the value > of such things, but in Python they are better supported. > > Here is the program I was talking about, which *really* shows the > power of dictionaries: > > * > > #Python program to discover word with most 1-word anagrams >[...] Nice! I think this simpler version of letter_hash should work too: def letter_hash(word): w = [c for c in word] w.sort() return "".join(w) -- http://mail.python.org/mailman/listinfo/python-list
Re: How much does Python optimize?
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 >> list. Is this list optimized away in the code above, or is it >> actually constructed internally? (With, say, CPython in one of the >> recent versions.) > > Yup, and if you are tuning a piece of code to the wall, you should > time it and possibly care. Likely you are not, and the timing makes > no difference. Someday, range will behave like xrange automagically, > and in the meantime your code will read just fine. If you are in > trouble now, your code reads much more like: > for i in range(10): > ... Thanks. Yes, this will be a problem for iterations in the order of 10**5 and upwards only, and those are rare in most applications. So my question was more motivated by a general curiosity about the inner workings of the Python interpreter, and I sort of understand why advanced optimization on an instruction set like bytecode would be difficult. And in the mean time, I found this insightful piece: http://www.python.org/doc/essays/list2str.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Does '#hash' mean anything in IDLE?
Scott David Daniels wrote:
> Paul Rubin wrote:
>> Scott David Daniels <[EMAIL PROTECTED]> writes:
>>> And, for 2.4 or later:
>>>
>>> def letter_hash(word):
>>> return "".join(sorted(word))
>>>
>>> sorted takes an iterable, and strings are iterables.
>>
>> I don't think the "hash" is really a hash in the normal sense--in
>> particular, it has to be collision-free. So I'd just call it
>> "sorted_word". Here's my version of the program:
>>
>>
>> from sets import Set
> "Cute" form for this:
>
> try:
> set
> except NameError:
> from sets import Set as set
>
> Then you get native sets for 2.4, and sets.Set for 2.3
>
>> d = {}
>> for line in file('/usr/share/dict/words'):
>> word = line.strip().lower()
>> d.setdefault(sorted_word(word), Set()).add(word)
>>
>> print sorted(d.iteritems(), key=lambda (x,y): -len(y))[:1]
> ...
>
>> Note that I sorted the dictionary items in order to get the max
>> element. That is sort of bogus because it's an O(N log N) operation
>> while finding the maximum should only need O(N). But it leads to
>> a convenient spelling. It would be nice if "max" accepted 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((len(words), words) for words in
> d.itervalues()) print size, sorted(words)
>
>
> --Scott David Daniels
> [EMAIL PROTECTED]
Your code is Pylegant. Jee, I just learned of Python two weeks ago, and my
copy of the cookbook arrived yesterday. And now I'm coining new words.
What is this language doing to me?
Blackbird
--
http://mail.python.org/mailman/listinfo/python-list
Re: raw strings and \
[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 last character. But at the parsing stage, it *is* somewhat special, even if it is not the last charater. E.g, a = r'check \' this' print a The second quote is not regarded as ending the string literal. -- http://mail.python.org/mailman/listinfo/python-list
Re: raw strings and \
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
Re: raw strings and \
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 "s=r\'%s\'\n%s"%(s,s) >> >> When run, this program will print an exact copy of itself. > > I'm not sure what the raw strings brings to the table, though; it's > not like you need them to write a "self-replicating" python program: > > http://miscoranda.com/37 Great link! I wasn't aware that this was called a Quine. This one is great: _='_=%r;print _%%_';print _%_ When I hacked down the two lines, I didnt see that assigning the variable to the beginning of the program, instead of the end, essentially gets rid of literals in the actual print statement. And now I also learned about %r. -- http://mail.python.org/mailman/listinfo/python-list
%r
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 parser accepts? -- http://mail.python.org/mailman/listinfo/python-list
Re: %r
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 "'%s'" % a > 'I don\'t think so' Excellent counterexample. Can something like this happen for other things than quotes? -- http://mail.python.org/mailman/listinfo/python-list
Re: %r
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'*anything the parser accepts*'
>> print "'%s'" % a
>>
>> always produce the same output, where *anything the parser accepts*
>> can be replaced with, well, anything the parser accepts?
>
> "Always produce the same output?" Well, hardly, as even a token test
> proves:
>
> >>> a = 'testing\'this'
> >>> print '%r' % a
> "testing'this"
> >>> b = r'testing\'this'
> >>> print "'%s'" % b
> 'testing\'this'
>
>
> Do you realize that '%r' % a just outputs whatever repr(a) returns?
> And that '%s' % a just outputs whatever str(a) returns?
>
> -Peter
I got it now (retrospectively, this turned out be an exercise in 'posting
before thinking'). Since many different looking string literals will
produce the same string, obviously my question must be answered in the
negative. It's of course
a = 'something'
b = ('%r'%a)
eval(b) == a
that in general should return True. I hope. But I'm sure there are
counterexamples to that, too.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help initializing a list or tuple.
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
Re: %r
Fredrik Lundh wrote: > "Blackbird" <[EMAIL PROTECTED]> wrote: > >>>> [...] >>> >>>>>> a = 'I don\'t think so' >>>>>> print '%r' % a >>> "I don't think so" >>>>>> a = r'I don\'t think so' >>>>>> print "'%s'" % a >>> 'I don\'t think so' >> >> Excellent counterexample. Can something like this happen for other >> things than quotes? > >>>> a = '\377' >>>> print '%r' % a > '\xff' >>>> a = r'\377' >>>> print "'%s'" % a > '\377' > > I still recommend looking up %s and %r and str() and repr() in the > documentation. it's not hard to understand what they do, and that > approach works a bit better than cargo cult programming. By "cargo cult programming", do you mean actually *running* the code? N, no, no. I *write* code. I don't *run* code any longer. A long life has thought me that the awakenings you are in for, by running code, are rude and only rude. Blackbird -- http://mail.python.org/mailman/listinfo/python-list
Re: %r
Peter Hansen wrote: > [...]> > On the other hand, if 'something' is actually some arbitrary object, > then it's definitely not always true, especially for anything not > built in to Python. > > -Peter Yes, I had strings in mind. And I guess it will work 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 similar. Blackbird -- http://mail.python.org/mailman/listinfo/python-list
Re: %r
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 that. But
>>> eval('f')
>>> repr(f)
''
So there is still a connection between eval and repr that I don't fully
understand, besides the fact that eval (among other things) is the inverse
of repr. Do they share some code, and if so, what part? Well, I guess I
could of course take a few weeks off and dive into the source... not sure my
wife would approve..
--
http://mail.python.org/mailman/listinfo/python-list
Re: %r
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: The interpreter uses eval. No doubt about
> that. But
>
>>>> eval('f')
>
>>>> repr(f)
> ''
>
> So there is still a connection between eval and repr that I don't
> fully understand, besides the fact that eval (among other things) is
> the inverse of repr. Do they share some code, and if so, what part?
> Well, I guess I could of course take a few weeks off and dive into
> the source... not sure my wife would approve..
Aarghh... the command line interpreter of course use both repr and eval.
In fact, when presented by a top level (unindented) expression,
and
print repr(eval(''))
the two lines produce the same output, so this last program *is* in fact the
interpreter. Now I'll get some sleep, and a life, and stop talking to
myself on usenet.
--
http://mail.python.org/mailman/listinfo/python-list
