Re: Accessing class variable at class creation time

[Dave Hansen]

On 23 Sep 2005 14:01:21 -0700, "Carlos" <[EMAIL PROTECTED]>
wrote:

>Hi!
>
>class A:
>  X = 2
>  def F():
>print A.X
>  F()
>
>The above fails because the name A is not
>yet at global scope when the reference A.X

Maybe I'm missing something.  Python 2.4.1#65 under Win32 Idle 1.1.1
gives me the following:

--begin included file---
>>> class A:
X = 2
def F():
print A.X
F()


2
---end included file---

But what good is F?  You can't call A.F() because methods need an
instance, and calling A.F(instance) or instance.F() throws a TypeError
(argument count) exception.

Regards,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: New Python chess module

[Dave Hansen]

On Sat, 01 Oct 2005 06:27:01 +1000, Tim Churches
<[EMAIL PROTECTED]> wrote:

>Will McGugan wrote:
>> There is a new version if anyone is interested...
>> 
>> http://www.willmcgugan.com/chess.py
>> 
>> It contains optimizations and bugfixes.
>> 
>> Can anyone suggest a name for this module? pyChess is already taken...
>
>Pyawn???

As a play on "pawn?"  that wasn't the way I first took it (ho-hum...)

How about pyTurk, after the first chess automaton?  It seems to be
available.

Regards,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Dave Hansen]

On Fri, 07 Oct 2005 14:24:42 -, Grant Edwards <[EMAIL PROTECTED]>
wrote:

>On 2005-10-07, Steve Holden <[EMAIL PROTECTED]> wrote:
[...]
>>
>> "Some village in Texas are missing their idiot"
>
>At least that one is consistent, though it sounds "wrong" to US
>ears.

The Germans have a word for it (sounds "wrong"): Sprachgefuhl,
literally a feeling for the language.

[...]
>
>Don't get me started on _that_ one.  I found it particularly
>horrifying that Jimmy Carter pronounced it "nucular" -- he had
>studied nuclear engineering at the naval acadamy, and should at
>least be able pronounce the word.

"I was talking to my daughter, Amy, last night..."

Regards,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Dave Hansen]

On Fri, 07 Oct 2005 21:44:29 +0100, Steve Holden <[EMAIL PROTECTED]>
wrote:

>Terry Hancock wrote:
>> On Friday 07 October 2005 03:01 am, Steve Holden wrote:
>> 
>>>OK, so how do you account for the execresence "That will give you a 
>>>savings of 20%", which usage is common in America?
>> 
>> 
>> In America, anyway, "savings" is a collective abstract noun 
>> (like "physics" or "mechanics"), there's no such
>> noun as "saving" (that's present participle of "to save"
>> only).  How did you expect that sentence to be rendered?
>> Why is it an "execresence"?
>> 
>Precisely because there *is* such a thing as a saving. If I buy a $100 
>gumball for $80 I have achieved a saving of 20%.

FWIW, my dictionary has a usage note: 

   /Savings/ (plural noun) is not preceded by the singular /a/, except
   loosely:"The price represents a savings (properly /saving/) of ten
   dollars."  In the foregoing, considered as an example in writing,
   /savings/ is unacceptable to 89 per cent the Usage Panel.

(Words enclosed in /slashes/ represent italics.)

The dictionary? "The American Heritage Dictionary of the English
Language, New College Edition."

Still sounds wrong to me, though.

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Dave Hansen]

On Fri, 7 Oct 2005 16:18:57 -0500, Terry Hancock
<[EMAIL PROTECTED]> wrote:

>On Friday 07 October 2005 01:31 pm, Dave Hansen wrote:

Actually, I didn't, though I did respond to it.  Please watch your
attributions.

Thanks,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: dictionaries/pointers

[Dave Hansen]

On 7 Oct 2005 14:23:49 -0700, "Rob Conner" <[EMAIL PROTECTED]> wrote:

>I dont know how to do this and can't think of a simple way to.
>
>All I want is a dictionary where two keys point to the same object.
>(to steal the ascii art from
>http://starship.python.net/crew/mwh/hacks/objectthink.html)
>I want sometihng like this:
>
>,--.   +---+
>| dict |-->|+-+| +---+
>`--'   || "a" |+>| 1 |
>   |+-+| +---+
>   |   |   ^
>   |+-+|   |
>   || "b" |+---'
>   |+-+|
>   +---+
>   |   |
>   |+-+| +---+
>   || "c" |+>| 2 |
>   |+-+| +---+
>   +---+
>
>Where if I change "a" or "b" to 3 the other one will change?
>Is this even possible? How would I do it?

A simple, ugly answer: Use a mutable object rather than a plain
integer.  Example:

>>> elt = [1]
>>> dict = {"a":elt, "b":elt, "c":[2]}
>>> print dict
{'a': [1], 'c': [2], 'b': [1]}
>>> dict["a"][0] = 3
>>> print dict
{'a': [3], 'c': [2], 'b': [3]}
>>> 

Regards,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Info] PEP 308 accepted - new conditional expressions

[Dave Hansen]

On Mon, 10 Oct 2005 16:42:34 -0500, Terry Hancock
<[EMAIL PROTECTED]> wrote:

>On Sunday 09 October 2005 07:50 am, phil hunt wrote:
>> On Fri, 7 Oct 2005 01:05:12 -0500, Terry Hancock <[EMAIL PROTECTED]> wrote:
>> >GvR's syntax has the advantage of making grammatical sense in English (i.e.
>> >reading it as written pretty much makes sense).
>> 
>> I know, let's re-write Python to make it more like COBOL! That's 
>> bound to be a winner!
>
>Whereas the "natural order" of "condition affirmative negative" is natural
>for what reason?  That it is so in C?

And Basic, and Fortran, and Lisp, and just about any programming
language you care to name, including python (if Condition: Affirmative
else: Negative).

Not to mention that the sequence is identical to execution order.
It's just plain goofy to have to scan to the middle of an expression
to find out what happens first, then depending on the result of that,
skipping back over what you just skipped.

>
>I don't find that so compelling either, frankly.  Why should it really
>matter in the end?  I've always found C's order (and punctuation) confusing,

Confusing how?  Perform test, choose branch.  Simple.

And it's not punctuation.  It's an operator, just like + or & or ~.  I
can understand how you might find the terseness confusing, though.

>I have to look it up practically everytime I use it or have to read it 
>(which correlates to it being used very rarely, with causality in both
>directions).

FWIW, in over 20 years of C programming, I use it pretty rarely too,
though I never had to look it up after I first saw it in K&R. It only
very rarely holds any advantage over a simple if/else statement,
especially in modern compilers. It's most useful in macros, which
python doesn't even have.

>
>Given that situation, choosing a form which is easy to read is surely
>an advantage, and, since it is the way that Python has handled logic
>in the past, it makes sense to continue doing so.

Easy to read out loud, but complex to understand, with all the back
and forth scanning required.

>
>No doubt, ANY choice of ternary operator for Python will be
>criticized, and no doubt, ANY choice would nevertheless be
>usable.

The whole idea of a ternary operator is somewhat complex.  

>
>OTOH, I think this choice is consistent with the rest of Python's
>design. The general choice to use keyword operators for LOGIC
>and symbolic operators for MATH is retained, and so long as we're
>describing the logic in words, it makes sense for the wording
>to sound natural.

I guess I agree, thoug I would have preferred to see something like
r = c ?then: yes else: no

>
>Consistency certainly does make it easier for me to remember.

I guess I disagree that it's consistent, at least with the way I see
python.

>
>Python's main advantage over other languages, for me, is that
>it makes me run to the manual a lot less, and I generally don't
>get confused trying to follow other people's code.

I'm inexperienced enough to keep Beazley's book at my elbow when
writing my own code, though reading other's code is usually simpler.
Until things like __metaclass__ and @classmethod start showing up...

Regards,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Info] PEP 308 accepted - new conditional expressions

[Dave Hansen]

On Tue, 11 Oct 2005 01:06:30 -0400, "George Sakkis"
<[EMAIL PROTECTED]> wrote:

>"Dave Hansen" <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 10 Oct 2005 16:42:34 -0500, Terry Hancock
>> <[EMAIL PROTECTED]> wrote:
>>
>> >On Sunday 09 October 2005 07:50 am, phil hunt wrote:
>> >> On Fri, 7 Oct 2005 01:05:12 -0500, Terry Hancock <[EMAIL PROTECTED]> 
>> >> wrote:
>> >> >GvR's syntax has the advantage of making grammatical sense in English 
>> >> >(i.e.
>> >> >reading it as written pretty much makes sense).
>> >>
>> >> I know, let's re-write Python to make it more like COBOL! That's
>> >> bound to be a winner!
>> >
>> >Whereas the "natural order" of "condition affirmative negative" is natural
>> >for what reason?  That it is so in C?
>>
>> And Basic, and Fortran, and Lisp, and just about any programming
>> language you care to name, including python (if Condition: Affirmative
>> else: Negative).
>
>Block delimiters (curly braces, if/fi, begin/end, etc.) are also in just about 
>any language but this
>didn't stop python using indentation instead, so what's your point ? 
>Conformity and backwards

The point is order of execution.  The condition is tested first, so it
should appear first.  I can think of no other language besides Perl
where that is not the case.  Admittedly, I don't know every other, or
even a large number, of other languages.

>compatibility should not be top priorities in language design; fortunately for 
>python, they're not.

Conformity I'd agree with, backwards capatibility I strongly disagree.
Breaking existing programs is a Bad Thing(tm).  All the code I wrote
for Python 1.52 still seems to work in 2.4.

Regards,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Info] PEP 308 accepted - new conditional expressions

[Dave Hansen]

On Wed, 12 Oct 2005 13:02:20 +0200, Piet van Oostrum <[EMAIL PROTECTED]>
wrote:

>> Paul Rubin  (PR) wrote:
>
[...]
>
>>PR> Yeah, "if C then A else B" is a ancient tradition stretching from
>>PR> Algol-60 to OCAML, and who knows what all else in between.  I'm not
>>PR> sure what Guido saw in the "A if C else B" syntax but it's not a big deal.
>
>I suspect it is because "if C then A else B" gives problems in the parser
>because it would have difficulty to distinguish this in time from the if
>statement. This is because the parser doesn't use a very strong formalism. 

So lose the "if."

   R = C then A else B

I don't think python uses the question mark for anything.  Throw that
in, if it makes parsing easier:

   R = C ? then A else B

Regards,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Dave Hansen]

On Wed, 12 Oct 2005 21:44:22 GMT, Roedy Green
<[EMAIL PROTECTED]> wrote:

[...]
>Obviously you can't trust anything code-like that arrives from
>strangers. It is an extension of the law Mommy laid down not to take
>candy from strangers.
>
>However, formatted text is not code. Pictures are not code.  It is
>unfair to tar them with the brush of JavaScript or the goofy things
>Outlook does with enclosures.

http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx

Summary: a buffer overflow problem in Microsoft's JPEG redering
library, used my almost all Windoze email and web clients, would allow
an attacker to execute any arbitrary code he wished on your computer
simply by tricking you into viewing a doctored JPEG image.  Since
solved (this problem is _so_ last year, dahling), but it belies your
assertion that "pictures are not code."

Regards,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Info] PEP 308 accepted - new conditional expressions

[Dave Hansen]

On Thu, 13 Oct 2005 21:49:15 +0200, Piet van Oostrum <[EMAIL PROTECTED]>
wrote:

>>>>>> [EMAIL PROTECTED] (Dave Hansen) (DH) wrote:
>
>>DH> So lose the "if."
>
>>DH>R = C then A else B
>
>>DH> I don't think python uses the question mark for anything.  Throw that
>>DH> in, if it makes parsing easier:
>
>>DH>R = C ? then A else B
>
>We have already had this discussion several times. I don't think it is
>going to add anything new to it. Besides after the BDFL has decided it is
>useless. 

Oh, agreed, most assuredly (except that "we" didn't include "me," not
that that would have made any difference, but I missed most of the
discussion).  I was merely responding to your assertion that using "if
C then A else B" could cause parsing problems.

I'm not convinced python even needs a ternary operator.  I just wish
the syntax chosen by the BDFL made more sense.  Even if I don't use
it, I'll likely have to read it...

Regards,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Underscores in Python numbers

[Dave Hansen]

On 7 Nov 2005 18:02:09 -0800 in comp.lang.python, "Gustav Hållberg"
<[EMAIL PROTECTED]> wrote:

>I tried finding a discussion around adding the possibility to have
>optional underscores inside numbers in Python. This is a popular option
>available in several "competing" scripting langauges, that I would love
>to see in Python.
>
>Examples:
>  1_234_567
>  0xdead_beef
>  3.141_592
>
>Would appreciate if someone could find a pointer to a previous
>discussion on this topic, or add it to a Python-feature-wishlist.

I've never needed them in Python, but I've very often wished for them
in C.  Along with 0b(0|1)* for binary numbers, where they'd be even
more useful.

Of course, I write _far_ more code in C than Python.  But I've seen
enough bugs of the sort where someone wrote 120 when they meant
1200, that I see great value in being able to specify 12_000_000.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is parameter an iterable?

[Dave Hansen]

On 15 Nov 2005 11:26:23 -0800 in comp.lang.python, "py"
<[EMAIL PROTECTED]> wrote:

>Dan Sommers wrote:
>> Just do it.  If one of foo's callers passes in a non-iterable, foo will
>> raise an exception, and you'll catch it during testing
>
>That's exactly what I don't want.  I don't want an exception, instead I
>want to check to see if it's an iterableif it is continue, if not
>return an error code.  I can't catch it during testing since this is
>going to be used by other people.

Then catch the exception yourself.

   >>> def foo2(i):
try:
for j in i:
print j
print "Success!"
return 0
except TypeError, e:
print "Bad foo.  No donut.", e
return -1


   >>> joe = foo2([1,3,5,7,9])
   1
   3
   5
   7
   9
   Success!
   >>> print joe
   0
   >>> bob = foo2(2)
   Bad foo.  No donut. iteration over non-sequence
   >>> print bob
   -1
   >>> 

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reinvent no more forever

[Dave Hansen]

On 17 Nov 2005 18:06:55 -0800 in comp.lang.python, "Phillip J. Eby"
<[EMAIL PROTECTED]> wrote:

[...]
>
>Okay, so call yours "SuperEnum" or "PowerEnum" or "UltraEnum" or
>"BetterEnum", "Enum-O-Matic", "Symbolitron"...

ITYM "EnumOMatic" or "Enum_O_Matic".  "Enum-O-Matic" is a syntax
error.  Or worse...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to do "new_variable = (variable) ? True : False; " (php) on python?

[Dave Hansen]

On Fri, 18 Nov 2005 14:15:06 -0800 in comp.lang.python, Scott David
Daniels <[EMAIL PROTECTED]> wrote:

>
>
>Don't try to force everything to the type you expect,
>use things as they are; embrace duck-typing.
>

Wrong, the grammar you have.
Do not Everything to the type you expect force.
Do or do not, there is no try.
Things as they are use.
Duck-typing embrace.

>:-)

Ditto.  Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Underscores in Python numbers

[Dave Hansen]

Sorry for the delayed response.  I somehow missed this earlier.

On Tue, 8 Nov 2005 15:39:09 + (UTC) in comp.lang.python,
[EMAIL PROTECTED] (Roy Smith) wrote:

>Dave Hansen  <[EMAIL PROTECTED]> wrote:
>> Of course, I write _far_ more code in C than Python.  But I've seen
>> enough bugs of the sort where someone wrote 120 when they meant

Digression: 1 was enough.

>> 1200, that I see great value in being able to specify 12_000_000.
>
>I'll admit that being able to write 12_000_000 would be convenient.
>On the other hand, writing 12 * 1000 * 1000 is almost as clear.  In C,

Perhaps, but it's pretty obvious that something's wrong when you have
to resort to ugly tricks like this to make the value of a simple
integer constant "clear."

And think about 64 (or longer) -bit unsigned long long hexadecimal
values.  How much nicer is 0xFFF0_FF0F_F0FF_0FFF_ULL than
0xFFF0FF0FF0FF0FFFULL?  I guess we could do something like
0xFFF0ULL<<16)|0xFF0FULL)<<16)|0xF0FFULL)<<16)|0x0FFFULL), but I'm
not sure it's any better.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Hot to split string literals that will across two or more lines ?

[Dave Hansen]

On Tue, 22 Nov 2005 18:38:15 + in comp.lang.python, Steve Holden
<[EMAIL PROTECTED]> wrote:

[...]
>
>Of course there's also the alternative of escaping the newlines out in 
>the literal. The replace result above is exactly
>
>"""\
>lots of text hundreds of characters long\
>more text on another line but we really don't want any line breaks\
>in our final string\
>so we replace newlines in this multiline string\
>with an empty string thus\
>"""

>>> """\
That's pretty close, but\
if you don't include spaces at the ends of words\
then Python will run those words\
together, which is probably not what you want."""
"That's pretty close, butif you don't include spaces at the ends of
wordsthen Python will run those wordstogether, which is probably not
what you want."
>>> """\
So you need to add spaces, but make sure they're \
before the backslash, and not after."""
"So you need to add spaces, but make sure they're before the
backslash, and not after."
>>> 

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Converting a flat list to a list of tuples

[Dave Hansen]

On Tue, 22 Nov 2005 20:12:52 GMT in comp.lang.python, [EMAIL PROTECTED]
(Bengt Richter) wrote:

>On Tue, 22 Nov 2005 13:26:45 +0100, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
>
>>Duncan Booth wrote:
>>
>>> That's funny, I thought your subject line said 'list of tuples'. I'll
>>> answer the question in the subject rather than the question in the body:
>>>
>>> >>> aList = ['a', 1, 'b', 2, 'c', 3]
>>> >>> it = iter(aList)
>>> >>> zip(it, it)
>>> [('a', 1), ('b', 2), ('c', 3)]
>>
[...]
>
>Hm, actually, something tells me I've seen some variation of this before,
>but I can't think of the context off hand.

Earlier this fall I posted a question about iterating over a sequence
while modifying it.  Google should bring it up.

This strikes me as the same idea, only inside-out...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: defining the behavior of zip(it, it) (WAS: Converting a flat list...)

[Dave Hansen]

On Tue, 22 Nov 2005 23:17:31 -0700 in comp.lang.python, Steven Bethard
<[EMAIL PROTECTED]> wrote:

>[EMAIL PROTECTED] wrote:
[...]
>> IIRC, this was discussednd rejected in an SF bug report.  It should not
>> be a defined behavior for severals reasons:
>[snip arguments about how confusing zip(it, it) is]
>> Overall, I think anyone using zip(it,it) is living in a state of sin,
>> drawn to the tempations of one-liners and premature optimization.  They
>> are forsaking obvious code in favor of screwy special cases.  The
>> behavior has been left undefined for a reason.
>
>Then why document itertools.izip() as it is?  The documentation there is 
>explicit enough to know that izip(it, it) will work as intended.  Should 
>we make the documentation there less explicit to discourage people from 
>using the izip(it, it) idiom?

ISTM that one would use itertools.izip in order to get some
functionality not available from zip.  Perhaps this is one of those
bits of functionality.

But I admit, I'm not all that familiar with itertools...

In any case, the solution seems obvious: if you want the guarantee,
use the tool that provides it.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: newbie question concerning formatted output

[Dave Hansen]

On Tue, 29 Nov 2005 17:40:08 GMT in comp.lang.python, Thomas Liesner
<[EMAIL PROTECTED]> wrote:
[...]>
>So instead of:
>
>3905
>3009
>
[...]
>
>i'd like to have:
>
>3905 3009 
[...]
>
>This is the codesnippet i am using:
>
>#!/usr/bin/python
>
>import string
>inp = open("xyplan.nobreaks","r")
>data = inp.read()
>for words in data.split():
>print words
>inp.close()
>
>Any hints?

Here's an obvious, if naive, implementation:

   data = imp.read().split()
   for i in range(0,len(data),3):
  tl = data[i:i+3]
  for d in tl:
 print d,
  print
   inp.close()

HTH,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compiling Guppy-PE extension modules

[Dave Hansen]

On 29 Nov 2005 11:53:31 -0800 in comp.lang.python, "Sverker Nilsson"
<[EMAIL PROTECTED]> wrote:

[...]
>One of the problems, seems to be string constants in the C source that
>contain newlines. I am using GCC on Linux so, I missed this with the

I'm not sure what you mean by this.  Something like

   char long_string[] = " A long string that
  extends to subsequent lines
  before closing the quote? ";

>standard warning options. Compiling with -pedantic reveals 'a lot' of
>places where this is a problem.
>
>I could fix this but it takes some work and it makes the source code
>less readable so I was wondering ...

Eye of the beholder, I guess.

You were aware that C supports concatenation of string literals
separated only by whitespace?  For example, if the problem is similar
to the long_string example above, and it does what I think it does,
the following code should be equivalent and will compile on any good C
compiler (even Microsoft's).

   char long_string[] = " A long string that\n"
"  extends to subsequent lines\n"
"  before closing the quote? ";

Not that much worse, and you could probably write a Python script to
automate the changes.  If a quote opens but doesn't close on a line,
append a newline and close the quote, then prepend an opening quote on
the next line.  The only tricky part is making sure the opening quote
isn't inside a comment or character literal.

>
>Is this a common problem? Or maybe it is just the compiler version
>mentioned that doesn't handle it?

I wasn't even aware GCC supported such an extension.  Certainly no
other C compiler I've used has anything like this.

>
>Does someone know of some switch to enable the Microsoft compiler to
>accept strings with newlines?

Not that I'm aware of.  Sorry.  

Maybe one exists, but if so, I'd resist the temptation to use it.  It
might disappear in a later version of the compiler, or you might need
to use some other compiler that doesn't support multiline strings, and
you're back where you started.

[...]

>
>PS. I know it's not ANSI-correct but why do we have to work to make
>our source codes less clear?

Hysterical raisins.  Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python as Guido Intended

[Dave Hansen]

On 30 Nov 2005 10:57:04 GMT in comp.lang.python, Antoon Pardon
<[EMAIL PROTECTED]> wrote:

>On 2005-11-29, Mike Meyer <[EMAIL PROTECTED]> wrote:
>> Antoon Pardon <[EMAIL PROTECTED]> writes:
 You see, you can make languages more powerful by *removing* things
 from it.
>>> You cast this in way to general terms. The logic conclusion
>>> from this statements is that the most powerfull language
>>> is the empty language.
>>
>> The only way you reach that conclusion is if you read the statement as
>> saying that removing things *always* makes a langauge more
>> powerful. That's not what I said,
>
>I would say it is the common interpretation for such a sentence.

I hope no one ever tells you that you'd be healthier if you ate less
and exercised more. (Perhaps it's not true in your case, but it
certainly is in mine.)

Regards,

-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Quene

[Dave Hansen]

On 30 Nov 2005 09:38:44 -0800 in comp.lang.python, "Tuvas"
<[EMAIL PROTECTED]> wrote:

>I am trying to write a function that holds a variable-length quene. The
>quene has 2 bits of information. At some point, I would like to remove
>bits of this quene, when they are completed. Is there a way to do this
>with something as follows?
>

the following might work...

>quene=[]
>quene.append((4,2))
>quene.append((3,6))
>if(4 in quene):#Shows false, what's the correct syntax to
>show true?

 found = [t for t in queue if t[0] == 4]
 if found:

>remove 4 from quene #(Not python code, not sure how to do this...)
 queue.remove(found[0])

HTH,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: Dao Language v.0.9.6-beta is release!

[Dave Hansen]

On 2 Dec 2005 10:08:21 -0800 in comp.lang.python, [EMAIL PROTECTED]
wrote:

>Here it is again...  Python bypassed/discounted because, of all things,
>scoping by indentation!?!?
>
>This used to surprise me.  Until I hear more and more otherwise
>reasonable programmers list this as their number one reason for
>shunning Python.
>
>I gauge design defects by how much after market
>discussion/documentation a feature generates/requires.   Scoping by
>indentation is a whopper of a defect.

FWIW, indentation scoping one one of the features that _attracted_ me
to Python.  

It's far more interesting to me _why_ people think indentation scoping
is a bad thing.  The answer I get back fall into two general
categories: 1) I've heard/read/been told it's a bad thing, and 2) It
causes portability problems.

Of these, only (2) is valid.  And the only reason it's valid is that
Python recognizes the TAB character as valid indentation.  TAB
characters are evil.  They should be banned from Python source code.
The interpreter should stop translation of code and throw an exception
when one is encountered.  Seriously.  At least, I'm serious when I say
that.  I've never seen TAB characters solve more problems than they
cause in any application.

But I suspect I'm a lone voice crying in the wilderness.  Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why my modification of source file doesn't take effect when debugging?

[Dave Hansen]

On Fri, 02 Dec 2005 18:04:15 +0100 in comp.lang.python, Christophe
<[EMAIL PROTECTED]> wrote:

>infidel a écrit :
>>>I'm using the Windows version of Python and IDLE. When I debug my .py
>>>file, my modification to the .py file does not seem to take effect
>>>unless I restart IDLE. Saving the file and re-importing it doesn't help
>>>either. Where's the problem?
>> 
>> 
>> "import" only reads the file the first time it's called.  Every import
>> call after that looks up the module in memory.  This is to prevent
>> circular dependencies between modules from creating infinite loops.
>> You need to use the reload() function:
>
>As a matter of fact, it would help a lot if that stupid behaviour of 
>Idle was dropped. I'm sure I'm not the only one who lost lots of time 
>because of that bug. Yes I call it a bug.

But, if you are editing a Python Module in Idle, and press F5 to run
the module, the interpreter is restarted for you.  So what's the
problem?

I would consider it a far greater problem if Idle _didn't_ do that --
it could mean you module worked when you were debuggining it because
of some initialization that doesn't get performed in a clean start.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: Dao Language v.0.9.6-beta is release!

[Dave Hansen]

On 8 Dec 2005 08:17:14 GMT in comp.lang.python, Antoon Pardon
<[EMAIL PROTECTED]> wrote:

[...]

>I just think braces are the worst solution for it, as python is
>concerned.

Agreed.  A model like Modula-2's would be much preferable, and in fact
is supported (but not enforced) today (as long as you also obey
indentation rules).  Just mark the end of your blocks with #endif,
#endfor, #endwhile, #enddef, #endclass, #endwhatever as appropriate.  

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bitching about the documentation...

[Dave Hansen]

On Wed, 07 Dec 2005 12:33:07 -0600 in comp.lang.python, Rocco Moretti
<[EMAIL PROTECTED]> wrote:

[...]

>fred where guido had had had had had had had had had had had a better 
>effect on the reader

I've seen this before as

bill had had had but will had had had had had had or had had been
correct had had had

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Unexpected Behavior Iterating over a Mutating Object

[Dave Hansen]

OK, first, I don't often have the time to read this group, so
apologies if this is a FAQ, though I couldn't find anything at
python.org.

Second, this isn't my code.  I wouldn't do this.  But a colleague did,
got an unexpected result, and asked me why.  I think I can infer what
is occurring, and I was able to find a simple work-around.  But I
thought I'd ask about it anyway.

I've been pushing Python at work for use as a scripting language to
get simple tasks done.  My colleague is modifying a parts library for
a schematic capture program with a Python script.  The library is
entirely in ASCII text.  

He's trying to delete a group of parts from the library.  The simple
code below shows what is occurring (taken from an IDLE session, Python
2.4.1#65 for Windoze).  The "parts" to be deleted in the example
contain the string 'DEL':

---begin included file---
>>> data = [ 'First', 'Second DEL', 'Third', 'Fourth',
 'Fifth DEL', 'DEL Sixth', 'Seventh DEL', 'Eighth DEL',
 'Ninth DEL', 'Tenth', 'Eleventh', 'Twelfth']

>>> bfr = []
>>> for item in data:
if item.find('DEL') >= 0:
bfr.append(item)
data.remove(item)


>>> data
['First', 'Third', 'Fourth', 'DEL Sixth', 'Eighth DEL', 'Tenth',
'Eleventh', 'Twelfth']
>>> bfr
['Second DEL', 'Fifth DEL', 'Seventh DEL', 'Ninth DEL']
---end included file---

It seems when an item is 'remove'd from data, the rest of the list
'shifts' over one, so what was 'next' now occupies the slot of the
'remove'd item.  When the next 'item' is selected from 'data', the
_desired_ 'next' item is skipped.  So when 'data' has several
consecutive items to be deleted, only every other one is 'remove'd.

The workaround is very simple:

---begin included file---
>>> for item in data:
if item.find('DEL') >= 0:
bfr.append(item)


>>> for item in bfr:
data.remove(item)


>>> data
['First', 'Third', 'Fourth', 'Tenth', 'Eleventh', 'Twelfth']
>>> bfr
['Second DEL', 'Fifth DEL', 'DEL Sixth', 'Seventh DEL', 'Eighth DEL',
'Ninth DEL']
---end included file---

Again, iterating over an item that is mutating seems like a Bad
Idea(tm) to me.  But I was curious: is this the intended behavior, or
does this fall under what C programmers would call 'undefined
behavior.'

Thanks,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected Behavior Iterating over a Mutating Object

[Dave Hansen]

On Tue, 13 Sep 2005 21:28:21 GMT, [EMAIL PROTECTED] (Dave Hansen)
wrote:

>OK, first, I don't often have the time to read this group, so
>apologies if this is a FAQ, though I couldn't find anything at
>python.org.
>

Thanks to everyone who responded.  All is clear now.  And I know I
need to look deeper into list comprehensions...  

Regards,

   -=Dave
-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PHP = Perl Improved

[Dave Hansen]

On Sat, 10 Dec 2005 08:25:08 GMT in comp.lang.python, Tim Roberts
<[EMAIL PROTECTED]> wrote:

[...]
>
>The design of the PHP language is not too bad, and the standard library is
>extensive.  It is quite possible to write well-structured, class-based web
>programs with PHP.
>
>However, it seems that almost no one actually does so.  Virtually all of
>the vast PHP code samples on the web are crap.  Maybe the simplicity of the
>language encourages inexperienced programmers who write spaghetti code
>without a thought to the structure; I don't know the exact cause, but I
>have seen it more often than not.

This reminds me of a comment that John Levine (moderator of
comp.compilers) wrote in a post back in 1997: "It is my impression
that it's possible to write good programs in C++, but nobody does."

However, in the case of C++, I wouldn't blame "... the simplicity of
the language ..."

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about tuple lengths

[Dave Hansen]

On Wed, 14 Dec 2005 12:58:16 -0500 in comp.lang.python, Jean-Paul
Calderone <[EMAIL PROTECTED]> wrote:

[...]
>
>It's the comma that makes it a tuple.  The parenthesis are only required in 
>cases where the expression might mean something else without them.

That's almost true.  Consider:

>>> t2 = (1,2)  # 2 element tuple
>>> t1 = (1,)   # 1 element tuple
>>> t0 = (,)# 0 element tuple?
  File "", line 1
t0 = (,)
  ^
SyntaxError: invalid syntax
>>> t0 = () # Guess not, try parens with no comma
>>> print t0, t1, t2
() (1,) (1, 2)
>>> print type(t0), type(t1), type(t2)
  
>>> print len(t0), len(t1), len(t2)
0 1 2
>>>

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ?: in Python

[Dave Hansen]

On Wed, 14 Dec 2005 21:16:23 +0100 in comp.lang.python, Lawrence
Oluyede <[EMAIL PROTECTED]> wrote:

>Il 2005-12-14, Andy Leszczynski <[EMAIL PROTECTED]> ha scritto:
>> How can do elegantly in Python:
>>
>> if condition:
>> a=1
>> else:
>> a=2
>>
>> like in C:
>>
>> a=condition?1:2
>>
>
>There are tons of threads on this newsgroup and in the python-dev mailing
>list about a ternary operator. There's also a PEP AFAIK.
>
>I like this:
>
>In [1]:switch = True
>
>In [2]:a = (1, 2)[switch]
>
>In [3]:print a
>2

Note, however, you have the logic backwards.  To duplicate the
functionality of the OP's example, you need

   a = (2,1)[condition]

or

   a = (1,2)[not condition]

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why and how "there is only one way to do something"?

[Dave Hansen]

On Thu, 15 Dec 2005 14:57:18 + in comp.lang.python, Steve Holden
<[EMAIL PROTECTED]> wrote:

[...]
>Would you say
>
> do:
> suite
> while condition
>
>or what? Basically do ... while and do ... until most naturally put the 

Works for me, though I wouldn't cry if the "while" was changed to
"until" to make the difference between this form and the "while" loop
more obvious.  I don't think there's a good argument for _both_
do-while and do-until, but one or the other would be useful.

The biggest objection I see is the addition of one or two more
keywords, but I don't recall using "do" or "until" as a name in any of
my programs...

>test after the loop body (suite), and it's difficult to think of a 
>consistent and natural syntax for expressing the construct. Not that 
>this stopped lots of people from coming forward with their personal 
>favourites ... some suggestions even offered "n and a half" looping 
>possibilities.

Syntax is the problem?  Specifically the position of the condition
after the loop body?  How do you explain the syntax of the new Python
ternary operation, with the test in the middle, even though it
logically has to be done first?

Right now, I tend to write these loops something like

   while 1:
  do_stuff()
  if exit_condition: break

which offends my sense of aesthetics, but it works.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tuples

[Dave Hansen]

On 15 Dec 2005 09:19:37 -0800 in comp.lang.python, "Tuvas"
<[EMAIL PROTECTED]> wrote:

>Let's say I make a program something like follows:
>
>x=[]
>x.append([1,2,3])
>x.append([4,5,6])
>print x
>print x[0]
>print x[0][1]
>x[0][1]=5
>
>Okay, everything works here as expected except the last line. Why won't
>this work? Thanks for the help!

Perhaps because you're not expecting the right thing?  Here's what I
get:

>>> x = []
>>> x.append([1,2,3])
>>> x.append([4,5,6])
>>> print x, x[0], x[0][1]
[[1, 2, 3], [4, 5, 6]] [1, 2, 3] 2
>>> x[0][1]=5
>>> print x
[[1, 5, 3], [4, 5, 6]]
>>>

Which is what i would expect.  Regards,

-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to create linked list automatically

[Dave Hansen]

On Mon, 19 Dec 2005 20:51:39 + in comp.lang.python, Simon Brunning
<[EMAIL PROTECTED]> wrote:

>I haven't the time (or inclination) to sort out all your problems
>here, but one thing jumps out at me:
>
>On 12/19/05, Shahriar Shamil Uulu <[EMAIL PROTECTED]> wrote:
>> class Node:
>> def __init__(self,name=None,next=None):
>> self.name=name
>> self.next=next
>>
>> def __str__(self):
>> return str(self.name)
>
>Your Node classes str() prints the instances self.name attribute,
>which is set by an optional named argument on the initialiser...
>
>> w=[]
>> for i in range(10):
>> node=Node(i)
>
>... but you aren't providing this argument when you build your Node objects...

Actually, he is.  Look closer.

As /F pointed out, his problem is in the linking.  By making a small
modification to his code, I was able to get it to print 

   1 2 3 4 5 6 7 8 9 None

As (I assume) was expected.  I'd post the code, but the margin is too
small to contain it...  Besides, I'd like the OP to figure it out
himself.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: parsing engineering symbols

[Dave Hansen]

On Wed, 21 Dec 2005 19:10:21 +0530 in comp.lang.python, Suresh
Jeevanandam <[EMAIL PROTECTED]> wrote:

[re: SI prefixes]
>
>Exactly what I wanted.
>
>It would be nice if the standard float function takes care of these.

No, it wouldn't.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: type error on porting outfile.write

[Dave Hansen]

On Tue, 20 Dec 2005 22:11:01 -0500 in comp.lang.python, Eric McCoy
<[EMAIL PROTECTED]> wrote:

>[EMAIL PROTECTED] wrote:
>> I ported my code from the development to
>> application platform, I found a "type error"
>> on a fileout statement:
>
>> outfile.write(object.id +",")
>
>What is the type of object.id?  I'm guessing an integer.  The exception
>should tell you, e.g.:
>
>  TypeError: unsupported operand type(s) for +: 'int' and 'str'
>
>If I'm right, you can do this:
>
>  outfile.write("%d," % (object.id))

Or, more generally,

   outfile.write("%s, " % object.id)

or even (closer to the original code)

   outfile.write(str(object.id)+", ")

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to check if a string "is" an int?

[Dave Hansen]

On Thu, 22 Dec 2005 01:41:34 +1100 in comp.lang.python, Steven
D'Aprano <[EMAIL PROTECTED]> wrote:

[...]
>Well, let's find out, shall we?
[...]
>A small but consistent speed advantage to the try...except block.
>
>Having said all that, the speed difference are absolutely trivial, less
>than 0.1 microseconds per digit. Choosing one form or the other purely on
>the basis of speed is premature optimization.

Or maybe on which actually works.  LBYL will fail to recognize
negative numbers, e.g.

def LBYL(s):
if s.isdigit():
return int(s)
else:
return 0

def JDI(s):
try:
return int(s)
except:
return 0

test = '15'
print LBYL(test), JDI(test)   #-> 15 15

test = '-15'
print LBYL(test), JDI(test)   #-> 0 -15

>
>But the real advantage of the try...except form is that it generalises to
>more complex kinds of data where there is no fast C code to check whether

re: Generalization, apropos a different thread regarding the %
operator on strings.  In Python, I avoid using the specific type
format conversions (such as %d) in favor of the generic string
conversion (%s) unless I need specific field width and/or padding or
other formatting, e.g.

   for p in range(32):
v = 1

Re: How to check if a string "is" an int?

[Dave Hansen]

On 21 Dec 2005 14:36:32 -0800 in comp.lang.python, Paul Rubin
 wrote:


>There is a third choice which is the natural and obvious one: have the
>function do what its name indicates.  Return true if the arg is a
>digit and false otherwise.  If iterating over the whole string is
>useful (which it may be), then the function should have been named
>differently, like .isdigits instead of .isdigit.

Following your logic to its conclusion, had the name isdigits been
chosen, '1'.isdigits() should return False.  It's only one digit, not
more than one, as the plural would imply.

I, for one, don't see any utility in the dichotomy.  We only need
(should only have) one function.  I do agree that isdigits might have
been a better name, but we're stuck with isdigit for hysterical
raisins.  And it's logical that string functions work over a string
rather than its first character.

>
>FWIW, I've usually tested for digit strings with re.match.  It never
>occurred to me that isdigit tested a whole string.  

Someone's been trotting out that old jwz chestnut about regular
expressions and problems...  Not that I agree with it, but ISTM that
regular expressions are vast overkill for this problem.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Guido at Google

[Dave Hansen]

On Wed, 21 Dec 2005 16:14:16 -0600 in comp.lang.python, Rocco Moretti
<[EMAIL PROTECTED]> wrote:

[...]
>15 meters (150 decimeter, 1500 cm, etc ...)
>590 inches
>49 feet
>16 yards
>0.0093 miles
>0.008 nautical miles
>3 rods
>0.075 furlongs
>1800 barleycorns
>147.63 hands
>66 spans
>33 cubits
>13 ells
>8.2 fathoms
>75 links
>0.75 chains
>0.0027 leauges
>0.03 li
>0.081 stadia
>4.8e-16 parsecs
>1e-10 astronomical units
>5e-8 lightseconds
>2.8e11 Bohr radiuses
>9.2e35 Plank lenghts
>
>and probably most appropriately (being dutch):
>
>1.5 roede
>
>In other words "a stone's throw away".

You forgot 

8.81419673 smoots

Regards,

-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: problem adding list values

[Dave Hansen]

On Thu, 22 Dec 2005 19:43:15 GMT in comp.lang.python, "David M. Synck"
<[EMAIL PROTECTED]> wrote:

[...]
>temp = float(raw_input("Please enter the first credit \n"))
>
>while temp != 0:
>credlist.append(temp)
>temp = float(raw_input("Please enter the next credit \n"))

Here you're building credlist as a list of floats.

>   
>i = 0

This is wasted effort

>for i in credlist:

You've asked to loop through credlist, so each value of i is going to
be float.  Maybe you should rename i to something that looks less like
an index and more like a credit.

>credits += credlist[i]

Here, you're trying to indexa list with a float.  No can do...
[...]
>TypeError: list indices must be integers

...ss it's telling you here
>
>
>If anyone can point me in the right direction, I would greatly appreciate
>it.

I think what you want is 

   for cr in credlist:
  credits += cr

Which could also be implemented as

   credits = reduce(lambda x,y: x+y, credlist)

HTH,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What's wrong with this code snippet?

[Dave Hansen]

You've received good answers to your original question.  Just a side
issue...

On Wed, 4 Jan 2006 22:19:27 + (UTC) in comp.lang.python, Karlo
Lozovina <[EMAIL PROTECTED]> wrote:

[...]
>def GenerateRandomColour():
>rn.seed()
>colour = rn.choice(['C', 'P', 'Z'])
>return colour

I'm not sure what rn is, but it looks like a standard library
random.Random object.  If so, I don't think you want to seed your PRNG
each time you use it -- your numbers might be much less random that
way.  If it is the standard library object, the PRNG is seeded when
the module is first imported, so you may not need to seed it at all.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What's wrong with this code snippet?

[Dave Hansen]

On Thu, 5 Jan 2006 01:14:43 + (UTC) in comp.lang.python, Karlo
Lozovina <[EMAIL PROTECTED]> wrote:

>Dave Hansen <[EMAIL PROTECTED]> wrote in 
>news:[EMAIL PROTECTED]:
>
>> I'm not sure what rn is, but it looks like a standard library
>> random.Random object.  If so, I don't think you want to seed your PRNG
>> each time you use it -- your numbers might be much less random that
>> way.  If it is the standard library object, the PRNG is seeded when
>> the module is first imported, so you may not need to seed it at all.
>
>Yes, it is random module. So, what is the preferred way of seeding random 
>number generator? Just once in a file? Or something else?
>
>I just needed some "random" choices to be made, so I didn't dig much into 
>random module. Anyway, thanks for pointing this out, appreciated.

>From my reading of the library docs, when you import random the PRNG
is seeded (using the current time) for you automatically.  

If you call seed without a parameter, it will again use the current
time to seed the generator.  But the generator only needs one seed to
generate a random sequence.  Re-seeding the generator starts it
proding a new, different sequence. The resulting sequence of numbers
is really the first number in several distinct sequences.

It may be that the sequence of first numbers is "random enough" for
your use.  But the call to seed is useless at best, and damaging at
worst.

Unless you want to reproduce the same string of random numbers,
there's really no reason to seed the generator yourself.  Consider:

>>> rep = random.Random()
>>> rep.seed(1234)
>>> first = [rep.random() for x in range(10)]
>>> second = [rep.random() for x in range(10)]
>>> rep.seed(1234)
>>> third = [rep.random() for x in range(10)]
>>> print first == second
False
>>> print first == third
True
>>> fourth = [rep.random() for x in range(10)]
>>> print second == fourth
True
>>>  

In your code, I would simply remove the rn.seed() call.  Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the slickest way to transpose a square list of lists (tuple of tuples)?

[Dave Hansen]

On Sun, 08 Jan 2006 14:27:55 -0500 in comp.lang.python, Gerard Brunick
<[EMAIL PROTECTED]> wrote:

>My way is ugly.  These has to be a better way.

This may not be the "slickest" way, but I needed some practice with
list comprehensions (I've never really gotten used to them...)

This works with lists.  Making it work with tuples should be a simple
change.  Also, it works for the general case of rectangular matrices
rather than being limited to squares.

>>> def transpose(m):
"""
Transpose the rectangular two-dimentional matrix m.
"""
return [[m[y][x] for y in range(len(m))]for x in
range(len(m[0]))]

>>> def pm(m):
"""
Print the matrix m.  Just to see the results.
"""
for row in m:
print row


>>> td = [range(10) for x in range(10)]
>>> pm(td)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> pm(transpose(td))
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
[1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
[2, 2, 2, 2, 2, 2, 2, 2, 2, 2]
[3, 3, 3, 3, 3, 3, 3, 3, 3, 3]
[4, 4, 4, 4, 4, 4, 4, 4, 4, 4]
[5, 5, 5, 5, 5, 5, 5, 5, 5, 5]
[6, 6, 6, 6, 6, 6, 6, 6, 6, 6]
[7, 7, 7, 7, 7, 7, 7, 7, 7, 7]
[8, 8, 8, 8, 8, 8, 8, 8, 8, 8]
[9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>>> td2 = [range(10) for x in range(5)]
>>> pm(td2)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> pm(transpose(td2))
[0, 0, 0, 0, 0]
[1, 1, 1, 1, 1]
[2, 2, 2, 2, 2]
[3, 3, 3, 3, 3]
[4, 4, 4, 4, 4]
[5, 5, 5, 5, 5]
[6, 6, 6, 6, 6]
[7, 7, 7, 7, 7]
[8, 8, 8, 8, 8]
[9, 9, 9, 9, 9]
>>> 

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to create a script that list itself ?

[Dave Hansen]

On 9 Jan 2006 10:09:19 -0800 in comp.lang.python, "Patrick  Allaire"
<[EMAIL PROTECTED]> wrote:

>How to create a script that list itself ?

Stealing from the old C chestnut:

s="s=%c%s%c;print s%%(34,s,34)";print s%(34,s,34)


>
>I would like to know, where is the script's code is stored once we
>start it. I know I can achieve that, using files :

Well, in the above, the script (or rather, the information necessary
to print the script) is actually stored in a string that is part of
the script...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Indentation/whitespace

[Dave Hansen]

On Thu, 12 Jan 2006 11:56:05 +0800 in comp.lang.python, Jon Perez
<[EMAIL PROTECTED]> wrote:

[...]
>
>Although the below does work, I believe:

Verified example:

>>> def check_indent(n):
if n==4:
print "You like four spaces"
elif n==3:
   print "I like three"
elif n==2:
  print "Others like two"
else:
print "But don't mix TABs and spaces!"


>>> for n in range(4,0,-1):
check_indent(n)


You like four spaces
I like three
Others like two
But don't mix TABs and spaces!
>>> 

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: - E04 - Leadership! Google, Guido van Rossum, PSF

[Dave Hansen]

On 11 Jan 2006 21:30:11 -0800 in comp.lang.python,
[EMAIL PROTECTED] (Aahz) wrote:

[..]
>
>Side note: I don't have a degree, and I interviewed at Google several
>years ago.  I'm about 97% certain that my lack of degree played little
>role (if any) in my failure to get a job offer.

Side note: I have a couple degrees, and I sent in solutions to those
"tests" Google published in Dr. Dobbs a year or so back, but I never
heard back from them.

Not that I expected to.  I just did it for fun.  I'm not sure what
Google would do with someone whose entire work experience has been
developing C code for small embedded controllers anyway.  I use Python
mostly to write small utility scripts for myself.

And, FWIW, I don't think I could convince my wife (or myself) to move
to CullyFORNya for any amount of money, whether there was a massage
therapist on duty or not...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how do "real" python programmers work?

[Dave Hansen]

On 12 Jan 2006 12:20:50 -0800 in comp.lang.python, "bblais"
<[EMAIL PROTECTED]> wrote:

>Hello,
>
>Let me start by saying that I am coming from a background using Matlab
>(or Octave), and C++.  I am going to outline the basic nuts-and-bolts

I generally write C code for embedded controllers.

>of how I work in these languages, and ask for some help to find out how
>the same thing is done in Python.  I am not sure what the standard is.
[...]

I have an editor I use for writing C code with a button I've
configured to run "lint".  When the code lints clean I drop to a shell
and run "make" when I can, fire up the vile IDE for the target
platform when I can't, and build the code.  Testing means firing up a
simulator or downloading the code to the target.

>
>How do experienced python programmers usually do it?  Is there a
>"usually" about it, or is it up to personal taste?  Are there any
>convenient ways of doing these things?

I've been writing Python for about 6 years, but mostly small utilities
for personal use, so I don't think I'm typical.  I think most of my
code would run fine in 1.5.2, because that's what I started learning
on...

I use Idle.  I try things out in the interactive shell, open an editor
window to write code.  When a script is ready to test, I hit F5 to run
it. I build my systems bit-by-bit, so it's rarely worth my while to
fire up my C editor (though it does support Python syntax coloring and
auto-indenting.  It may not be the shiniest toy in the box, but Idle
does what I need it to do, and it's actually a very powerful and
effective tool for writing simple scripts.

Huge multi-module projects are probably another animal entirely.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: - E04 - Leadership! Google, Guido van Rossum, PSF

[Dave Hansen]

On 12 Jan 2006 16:16:58 -0800 in comp.lang.python,
[EMAIL PROTECTED] (Aahz) wrote:

>In article <[EMAIL PROTECTED]>,
>Dave Hansen  <[EMAIL PROTECTED]> wrote:
>>
>>And, FWIW, I don't think I could convince my wife (or myself) to move
>>to CullyFORNya for any amount of money, whether there was a massage
>>therapist on duty or not...
>
>Google also has technical offices in the New York area.

City?  .  I moved out of the 'burbs of Minneapolis about 6
years ago, not because of the weather, but because it was getting too
crowded for me.

How 'bout Des Moines, or Madison?  Or even Lubbock?  Traverse City
would be ideal, though there's no large university nearby (you can
probably guess my biases...).

Or even the Twin Cities?  I still have friends there, and might be
coaxed back. (Yeah, like Google wants to coax _me_  ;-)

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Indentation/whitespace

[Dave Hansen]

On 16 Jan 2006 20:41:24 -0800 in comp.lang.python, "thakadu"
<[EMAIL PROTECTED]> wrote:

>Yes, thats what you have to do. And that was my original point, you
>cannot just paste and go, you have to first reformat.

My heart bleeds.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can a simple a==b 'hang' in and endless loop?

[Dave Hansen]

On Wed, 18 Jan 2006 17:03:23 +0100 in comp.lang.python, Claudio Grondi
<[EMAIL PROTECTED]> wrote:

[...]
>
> >>> a = 1L
> >>> b = 1L
> >>> a is b
>False
>
>Python fails to reuse the long integer object. It would be interesting 
>to know why, because it seems to be strange, that in case of integers it 
>does (but not always and I don't know actually when it happens and what 
>it depends upon). Reusing long integers would make much more sense than 
>reusing plain integers when considering memory spent on storage.
>Hmmm...

I suspect it's a matter of practicality beating purity.  Consider

   a = 1L
   b = 10L
   ... much code ...
   c = b/5
   ... more code ...
   d = c * 3
   ... still more code ...
   e = a * 6
   ... and now the question ...
   print d is e

Do you really want the interpreter, on each long integer assignment
operation (5 in the above example), to find all the long integer
objects, perform a comparison, and re-use objects that compare equal?

Or would you rather the "is" operator alias "==" for longs?

Are either of these options really useful?

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can a simple a==b 'hang' in and endless loop?

[Dave Hansen]

On 18 Jan 2006 08:41:00 -0800 in comp.lang.python, [EMAIL PROTECTED]
wrote:

>
>Fuzzyman wrote:
>> I'm not familiar with the C basic datatypes - I assume it has an array
>> or list like object.
>>
>> Would it contain a sequence of poitners to the members ? In which case
>> they would only be equal if the pointers are the same.
>>
>> In this case :
>>
>> a = ['some string']
>> b = ['somestring']
>> a == b
>> False (probably)
>>
>> Incorrectly using Python syntax for a C example of course :-)
>>
>That depends, the C syntax is like this :
>
>char *a="hello";
>char *b="hello";
>
>assert(a==b);
>
>// true, the compiler knows the two hello are the same and assign the
>same address(sort of id() in python) to a and b

No. The C standard says the compiler is _allowed_ to re-use character
literal constants, but is not _required_ to do so.  So it may be true,
or maybe not, depedning ont he compiler (and, probably, the options
used in its invocation).

>
>But the following is not
>
>char *a="hello";
>char *b="_hello";
>char *c=b+1;
>
>assert(a==c); //false, even the content they point to are the same

Ditto.  The compiler is allowed to re-use the end of "_hello" to
implement "hello", in which case a == b+1, so a==c.

Just to confuse matter slightly, if you change the declarations to
something like

   char a[] = "hello";
   char b[] = "_hello";
   char c[] = "hello";

then a, b, and c are three different strings in three different
locations.  Always.  In this case, the user is allowed to write code
like

   a[0] = 'j';

to change the first string to "jello" without affecting the other
strings.

The essential difference is that in the first two cases, you're
declaring _pointers_ to char, and initializing them to point to string
constants, while in the second case, you're declaring _arrays_ of
char, and setting their initial value using a special initialization
syntax.

>
>However, string in the above are not basic types of C and if you want
>to compare the value(like comparing integer), you need to use function
>like strcmp() which again compare byte by byte in the above example and
>give true.

Yes, indeed.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OT: excellent book on information theory

[Dave Hansen]

On Thu, 19 Jan 2006 15:04:51 +0100 in comp.lang.python, Mikael
Olofsson <[EMAIL PROTECTED]> wrote:

>Terry Hancock wrote:
>"Tim Peters" <[EMAIL PROTECTED]> wrote:
>>>   UK:Harry smiled vaguely back
>>>   US:Harry smiled back vaguely
>
>Terry Hancock wrote:
>> I know you are pointing out the triviality of this, since
>> both US and UK English allow either placement -- but is it
>> really preferred style in the UK to put the adverb right
>> before the verb?  In US English, the end of the clause
>> (or the beginning) is probably more common.

Indeed, the UK version (stripped of context) means something
completely different than the US ("vaguely" modifies "back" rather
than "smiled.").  At least, to this American.

>
>I appreciate your desire to put the thread on (Python) topic, but as I 
>see this discussion, it really has to do with respect for the author, 
>but also respect for the reader. The UK version is most likely the way 
>the author intended it to be. Then that is the way the text should be, 
>regardless if it is preferred style or not, under the assumption that 
>English is English is English.
>

I've not read any of the books, but from the critiques I've read,
Rowling's skills as a writer in no way match (and indeed, often
interfere with) her gifts as a storyteller.

Sometimes a writer needs an editor.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can a simple a==b 'hang' in and endless loop?

[Dave Hansen]

On Thu, 19 Jan 2006 08:06:50 +0100 in comp.lang.python, "Fredrik
Lundh" <[EMAIL PROTECTED]> wrote:

>Dave Hansen wrote:
>

[EMAIL PROTECTED] wrote]

>> >Fuzzyman wrote:
[...]
>> >> In this case :
>> >>
>> >> a = ['some string']
>> >> b = ['somestring']
>> >> a == b
>> >> False (probably)
>> >That depends, the C syntax is like this :
>> >
>> >char *a="hello";
>> >char *b="hello";
>> >
>> >assert(a==b);
>> >
>> >// true, the compiler knows the two hello are the same and assign the
>> >same address(sort of id() in python) to a and b
>>
>> No. The C standard says the compiler is _allowed_ to re-use character
>> literal constants, but is not _required_ to do so.
>
>I could have sworn that fuzzyman's example contained a literal string in
>an array, and an array comparision, so why are you talking about com-
>paring string literals ?   a compiler for which

I was responding to bonono's example, not fuzzyman's.  Perhaps a more
appropriate response would have been that his example (besides being
incorrect) didn't match the situation under consideration.

>
>char* a[] = { "some string" };
>char* b[] = { "some string" };
>
>...
>
>if (a == b)
>printf("True\n");
>
>prints True is definitely broken.

Definitely.  However,

   if (a[0] == b[0])
  puts("True");

May or may not print "True."  Either answer is allowed.  In C.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: New Python.org website?

[Dave Hansen]

On Thu, 19 Jan 2006 11:58:27 -0600 in comp.lang.python, Terry Hancock
<[EMAIL PROTECTED]> wrote:

[...]
>At worst, the cross might be a reference to "The Spanish
>Inquisition", which anyone who knows anything about Python
>should know is topical.  

Perhaps, but they wouldn't expect it...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python code written in 1998, how to improve/change it?

[Dave Hansen]

On Fri, 20 Jan 2006 10:27:58 +1300 in comp.lang.python, Carl Cerecke
<[EMAIL PROTECTED]> wrote:

[...]
>
>Python has no goto.

+1

[...]
>
>We want a goto.

-1

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Restricted Access

[Dave Hansen]

On 11 Jul 2006 10:19:22 -0700 in comp.lang.python, Paul Rubin
 wrote:

>"K.S.Sreeram" <[EMAIL PROTECTED]> writes:
>> Java is not the only restricted execution environment around.
>> Javascript, as implemented by most browsers, is an excellent lightweight
>> restricted execution environment, and there are many browsers which have
>> good implementations.
>
>And we hear about browser security bugs all the time, for which the
>workaround is "shut off javascript".

And Java...

Regards,

-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: stderr, stdout, and errno 24

[Dave Hansen]

On 12 Jul 2006 18:09:42 -0700 in comp.lang.python, "Wesley Henwood"
<[EMAIL PROTECTED]> wrote:

>To capture output from python scripts run from a C++ app I've added the
>following code at the beggening of the C++ app:
>
>PyRun_SimpleString("import grabber");
>PyRun_SimpleString("import sys");
>PyRun_SimpleString("class a:\n\tdef
>write(self,s):\n\t\tograbber.grab(s)\n");
>PyRun_SimpleString("import sys\nsys.stderr=a()\nsys.stdout=a()");
>
>Its hard to read that way, here's what it expands to:
>import grabber
>import sys
>class a:
>def write(self, s)
>grabber.grab(s)

Actually, that last line will more like
>ograbber.grab(s)

At least, if what you posted above is accurate...

It's not the question you asked, but if you want to make that easier
to read, you can do something like

   PyRun_SimpleString("import grabber");
   PyRun_SimpleString("import sys");

   PyRun_SimpleString("class a:\n"
  "   def write(self,s):\n"
  "  grabber.grab(s)\n");

   PyRun_SimpleString("import sys\n"
  "sys.stderr=a()\n"
  "sys.stdout=a()\n");


C++, like Python, will concatenate strings seperated only by
whitespace.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Coding style

[Dave Hansen]

On Mon, 17 Jul 2006 17:09:32 +0100 in comp.lang.python, "Simon
Brunning" <[EMAIL PROTECTED]> wrote:

[...]
>
>lst = [1,2,3,4,5]
>while lst:
>lst.pop()
>
>Or even just:
>
>lst = []
>

 del lst[:]

is probably closer to what the OP wants...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Isn't there a better way?

[Dave Hansen]

On 21 Jul 2006 07:51:15 -0700 in comp.lang.python, "T"
<[EMAIL PROTECTED]> wrote:

>
>I am using an optparse to get command line options, and then pass them
>to an instance of another class:
>
>
>
># Class that uses optparse.OptionParser
>foo = Parse_Option()
>
># Class that does the real work
>bar = Processor()
>
>bar.index = foo.options.index
>bar.output  = foo.options.output
>bar.run()


How about

   class Processor(whatever):
  ...
  def __init__(self,whatever_else):
  ...
  self.op = Parse_Option()

   ...
   bar = Processor()
   bar.run()

This would even let you do some preliminary option processing during
object initialization.

Regards,

   
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a good programming text editor (not IDE)

[Dave Hansen]

On Thu, 15 Jun 2006 17:12:26 GMT in comp.lang.python, John Salerno
<[EMAIL PROTECTED]> wrote:

>I know there's a request for a good IDE at least once a week on the ng, 
>but hopefully this question is a little different. I'm looking for 
>suggestions for a good cross-platform text editor (which the features 
>for coding, such as syntax highlighting, etc.) but not a full IDE with 
>all the fancy jazz (GUI developer, UML diagrams, etc.).
>
>Ideally, it would be something I could even put on a flash drive and 
>move from computer to computer, but this isn't necessary. Just something 
>I can immediately use in either Windows or Linux (or Mac, if necessary).

Very small, very fast, very powerful, and very portable (though I'm
not sure about Mac...): Take a look at Jed from www.jedsoft.org.

You might not find it pretty, however...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Dave Hansen]

On Tue, 24 Jan 2006 16:33:16 +0200 in comp.lang.python, Juho Schultz
<[EMAIL PROTECTED]> wrote:

[...]
>
>Fortran 90 allowed >, >= instead of .GT., .GE. of Fortran 77. But F90 
>uses ! as comment symbol and therefore need /= instead of != for 
>inequality. I guess just because they wanted. However, it is one more 
>needless detail to remember. Same with the suggested operators.

C uses ! as a unary logical "not" operator, so != for "not equal" just
seems to follow, um, logically.

Pascal used <>, which intuitively (to me, anyway ;-) read "less than
or greater than," i.e., "not equal."  Perl programmers might see a
spaceship.

Modula-2 used # for "not equal."  I guess that wouldn't work well in
Python...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Dave Hansen]

On Tue, 24 Jan 2006 04:09:00 +0100 in comp.lang.python, Christoph
Zwerschke <[EMAIL PROTECTED]> wrote:

[...]
>Once you open your mind for using non-ascii symbols, I'm sure one can 
>find a bunch of useful applications. Variable names could be allowed to 
>be non-ascii, as in XML. Think class names in Arabian... Or you could 
>use Greek letters if you run out of one-letter variable names, just as 
>Mathematicians do. Would this be desirable or rather a horror scenario? 

The latter, IMHO.  Especially variable names.  Consider i vs. ì vs. í
vs. î vs. ï vs. ...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a 32 bit number to integer

[Dave Hansen]

On Tue, 24 Jan 2006 13:23:05 -0300 in comp.lang.python, Ricardo
Quesada <[EMAIL PROTECTED]> wrote:

>Hi,
>
>  In python 2.0, this number was an integer:
>0x88776655
>
>  but in python 2.4 it is a long (every number > 0x7fff it is a long)
>
>in python 2.4, is there a way to convert that number to a integer 
>(notice that it only occupies 32 bits) ?

Well, the sign bit's gonna be set no matter what.  But the following
might work for you...

>>> def short(x):
return int(0x8000 - x)


>>> x = short(0x88776655)
>>> x
-142042709
>>> "%x"%x
'-8776655'
>>> 

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Dave Hansen]

On Tue, 24 Jan 2006 19:44:28 +0100 in comp.lang.python, Christoph
Zwerschke <[EMAIL PROTECTED]> wrote:

>Dave Hansen wrote:
>> C uses ! as a unary logical "not" operator, so != for "not equal" just
>> seems to follow, um, logically.
>
>Consequently, C should have used !> for <= and !< for >= ...

Well, actually, no.

"Less (than) or equal" is <=.  "Greater (than) or equal" is >=.  "Not
equal" is !=. 

If you want to write code for the IOCCC, you could use !(a>b) instead
of a<=b...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Dave Hansen]

On Wed, 25 Jan 2006 08:26:16 +1100 in comp.lang.python, Steven
D'Aprano <[EMAIL PROTECTED]> wrote:

>On Tue, 24 Jan 2006 10:38:56 -0600, Dave Hansen wrote:
>
>> The latter, IMHO.  Especially variable names.  Consider i vs. ì vs. í
>> vs. î vs. ï vs. ...
>
>Agreed, but that's the programmer's fault for choosing stupid variable
>names. (One character names are almost always a bad idea. Names which can
>be easily misread are always a bad idea.) Consider how easy it is to

I wasn't necessarily expecting single-character names.  Indeed, the
different between i and ì is easier to see than the difference
between, say, long_variable_name and long_varìable_name.  For me,
anyway.

>shoot yourself in the foot with plain ASCII:
>
>
>l1 = 0
>l2 = 4
>...
>pages of code
>...
>assert 11 + l2 = 4

You've shot yourself twice, there.  Python would tell you about the
second error, though.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Creating a more random int?

[Dave Hansen]

On Wed, 25 Jan 2006 15:21:43 - in comp.lang.python, Grant Edwards
<[EMAIL PROTECTED]> wrote:

>On 2006-01-25, Magnus Lycka <[EMAIL PROTECTED]> wrote:
>
>> P.S. Since I was a kid, I've heard people say: So you're born
>> on new years day--how unusual.
>
>Well, it happens to slightly less than 1/365th of the
>population[1], so it is rather unusual.  Of course it's no more
>unusal that being born on June 19th or November 3rd or any
>other date you choose...
>
>[1] Assuming birth dates are uniformly distributed.  Which the
>probably aren't in countries where a significant portion of
>the population schedules births to fit the hospital/doctors
>schedule.

Google "birthday paradox" for a little OT fun.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float formatting

[Dave Hansen]

On 25 Jan 2006 11:32:27 -0800 in comp.lang.python, "Brian"
<[EMAIL PROTECTED]> wrote:

>Hello all,
>
>I am a bit stuck with a float formatting issue.  What I want to do is
>print a float to the screen with each line showing one more decimal
>place.  Here is a code snip that may explain it better:
>
>#!/usr/bin/env python
>
>num1 = 32
>num2 = 42.98765
>
>for i in range(2,7):
>   print "|" + "%10.3f" % num2 + "|"
>
>In the for loop, is the line with my difficulty.  In a perfect world it
>would read something like this:
>
>for i in range(2,7):
>print "|" + "%10.if" % num2 + "|"  #where i would be the iteration
>and the num of decimal places
>

Try something like this

>>> num2 = 42.98765
>>> for i in range(2,7):
print "|" + "%10.*f"%(i,num2) + "|"


| 42.99|
|42.988|
|   42.9877|
|  42.98765|
| 42.987650|
>>> 

HTH,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pulling numbers from ASCII filename not working

[Dave Hansen]

On Thu, 26 Jan 2006 06:39:20 GMT in comp.lang.python, Dennis Lee
Bieber <[EMAIL PROTECTED]> wrote:

>On 25 Jan 2006 12:42:20 -0800, "IamIan" <[EMAIL PROTECTED]> declaimed the
>following in comp.lang.python:
[...]
>> I tried print repr(filename) and it returned the actual filename:
>> 'n16w099.asc' , 'n17w062.asc' , etc.
>
>   You may have problems with the longitude... those leading zeroes may
>be taken as Octal notation...

Shouldn't be a problem unless you make it one.  Int defaults to
decimal, unless you specify a base or tell it to infer the base from
the number format by specifying a base of zero.

   >>> a = int("062")
   >>> a
   62
   >>> a = int("062",0)
   >>> a
   50

Hard to interpret "099" as an octal number in any case:

   >>> a = int("099",0)

   Traceback (most recent call last):
 File "", line 1, in -toplevel-
   a = int("099",0)
   ValueError: invalid literal for int(): 099
   >>> 

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Match First Sequence in Regular Expression?

[Dave Hansen]

On Thu, 26 Jan 2006 16:26:57 GMT in comp.lang.python, "Roger L.
Cauvin" <[EMAIL PROTECTED]> wrote:

>"Christos Georgiou" <[EMAIL PROTECTED]> wrote in message 
>news:[EMAIL PROTECTED]
[...]
>> Is this what you mean?
>>
>> ^[^a]*(a{3})(?:[^a].*)?$
>
>Close, but the pattern should allow "arbitrary sequence of characters" that 
>precede the alternating a's and b's to contain the letter 'a'.  In other 
>words, the pattern should accept:
>
>"xayz123aaabbab"
>
>since the 'a' between the 'x' and 'y' is not directly followed by a 'b'.
>

I don't know an RE is the best solution to this problem.  If I
understand the problem correctly, building a state machine to solve
this is trivial.  The following took about 5 minutes of coding:

---begin included file
# Define our states.  
#   state[0] is next state if character is 'a'
#   state[1] is next state if character is 'b'
#   state[2] is next state for any other character

# Accept state means we've found a match
Accept = []
for i in range(3):
Accept.append(Accept)

# Reject state means the string cannot match
Reject = []
for i in range(3):
Reject.append(Reject)

# Remaining states: Start, 'a' found, 'aa', 'aaa', and ''
Start = [0,1,2]
a1 = [0,1,2]
a2 = [0,1,2]
a3 = [0,1,2]
a4 = [0,1,2]

# Start: looking for first 'a'
Start[0] = a1
Start[1] = Start
Start[2] = Start

# a1: 1 'a' found so far
a1[0] = a2
a1[1] = Reject
a1[2] = Start

# a2: 'aa' found
a2[0] = a3
a2[1] = Reject
a2[2] = Start

# a3: 'aaa' found
a3[0] = a4
a3[1] = Accept
a3[2] = Start

# a4: four or more 'a' in a row
a4[0] = a4
a4[1] = Reject
a4[2] = Start

def detect(s):
"""
Return 1 if first substring aa*b has exactly 3 a's
Return 0 otherwise
"""
state = Start
for c in s:
if c == 'a':
state = state[0]
elif c == 'b':
state = state[1]
else:
state = state[2]
if state is Accept:
return 1
return 0

print detect("xyza123abc")
print detect("xyzaaa123aabc")
print detect("xyzaa123aaabc")
print detect("xyza123bc")

--- end included file ---

And I'm pretty sure it does what you need, though it's pretty naive.
Note that if '3' isn't a magic number, states a1, a2, a3, and a4 could
be re-implemented as a single state with a counter, but the logic
inside detect gets a little hairier.

I haven't timed it, but it's not doing anything other than simple
comparisons and assignments.  It's a little (OK, a lot) more code than
a simple RE, but I know it works.

HTH,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: beta.python.org content

[Dave Hansen]

On Thu, 26 Jan 2006 15:28:50 -0800 in comp.lang.python, James Stroud
<[EMAIL PROTECTED]> wrote:

>Rocco Moretti wrote:
>> (Not that I like the logo, mind you...)
>
>Does anyone? There has to be a better logo! I thought the previous 
>requirement as established by the BDFL was no snakes. These are snakes, 
>and they have no personality to boot.

I like it, FWIW.  Better than a dead parrot or a killer rabbit IMHO.
Though maybe not as funny...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Dave Hansen]

Just a couple half-serious responses to your comment...

On Fri, 27 Jan 2006 11:05:15 +0100 in comp.lang.python, Magnus Lycka
<[EMAIL PROTECTED]> wrote:

>Terry Hancock wrote:
>> That's interesting. I think many people in the West tend to
>> imagine han/kanji characters as archaisms that will
>> disappear (because to most Westerners they seem impossibly
>> complex to learn and use, "not suited for the modern
>> world"). 
>I don't know about "the West". Isn't it more typical for the
>US that people believe that "everybody really wants to be like
>us". Here in Sweden, *we* obviously want to be like you, even
>if we don't admit it openly, but we don't suffer from the
>misconception that this applies to all of the world. ;)

1) Actually, we don't think "everyone wants to be like us."  More like
"anyone who doesn't want to be like us is weird."

2) This extends to our own fellow citizens.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Dave Hansen]

On Fri, 27 Jan 2006 08:11:24 GMT in comp.lang.python, [EMAIL PROTECTED]
(Bengt Richter) wrote:

[...]
>Maybe you would like the unambiguousness of
>(+ 8 (* 6 2))
>or
>6 2 * 8 +
>?

Well, I do like lisp and Forth, but would prefer Python to remain
Python.

Though it's hard to fit Python into 1k on an 8-bit mocrocontroller...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: beta.python.org content

[Dave Hansen]

On Fri, 27 Jan 2006 13:33:06 + in comp.lang.python, Steve Holden
<[EMAIL PROTECTED]> wrote:

>Shalabh Chaturvedi wrote:
[...]
>
>> 2. "also available as the python-list mailing list"
>> 
>> Add "or a google group (link)".

It's not a "Google Group," it's a Usenet newsgroup.  Google merely
provides a lousy but accessible interface to Usenet.

>> 
>Gimme the link!

http://groups.google.com/group/comp.lang.python

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Dave Hansen]

On Fri, 27 Jan 2006 20:27:40 -0500 in comp.lang.python, Dan Sommers
<[EMAIL PROTECTED]> wrote:

>On Fri, 27 Jan 2006 22:29:20 GMT,
>Neil Hodgson <[EMAIL PROTECTED]> wrote:
>
>> ... I'm so used to "/" for division that "÷" now looks strange.

Indeed, I don't think I've used ÷ for division since about 7th grade,
when I first started taking Algebra (over 30 years ago).

>
>Strange, indeed, and too close to + for me (at least within my
>newsreader).
>

FWIW, it looks closer to - than + in mine.  And as you say, _too_
close.  IMHO.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Intro to Pyparsing" Article at ONLamp

[Dave Hansen]

On Mon, 30 Jan 2006 16:39:51 -0500 in comp.lang.python, Peter Hansen
<[EMAIL PROTECTED]> wrote:

>Christopher Subich wrote:
>> Using English, because that's the only language I'm fluent in, consider 
>> the sentence:
>> 
>> "The horse raced past the barn fell."
>> 
>> It's just one of many "garden path sentences," where something that 
>> occurs late in the sentence needs to trigger a reparse of the entire 
>> sentence.  
>
>I can't parse that at all.  Are you sure it's correct?  Aren't "raced" 
>and "fell" both trying to be verbs on the same subject?  English surely 
>doesn't allow that forbids that sort of thing. ()

I had a heck of a time myself.  Try "The horse that was raced..." and
see if it doesn't make more sense.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is there a better way?

[Dave Hansen]

On Sat, 11 Feb 2006 01:37:59 +0100 in comp.lang.python, Schüle Daniel
<[EMAIL PROTECTED]> wrote:

>Lonnie Princehouse wrote:
>> everybody is making this way more complicated than it needs to be.
>> 
>> storage = list[:list.index(O)]
>
>the question is whether the old list is needed in the future or not
>if not then it would be easer/mor efficient to use
>
>del lst[lst.index(0):]

And you're both forgetting the list can end with X.  the index method
raises a ValueError exception if the desired value is not found in the
list.  Assuming you want to keep the original list and create a new
list called storage, you could try

   if lst[-1] == X:
  storage = lst[:]
   else:
  storage = lst[:lst.index(O)]

or even

   try:
  storage = lst[:lst.index(O)]
   except ValueError:
  storage = lst[:]

(WARNING: untested!)

Regards,


   
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: simple math question

[Dave Hansen]

On Sat, 11 Feb 2006 16:43:33 -0500 in comp.lang.python, John Salerno
<[EMAIL PROTECTED]> wrote:

>John Salerno wrote:
>> Hi all. I'm just starting out with Python, so I'm a little slow right 
>> now. :)
>> 
>> Can someone explain to me why the expression 5 / -2 evaluates to -3, 
>> especially considering that -2 * -3 evaluates to 6?
>> 
>> I'm sure it has something to do with the negative number and the current 
>> way that the / operator is implemented, but why doesn't it evaluate to 
>> -2 instead?
>
>Thanks for the help guys! It's clearer to me now, and I think I was just 
>conceptualizing it the wrong way in the first place.

Probably not the "wrong" way, just a different way, especially if you
write C code.  

The C standard defines integer division as (something like) "the
integer part of the result, throwing away the fraction," which would
get you the value you expect.  

This also means the sign of the result of the C % operator matches the
sign of the numerator.  In Python, the sign matches the sign of the
denominator.

You could also describe the C scheme as "truncating towards zero."
Python (and my HP calculator) "truncates toward negative infinity."  I
suppose a third way to do it would be to "truncate towards positive
infinity," but I don't know of any concrete examples of this.  'Twould
seem counter-intuitive in any case...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how do you pronounce 'tuple'?

[Dave Hansen]

On Sun, 12 Feb 2006 23:30:25 -0500 in comp.lang.python, Steve Holden
<[EMAIL PROTECTED]> wrote:

>John Salerno wrote:
[...]
>
>> I know it comes from the suffix -tuple, which makes me think it's 
>> pronounced as 'toople', but I've seen (at m-w.com) that the first 
>> pronunciation option is 'tuhple', so I wasn't sure. Maybe it's both, but 
>> which is most prevalent?
[...]
>"Tyoople", "toople" or "tupple" depending on who you are, where you grew 
>up and who you are speaking to. As with so many Usenet questions, 
>there's no right answer, only 314 wrong ones :-)

FWIW, I've often heard the latter two, but never the first one.
"Tuple" by itself tends to be "toople," but as a suffix tends to be
"tupple."

>
>I teach on both sides of the Atlantic, and have learned to draw a mental 
>breath before trying to pronounce the word "router". Americans find the 
>British pronunciation ("rooter") hilarious, despite the fact they tell 

Probably a cultural reference to "Roto-Rooter," a nationwide plumbing
company specializing in cleaning (ostensibly tree and other plant
roots, though often more, uh, prozaic materials), from sewer drains.
"Call Roto-Rooter, that's the name, and away go troubles down the
drain."

>me I drive on "Root 66" to get to DC. The Brits are politer, and only 
>snigger behind my back when I pronounce it as Americans do, to rhyme 
>with "outer".

I've seen "route" pronounced "rout" or "root" depending on the
background and mood of the speaker, though in this part of the country
("midwest", though "middle" might be more accurate) the former
pronunciation is far more common.  Through the sugestive power of
television, however, I suspect nearly every American would speak of
"root 66" even though the next sentence might reference "rout 12."

On NPR ([American] National Public Radio), there's a weekly music
program called "American Routes" pronounced such to conjure the
alternate "American Roots."

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how do you pronounce 'tuple'?

[Dave Hansen]

On Mon, 13 Feb 2006 22:30:43 +0100 in comp.lang.python, Peter Maas
<[EMAIL PROTECTED]> wrote:

>John Salerno schrieb:
>> Terry Hancock wrote:
>> 
>>> So what's a 1-element tuple, anyway? A "mople"?  "monople"?
>>> It does seem like this lopsided pythonic creature (1,) ought
>>> to have a name to reflect its ugly, newbie-unfriendly
>>> nature.
>>>
>>> Are we having fun yet? ;-)
>> 
>> I kind of like 'moople'.  :)
>
>tuples are of latin origin, so one can derive the tuple words
>systematically:
>
>Latin n-tuple
>---
>...   ...
>triplex   triple
>duplexduple
>simplex   simple

When I was in 4th grade, I was taught to count to ten in latin: unos,
duos, trace, quatro, quinque, sex, septem, octem, novem, decem
(assuming the intervening 35 years haven't dimmed my memory too
much...).  This would suggest "untuple" (or one of several
contractions such as "unuple" or "uple").

Though I suspect "single" is correct.  Consider coronary bypass
operations -- single, double, triple, quadruple...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how do you pronounce 'tuple'?

[Dave Hansen]

On Mon, 13 Feb 2006 16:46:26 -0500 in comp.lang.python, Steve Holden
<[EMAIL PROTECTED]> wrote:

>Dave Hansen wrote:
>> On Sun, 12 Feb 2006 23:30:25 -0500 in comp.lang.python, Steve Holden
>> <[EMAIL PROTECTED]> wrote:
[...]
>> 
>>>"Tyoople", "toople" or "tupple" depending on who you are, where you grew 
>>>up and who you are speaking to. As with so many Usenet questions, 
>>>there's no right answer, only 314 wrong ones :-)
>> 
>> 
>> FWIW, I've often heard the latter two, but never the first one.
>> "Tuple" by itself tends to be "toople," but as a suffix tends to be
>> "tupple."
>> 
>No, but then you probably listen to the noos, not the nyoos, on the TV 
>or radio. That's a particularly British pronunciation.

I have heard that pronunciation of "news," and not just from the
British.  Back in the mid-1980's I listened to a radio station with a
DJ who, in an attempt at humor, would prefix his news segments with a
nasal "And now, the nYoos!" with the first part of the Y heavily
stressed and about an octave higher in pitch than either end of the
word.  He wasn't trying to sound British, just mock-enthusiastic.

[...]
>> On NPR ([American] National Public Radio), there's a weekly music
>> program called "American Routes" pronounced such to conjure the
>> alternate "American Roots."
>> 
>Never caught that. Must go get some batteries for my radio.

If you're interested, see http://www.americanroutes.org/

Their station list includes some who broadcast over the web.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: invert the order of a string

[Dave Hansen]

On Mon, 13 Feb 2006 18:51:11 + in comp.lang.python, rtilley
<[EMAIL PROTECTED]> wrote:

>s = list('some_random_string')
>print s
>s.reverse()
>print s
>s = ''.join(s)
>print s
>
>Surely there's a better way to do this, right?

How about 

s = "some random string"
print s
s = s[::-1]
print s

HTH,
   -=Dave
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: invert the order of a string

[Dave Hansen]

On Mon, 13 Feb 2006 19:03:32 + in comp.lang.python, rtilley
<[EMAIL PROTECTED]> wrote:

>Dave Hansen wrote:
>> How about 
>> 
>> s = "some random string"
>> print s
>> s = s[::-1]
>> print s
>
>That looks like Perl, but it works. Makes me wonder with the string 
>module doesn't have a reverse or invert function?

It's just simple slicing.  Well, maybe not so simple, or at least not
so common, but with a syntax similar to the range function.  Consider
the following (string chosen to make it obvious what's going on):

s = "0123456789"
s[::]
s[3::]
s[:3:]
s[::3]
s[::-2]
s[-2::-2]

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: processing limitation in Python

[Dave Hansen]

On 14 Feb 2006 08:42:38 -0800 in comp.lang.python, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:

>If I un-comment any line in this program below the line where I
>commented " all OK up to this point " This program locks up my
>computer.

Hmm.  Ctrl-C gets me out just fine.  In Idle, at least.

>
>Windows task manager will show "Not Responding" for Python in the
>Applications tab and in the Performance tabe the CPU usage will be
>locked at %100.

Well sure.  It's pretty busy code.

>
>I've experienced the same problem on 2 different computers, one running
>2000 pro. the other running XP home eddition.  both computers run
>Python 2.4.2
>
>I'm just wondering if any one else has noticed any problems with
>working with large numbers in Python ind if there is anything that can
>work around this issue.

Try running with the changes I've made below, and see if that tells
you anything.

def factor(n):
d = 2
pctr = 0
factors = [ ]
while n > 1:
if n % d == 0:
factors.append(d)
n = n/d
else:
d = d + 1
pctr += 1
if pctr >= 100:
print "So Far: " + str(factors)
pctr = 0
print factors
factor (12)
factor (123)
factor (1234)
factor (12345)
factor (123456)
factor (1234567)
factor (12345678)
factor (123456789)
factor (1234567898)
factor (12345678987)
factor (123456789876)
factor (1234567898765)   # all OK up to this point
factor (12345678987654)# locks up computer if I run this line
#factor (123456789876543)
#factor (1234567898765432)
#factor (12345678987654321)


Hint: 2057613164609L is a Really Big Number (tm).  If it's prime (I
don't know if it is or not), it will take more than 46 days on my
computer to figure that out.  Did you wait that long?

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Merging two lists of data (Pythonic way)

[Dave Hansen]

On Thu, 16 Feb 2006 12:51:24 -0800 in comp.lang.python, "SMB"
<[EMAIL PROTECTED]> wrote:

>
>"Jonathan Gardner" <[EMAIL PROTECTED]> wrote in message 
>news:[EMAIL PROTECTED]
>> codes = map(lambda x: x[0], list1)
>> for d in list2:
>>  if d['code'] in codes:
>>d['VERIFIED'] = 1
>>
>> Is this what you were looking for?
>>
>
>That is exactly what I was looking for.  I will have to take a look at map.

You might also look at list comprehensions.  Replacing the first line
in the above with

   codes = [x[0] for x in list1]

should yield the same result.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3000 deat !? Is true division ever coming ?

[Dave Hansen]

Caution: bunny trail ahead.  Feel free to skip this message, as it
contains no useful content whatever...

On Sat, 18 Feb 2006 12:09:02 +1100 in comp.lang.python, Steven
D'Aprano <[EMAIL PROTECTED]> wrote:

[...]
>
>I've never even used Matlab. But I have a calculator. (Actually I have
>about half a dozen calculators.) In every single one of them, 1/2 gives
>0.5 instead of 0. I'm even capable of doing that calculation in my head.
>So I don't think true division is only in Matlab.

I have three calculators: an HP-48S, and HP-16C, and NeoCal on my
Palm.

On the HP-48S: 1  2 / -> 500.0E-3
On the HP-16C: 1  2 / -> 0 h (c)
On NeoCal: 1  2 / -> 500.e-3

Note: the (c) on the 16C indicates the "carry" bit was set, which the
16C does whenever the remainder of a division is nonzero.

Caveats: The result for each calculator depends on its "mode."  In
"programmer" mode, each calculator performs a truncating integer
division.  The 16C is in programmer mode by default.  The 48S is
almost never in programmer mode since I bought the 16C.  NeoCal goes
into programmer mode about 25% of the time I use it.  It was in
"Statistics" mode when I powered it up just now.

>
>
>> As you pointed out: the "true division" part of "Python3000" might be
>> one of the "scariest" and should therefore be pointed out already in
>> the tutorial !!  (It would look quite ugly to newcomers, though)

If you want ugly, consider Pascal.  The / operator could not perform
an integer divide, and a compile-time error was generated if you
attempted to use it with integer operands.  The integer divide
operator was 'div', e.g. "i = j div k"

>
>The tutorial shouldn't talk about Python3000 at all. What would be the
>point of that? The tutorial is there to teach about the way Python works
>now, not to make guesses and prediction about how it will work some time
>in the indefinite future.
>
>
>> Having said that:  I would vote against EVER introducing true division
>> as default - because it will just PISS too many (long time python)
>> people OFF. ;-)
>
>Do you realise that the reason true division was introduced into Python
>was because many long-time Python programmers requested it? So far from
>annoying them, it is a feature that most Python programmers are waiting
>for.

I am a relatively long-time user (since about 1999) of Python, but I
mainly program in C.  "True" division probably wouldn't p*ss me off
too bad, and I certainly wouldn't have a problem with new scripts I
wrote.  But if it broke old scripts, I wouldn't be extremely happy.

FWIW, ISTM that "true" division would be better implemented by the new
// operator, leaving the behavior of / unchanged.  But that's probably
just me.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Mutable numbers

[Dave Hansen]

On Tue, 21 Feb 2006 12:44:52 +0530 in comp.lang.python, Suresh
Jeevanandam <[EMAIL PROTECTED]> wrote:

># I am new to python.
>
>In python all numbers are immutable. This means there is one object ( a 
>region in the memory ) created every time we do an numeric operation. I 
>hope there should have been some good reasons why it was designed this way.
>
>But why not have mutable numbers also in the language. A type which 
>would behave as follows:
>
>a = MutableInt(12)

a = [12]

>b = a
>
>Now both a and b should refer to the same memory location. Any change in 
>the object should get reflected in all the references.
>
>a.assign(13) # Same memory location should be updated with value 13, b 

a[0] = 13

>is also 13 now.
>
>Now we can further optimize:
>
>a.incrementOne() # equivalent to a++ in C++
>a.decrementOne()

a[0] += 1
a[0] -= 1

>
>and the augmented assignment operation also could be made optimized.
>
>In any application most of the operation is numerical. So, i think, we 
>should get a good speed advantage with the availability of mutable 
>numbers. What do you think ?

I don't see how.

HTH,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Dave Hansen]

On Tue, 21 Feb 2006 08:36:50 -0600 in comp.lang.python, "Chris Mellon"
<[EMAIL PROTECTED]> wrote:

[...]
>
>When asked to name some interpreted (or scripting) languages, they'll
>name some off - perl, python, ruby, javascript, basic...
>
>They won't say Java. Ask them why Python is interpreted and Java isn't
>and you'll have a hard time getting a decent technical answer, because
>Python isn't all that different from Java in that regard, especially
>pre-JIT versions of Java.

IMHO, it's marketing.  Soon after (as soon as?) Sun introduced Java,
they announced microprocessors that would implement the JVM natively.
Thus on those machines, Java would not be "interpreted."

AIUI, the reason native Java chips never took off is 1) limited
utility (who wants a chip that can only run Java programs?), and 2)
performance on native chips wasn't even better than JVMs running on
commodity microprocessors, so what's the point?

>
>Probably the most accurate definition of "interpreted" as it is used
>in the wild is "one of these languages: perl, python, perl, ruby,
>etc". That is, you're essentially claiming that Python is interpreted
>because everyone thinks of it that way, technical correctness be
>damned.

I think another reason "perl, Python etc." are known to be interpreted
and Java is not is the interactivity afforded by former group.  This
is also why, e.g., lisp and Forth are thought of as interpreted (at
least by those with only a passing familiarity with the languages),
though native compilers for both languages are readily available.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A C-like if statement

[Dave Hansen]

On Thu, 23 Feb 2006 12:04:38 -0700 in comp.lang.python, "Bob Greschke"
<[EMAIL PROTECTED]> wrote:

>
>"Roy Smith" <[EMAIL PROTECTED]> wrote in message 
>news:[EMAIL PROTECTED]
[...]

>> try:
>>i = a.find("3")
>>print "It's here: ", i
>> except NotFound:
>>print "No 3's here"
>
>Nuts.  I guess you're right.  It wouldn't be proper.  Things are added or 
>proposed every day for Python that I can't even pronounce, but a simple 'if 
>(I = a.find("3")) != -1' isn't allowed.  Huh.  It might be time to go back 
>to BASIC. :)

I think you'll find that BASIC doesn't allow it either...

Of the "missing" "features" of Python, this one is waay down on my
list.  In fact, it's not there at all.  What I _really_ miss is
do{...}while.  The best workaround I've found is unaesthetic, IMHO:

   while 1:
  # stuff
  if exit_condition: break

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How would you open this file?

[Dave Hansen]

On Thu, 23 Feb 2006 18:01:32 -0500 in comp.lang.python, Kent Johnson
<[EMAIL PROTECTED]> wrote:

[...]
>
>filename = open_file()
>
>By the way 'filename' is a pretty bad name, since it contains a file 
>object, not a string. Maybe call it f instead. ('file' is also a bad 
>name because it is the name of a Python built-in function.)

I write a lot of simple scripts.  Those that have input and/or output
files tend to call them infile and outfile.  Given the name of the
OP's file, perhaps optfile would work for him...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs

[Dave Hansen]

On Jun 20, 8:28 am, David Kastrup <[EMAIL PROTECTED]> wrote:
> Actually, the "E" in "Emacs" stands for "extensible".  Part of the
> appeal of Emacs is that you can change it to accommodate you.

Actually, though Emacs is the epitome of extensibility, the "E" stands
for "Editor."  "EMACS" is simply short for Editor MACroS, and was
originally implemented as a set of TECO macros.

There's also the joke that EMACS stands for Esc Meta Alt Ctrl Shift,
due to it's (often overwhelmingly) large and sometimes complex set of
keystroke combinations used to invoke various editing functions.  This
view is usually put forth by the vi camp during editor wars.

Speaking of which, vi is a piece of wombat do.  ;-)

Regards,

   -=Dave

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs

[Dave Hansen]

On Jun 21, 9:49 am, Robert Uhl <[EMAIL PROTECTED]> wrote:
> Twisted <[EMAIL PROTECTED]> writes:
>
> > Given that in its out-of-the-box configuration it's well-nigh unusable
> > without a printed-out "cheat sheet" of some kind, of the sort that
> > were supposed to have died out in the 80s, getting it customized poses
> > something of a catch-22 for anyone trying to get started using it.
>
> I don't see that.  C-h t is your friend if you're starting out.  The
> only keystrokes a user really needs to remember are C-x C-s and C-x C-c;
> everything else simple text editing needs works as expected (arrow keys,
> backspace and so forth).  Granted, text-mode is friendlier than

I'm not so sure C-h t is anybody's friend anymore.  Every version of
Emacs that I've used since 1984 has supported the arrow and page up/
down keys.  And every version of the tutorial that I've read (the
latest just a couple years back) insists on starting the user out with
C-f, C-b, C-p, C-n, C-V, and ESC-V, with some lame explanation like
"touch-typists shun the arrow and page keys, and besides, they might
not be supported on the next terminal you use."  Like ESC, I suppose.
Furrfu.

Regards,

   -=Dave

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggestions for how to approach this problem?

[Dave Hansen]

On May 8, 3:00 pm, John Salerno <[EMAIL PROTECTED]> wrote:
> Marc 'BlackJack' Rintsch wrote:
> > I think I have vague idea how the input looks like, but it would be
> > helpful if you show some example input and wanted output.
>
> Good idea. Here's what it looks like now:
>
> 1.  Levy, S.B. (1964)  Isologous interference with ultraviolet and X-ray
> irradiated
> bacteriophage T2.  J. Bacteriol. 87:1330-1338.
> 2.  Levy, S.B. and T. Watanabe (1966)  Mepacrine and transfer of R
> factor.  Lancet 2:1138.
> 3.  Takano, I., S. Sato, S.B. Levy and T. Watanabe (1966)  Episomic
> resistance factors in
> Enterobacteriaceae.  34.  The specific effects of the inhibitors of DNA
> synthesis on the
> transfer of R factor and F factor.  Med. Biol. (Tokyo)  73:79-83.

Questions:

1) Do the citation numbers always begin in column 1?

2) Are the citation numbers always followed by a period and then at
least one whitespace character?

If so, I'd probably use a regular expression like ^[0-9]+\.[ \t] to
find the beginning of each cite.  then I would output each cite
through a state machine that would reduce consecutive whitespace
characters (space, tab, newline) into a single character, separating
each cite with a newline.

Final formatting can be done with paragraph styles in Word.

HTH,
   -=Dave


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is PEP-8 a Code or More of a Guideline?

[Dave Hansen]

Apologies for jumping into the thread late.

On May 27, 3:25 pm, Roy Smith <[EMAIL PROTECTED]> wrote:
> Ben Finney <[EMAIL PROTECTED]> wrote:
> > Is C no longer a "major" language? The long-standing convention there
> > is for lower_case_with_underscores.
>
> Which dates back to the days of ASR-33's which only had one case (upper

The date is about right (actually, a little early: ASR-33, 1965; C,
about 1970), but you can't program C on an ASR-33.  Keywords are all
lower case, and always have been.  "IF" is a syntax error...

> case, as a matter of fact).  Does nobody else remember C compilers which
> accepted \( and \) for { and }?

I don't, but modern conforming compilers are supposed to accept ??< or
<% for { and ??> or %> for }.  Makes it awful hard to read, though,
IMHO.

Regards,

   -=Dave

P.S.  CamelCase sucks.  ;-)


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: regexp problem in Python

[Dave Hansen]

On Aug 3, 4:41 pm, Ehsan <[EMAIL PROTECTED]> wrote:
> I want to find "http://www.2shared.com/download/1716611/e2000f22/
[...]
> I use this pattern :
> "http.*?\.(wmv|3gp).*""
>
> but it returns only 'wmv' and '3gp' instead of "http://www.2shared.com/
> download/1716611/e2000f22/Jadeed_Mlak14.wmv?
> tsid=20070803-164051-9d637d11"
>
> what can I do? what's wrong whit this pattern? thanx for your comments

Just a guess, based on too little information: Try "(http.*?\.(wmv|
3gp).*)"

Regards,

   -=Dave

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbee Question

[Dave Hansen]

On Aug 21, 2:57 am, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
[...]
>
> pay = min(num, 22) * 0.4 + max(num-22, 0) * 1.4

   pay = num*0.4 + (num>22)*(num-22)

;-)

   -=Dave

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Car-ac-systems

[Dave Hansen]

On Sep 11, 12:42 pm, Zentrader <[EMAIL PROTECTED]> wrote:
> 
> What is it about "please do not top-post" that you have difficulty
> understanding? Or do "MVP"s feel that their time is so much more
> valuable than anyone else's that they are free to ignore the norms?
>
> Who made this the norm?

http://www.ietf.org/rfc/rfc1855.txt

If you don't know what the IETF is, or what an RFC is, you should
educate yourself.
http://www.ietf.org/glossary.html#IETF is a good place to start.

>   In my travels through web-land, it appears to

Usenet is not "web-land".  And it is not Google Groups, either.  Look
up
http://www.faqs.org/faqs/usenet/welcome/part1/ for more info

> be the opposite.  Don't waste space repeating everything in every
> post, and it wastes everyone's time by have to go over the same thing
> again and again.  Perhaps this thread has a purpose after all, anyway
> it has been reported as spam.

You have much to learn.

Regards,

   -=Dave

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: newbie: self.member syntax seems /really/ annoying

[Dave Hansen]

On Sep 12, 5:21 am, Charles Fox <[EMAIL PROTECTED]> wrote:
> I've just started playing around with Python, as a possible
> replacement for a mix of C++, Matlab and Lisp.  The language looks
> lovely and clean with one huge exception:  I do a lot of numerical
> modeling, so I deal with objects (like neurons) described
> mathematically in papers, by equations like
> a_dot = -k(a-u)
> In other languages, this translates nicely into code, but as far as I
> can tell, Python needs the ugly:
> self.a_dot = -self.k(self.a-self.u)
> For large equations this is going to make my code seriously unreadable
> to the point of needing to switch back to Matlab -- and it seems to go
> against everything else about python's simplicity and elegance.  Am I

It goes back to the Zen of Python (import this): Explicit is better
than implicit.  And it's a boon to future maintainers of your code

> missing something?  Is there something like a 'with' command that lets
> me set the scope, like
>
> with self:
>   .a_dot = -.k(.a-.u)

The name "self" is just a convention.  You can give it any name you
wish.  Using "s" is common.

As others have mentioned, you can also provide local synonyms if the
dot syntax is too onerous.  But make sure you use the member access
syntax if the result of an expression is an immutable type.  For
example, I assume a_dot is a mutable type, such as a list.  If so,
then you could simply use

   a_dot, k, a, u = self.a_dot, self.k, self.a, self.u
   a_dot = -k(a-u)

However, if it's an immutable type, such as a scalar, strung, or
tuple, you need

   self.a_dot = -k(a-u)

And it gets trickier if you have members taking intermediate values...

>
> It's premature to make language suggestions as I am new to the

That's for sure  ;-)

Regards,

   -=Dave

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Mastering Python

[Dave Hansen]

On Mar 16, 8:39 am, "Paul McGuire" <[EMAIL PROTECTED]> wrote:
[...]
> Stop thinking about *how* to start and *just start*.  Python is pretty

Indeed.  Of all the fortune cookies I've eaten over the years, I've
saved (and taped to my monitor) only one fortune.  It reads:

  Begin...the rest is easy.

Regards,
   -=Dave

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Finding overlapping times...

[Dave Hansen]

On Dec 13, 5:45 pm, Breal <[EMAIL PROTECTED]> wrote:
> I have a list that looks like the following
> [(10, 100010), (15, 17), (19, 100015)]
>
> I would like to be able to determine which of these overlap each
> other.  So, in this case, tuple 1 overlaps with tuples 2 and 3.  Tuple
> 2 overlaps with 1.  Tuple 3 overlaps with tuple 1.
>
> In my scenario I would have hundreds, if not thousands of these
> ranges.  Any nice pythonic way to do this?
>

What are you going to do with the result?  Do you need to know if
there are any overlaps?  The number of overlaps?  Given any particular
range, what ranges overlap?

There's really no way, other than to compare each range.  Note that
the relationship is symmetric, so you can save half you work.  A
simple-minded approach might be

---

def overlaps(t1, t2):
return (t2[1] >= t1[0]) and (t2[0] <= t1[1])

in_data =  [(10, 100010), (15, 17), (19, 100015)]

while (len(in_data) > 1):
target = in_data.pop(0)
for test in in_data:
if overlaps(target,test):
print "%s overlaps with %s" % (repr(target),repr(test))

---

If you want to save the information for later retrieval, you could
build a dictionary with the ranges as keys:

---
ovr_map = {}

while len(in_data) > 1:
target = in_data.pop(0)
for test in in_data:
if overlaps(target,test):
if ovr_map.has_key(target): ovr_map[target].append(test)
else: ovr_map[target] = [test]
if ovr_map.has_key(test): ovr_map[test].append(target)
else: ovr_map[test] = [target]

for target in ovr_map.keys():
for test in ovr_map[target]:
print "%s overlaps with %s" % (repr(target),repr(test))
---

I don't know that there isn't a more Pythonic way, I'm not much of an
expert.  HTH,

   -=Dave
-- 
http://mail.python.org/mailman/listinfo/python-list