Re: Beginner needs advice

[Ian Kelly]

On Sat, May 28, 2011 at 8:33 PM, harrismh777  wrote:
> In this present case the straw-man was not "me," rather the straw-man was
> the python language itself. You chose a code-snippet (one small puny dangle
> that doesn't prove a thing) and used it to speak for the entire language!
>  As though one code-block is enough to demonstrate compatibility for the
> entire language in all of its nuances and details.  To prove something
> positive with a test case requires that you provide *all* test cases, or
> that you provide an algorithm that accounts for *all* test cases... you
> cannot prove compatibility with a code-snippet.

You have just misrepresented Steven's argument, which is rather ironic
considering that you're the one who brought up straw-men.  Steven did
not use one code snippet to demonstrate that Python 2 and Python 3 are
fully compatible.  The code snippet merely demonstrated that Python 2
and 3 are not "totally incompatible" as you had claimed.

I realize you are now asserting that compatibility is a boolean
condition, and that "totally incompatible" is a redundant phrase that
you tossed out as a joke.  I don't know whether you're sincere or
backpedaling, but in any case this assertion is flatly ludicrous.
Following your definition, *nothing* is compatible with anything else.
 If you disagree, then I invite you to list one example of two
different things that are compatible.

And finally, would you please just knock off the fallacy crap?  If you
assert something, and another person counters with a straw-man, and
you respond by dismissing his argument as a straw-man, your response
is valid.  But if you assert something, and another person makes a
counter-argument, to whom you invariably respond by crying
"Straw-man!" or "False analogy!" (or in your case, "Analogy!"; you
seem to view all analogies as false) regardless of what that person
actually said -- even if that person does *sometimes* actually commit
those fallacies -- then you yourself are employing an ad hominem.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Wolfgang Rohdewald]

On Sonntag 29 Mai 2011, Tim Delaney wrote:
> There's a second part the mystery - sets and dictionaries (and
> I think lists) assume that identify implies equality (hence
> the second result). This was recently discussed on
> python-dev, and the decision was to leave things as-is.

On Sonntag 29 Mai 2011, Grant Edwards wrote:
> Even if they are the same nan, it's still not equal to itself.

if I understand this thread correctly, they are not equal to
itself as specified by IEEE but Python treats them equal in
sets and dictionaries for performance reasons

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

Re: float("nan") in set or as key

[Steven D'Aprano]

On Sun, 29 May 2011 10:32:43 +1000, Chris Angelico wrote:

> On Sun, May 29, 2011 at 10:28 AM, Albert Hopkins
>  wrote:
>> This is the same nan, so it is equal to itself.
>>
>>
> Actually, they're not. But it's possible the dictionary uses an 'is'
> check to save computation, and if one thing 'is' another, it is assumed
> to equal it. That's true of most well-behaved objects, but nan is not
> well-behaved :)

*Exactly* correct.

NAN != NAN even if they are the same NAN, by design. This makes NANs ill-
behaved, but usefully so. Most (all?) Python built-ins assume that any 
object X is equal to itself, so they behave strangely with NANs.


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

Error: child process close a socket inherited from parent

[narke]

Hi,

As illustrated in the following simple sample:

import sys
import os
import socket

class Server:
def __init__(self):
self._listen_sock = None

def _talk_to_client(self, conn, addr):
text = 'The brown fox jumps over the lazy dog.\n'
while True:
conn.send(text)
data = conn.recv(1024)
if not data:
break
conn.close()

def listen(self, port):
self._listen_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
self._listen_sock.bind(('', port))
self._listen_sock.listen(128)
self._wait_conn()

def _wait_conn(self):
while True:
conn, addr = self._listen_sock.accept()
if os.fork() == 0:
self._listen_sock.close()   # line x
self._talk_to_client(conn, addr)
else:
conn.close()

if __name__ == '__main__':
Server().listen(int(sys.argv[1]))

Unless I comment out the line x, I will get a 'Bad file descriptor'
error when my tcp client program (e.g, telnet) closes the connection to
the server.  But as I understood, a child process can close a unused
socket (file descriptor).

Do you know what's wrong here?


-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

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

scope of function parameters

[Henry Olders]

I just spent a considerable amount of time and effort debugging a program. The 
made-up code snippet below illustrates the problem I encountered:

def main():
a = ['a list','with','three elements']
print a
print fnc1(a)
print a

def fnc1(b):
return fnc2(b)

def fnc2(c):
c[1] = 'having'
return c

This is the output:
['a list', 'with', 'three elements']
['a list', 'having', 'three elements']
['a list', 'having', 'three elements']

I had expected the third print statement to give the same output as the first, 
but variable a had been changed by changing variable c in fnc2.

It seems that in Python, a variable inside a function is global unless it's 
assigned. This rule has apparently been adopted in order to reduce clutter by 
not having to have global declarations all over the place.

I would have thought that a function parameter would automatically be 
considered local to the function. It doesn't make sense to me to pass a global 
to a function as a parameter.

One workaround is to call a function with a copy of the list, eg in fnc1 I 
would have the statement "return fnc2(b[:]". But this seems ugly.

Are there others who feel as I do that a function parameter should always be 
local to the function? Or am I missing something here?

Henry




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

Re: scope of function parameters

[Wolfgang Rohdewald]

On Sonntag 29 Mai 2011, Henry Olders wrote:
> It seems that in Python, a variable inside a function is
> global unless it's assigned.

no, they are local

> I would have thought that a function parameter would
> automatically be considered local to the function. It doesn't
> make sense to me to pass a global to a function as a
> parameter.

it is local. But consider what you actually passed:
You did not pass a copy of the list but the list itself.
You could also say you passed a reference to the list.
All python variables only hold a pointer (the id) to
an object. This object has a reference count and is
automatically deleted when there are no more references
to it.

If you want a local copy of the list you can either
do what you called being ugly or do just that within
the function itself - which I think is cleaner and
only required once.

def fnc2(c):
c = c[:]
c[1] = 'having'
return c


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

Re: scope of function parameters

[Chris Rebert]

On Sun, May 29, 2011 at 1:30 AM, Henry Olders  wrote:
> I just spent a considerable amount of time and effort debugging a program. 
> The made-up code snippet below illustrates the problem I encountered:
>
> def main():
>        a = ['a list','with','three elements']
>        print a
>        print fnc1(a)
>        print a
>
> def fnc1(b):
>        return fnc2(b)
>
> def fnc2(c):
>        c[1] = 'having'
>        return c
>
> This is the output:
> ['a list', 'with', 'three elements']
> ['a list', 'having', 'three elements']
> ['a list', 'having', 'three elements']
>
> I had expected the third print statement to give the same output as the 
> first, but variable a had been changed by changing variable c in fnc2.

To be more accurate, the list object referred to by `a` was modified
through c, due to the fact that a, b, and c all refer to the very same
object in this case.

> It seems that in Python, a variable inside a function is global unless it's 
> assigned. This rule has apparently been adopted in order to reduce clutter by 
> not having to have global declarations all over the place.
>
> I would have thought that a function parameter would automatically be 
> considered local to the function.

> Are there others who feel as I do that a function parameter should always be 
> local to the function? Or am I missing something here?

Function parameters *are* local variables. Function parameters are
indeed local in that *rebinding* them has no effect outside of the
function:

def foo(a):
a = 42

def bar():
b = 1
foo(b)
print b

bar() #=> outputs 1

As you've observed, *mutating* the object a variable refers to is
another matter entirely. Python does not use call-by-value and does
not copy objects unless explicitly requested to, as you've
encountered. But it does not use call-by-reference either, as my
example demonstrates. Like several other popular contemporary
languages, Python uses call-by-object for parameter passing; a good
explanation of this model can be found at
http://effbot.org/zone/call-by-object.htm  It's well worth reading.

Cheers,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to catch a line with Popen

[TheSaint]

Tim Roberts wrote:

> Are you specifying a buffer size in the Popen command?  If not, then the
> Python side of things is unbuffered

The buffer is as per default. The program reports one line around 1/2 second 
time.
I think I'll look into the option as Nobody states:

p = subprocess.Popen(...)
for line in p.stdout:
...
p.wait()

It is strange that would take a for cycle, rather than catching the line on-
the-fly. I can judge it now, I'm going to try it out.

-- 
goto /dev/null
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to catch a line with Popen

[Chris Rebert]

On Sun, May 29, 2011 at 3:02 AM, TheSaint  wrote:
> Tim Roberts wrote:
>
>> Are you specifying a buffer size in the Popen command?  If not, then the
>> Python side of things is unbuffered
>
> The buffer is as per default. The program reports one line around 1/2 second
> time.
> I think I'll look into the option as Nobody states:
>
>        p = subprocess.Popen(...)
>        for line in p.stdout:
>            ...
>        p.wait()
>
> It is strange that would take a for cycle, rather than catching the line on-
> the-fly. I can judge it now, I'm going to try it out.

What do you mean by "on-the-fly" in this context?

Cheers,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Steven D'Aprano]

On Sat, 28 May 2011 23:12:54 -0700, John Nagle wrote:

> The correct answer to "nan == nan" is to raise an exception, because
> you have asked a question for which the answer is nether True nor False.

Wrong.

The correct answer to "nan == nan" is False, they are not equal. Just as 
None != "none", and 42 != [42], or a teacup is not equal to a box of 
hammers.

Asking whether NAN < 0 could arguably either return "unordered" (raise an 
exception) or return False ("no, NAN is not less than zero; neither is it 
greater than zero"). The PowerPC Macintishes back in the 1990s supported 
both behaviours. But that's different to equality tests.


> The correct semantics for IEEE floating point look something like
> this:
> 
>   1/0 INF
>   INF + 1 INF
>   INF - INF   NaN
>   INF == INF  unordered

Wrong. Equality is not an order comparison.



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

Re: The worth of comments

[Gregory Ewing]

Ben Finney wrote:


You omit the common third possibility: *both* the comment and the code
are wrong.


In that case, the correct response is to fix both of them. :-)

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

Re: Class decorators might also be super too

[Vinay Sajip]

On May 29, 7:33 am, Michele Simionato 
wrote:
> He is basically showing that using mixins for implementingloggingis not such 
> a good idea,

I don't think he was particularly advocating implementing logging this
way, but rather just using logging for illustrative purposes.

Regards,

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

Weird problem matching with REs

[Andrew Berg]

I have an RE that should work (it even works in Kodos [1], but not in my
code), but it keeps failing to match characters after a newline.

I'm writing a little program that scans the webpage of an arbitrary
application and gets the newest version advertised on the page.


test3.py:
> # -*- coding: utf-8 -*-
>
> import configparser
> import re
> import urllib.request
> import os
> import sys
> import logging
> import collections
>
>
> class CouldNotFindVersion(Exception):
> def __init__(self, app_name, reason, exc_value):
> self.value = 'The latest version of ' + app_name + ' could not
> be determined because ' + reason
> self.cause = exc_value
> def __str__(self):
> return repr(self.value)
>
> class AppUpdateItem():
> def __init__(self, config_file_name, config_file_section):
> self.section = config_file_section
> self.name = self.section['Name']
> self.url = self.section['URL']
> self.filename = self.section['Filename']
> self.file_re = re.compile(self.section['FileURLRegex'])
> self.ver_re = re.compile(self.section['VersionRegex'])
> self.prev_ver = self.section['CurrentVersion']
> try:
> self.page = str(urllib.request.urlopen(self.url).read(),
> encoding='utf-8')
> self.file_URL = self.file_re.findall(self.page)[0] #here
> is where it fails
> self.last_ver = self.ver_re.findall(self.file_URL)[0]
> except urllib.error.URLError:
> self.error = str(sys.exc_info()[1])
> logging.info('[' + self.name + ']' + ' Could not load URL:
> ' + self.url + ' : ' + self.error)
> self.success = False
> raise CouldNotFindVersion(self.name, self.error,
> sys.exc_info()[0])
> except IndexError:
> logging.warning('Regex did not return a match.')
> def update_ini(self):
> self.section['CurrentVersion'] = self.last_ver
> with open(config_file_name, 'w') as configfile:
> config.write(configfile)
> def rollback_ini(self):
> self.section['CurrentVersion'] = self.prev_ver
> with open(config_file_name, 'w') as configfile:
> config.write(configfile)
> def download_file(self):
> self.__filename = self.section['Filename']
> with open(self.__filename, 'wb') as file:
> self.__file_req = urllib.request.urlopen(self.file_URL).read()
> file.write(self.__file_req)
>
>
> if __name__ == '__main__':
> config = configparser.ConfigParser()
> config_file = 'checklist.ini'
> config.read(config_file)
> queue = collections.deque()
> for section in config.sections():
> try:
> queue.append(AppUpdateItem(config_file, config[section]))
> except CouldNotFindVersion as exc:
> logging.warning(exc.value)
> for elem in queue:
> if elem.last_ver != elem.prev_ver:
> elem.update_ini()
> try:
> elem.download_file()
> except IOError:
> logging.warning('[' + elem.name + '] Download failed.')
> except:
> elem.rollback_ini()
> print(elem.name + ' succeeded.')

checklist.ini:
> [x264_64]
> name = x264 (64-bit)
> filename = x264.exe
> url = http://x264.nl/x264_main.php
> fileurlregex =
> http://x264.nl/x264/64bit/8bit_depth/revision\n{0,3}[0-9]{4}\n{0,3}/x264\n{0,3}.exe
> versionregex = [0-9]{4}
> currentversion = 1995

The part it's supposed to match in http://x264.nl/x264_main.php:
> http://x264.nl/x264/64bit/8bit_depth/revision
> 1995
> /x264
>
> .exe 
> http://x264.nl/x264/64bit/8bit_depth/revision%0A1995%0A/x264%0A%0A.exe>"
>  
I was able to make a regex that matches in my code, but it shouldn't:
http://x264.nl/x264/64bit/8bit_depth/revision.\n{1,3}[0-9]{4}.\n{1,3}/x264.\n{1,3}.\n{1,3}.exe
I have to add a dot before each "\n". There is no character not
accounted for before those newlines, but I don't get a match without the
dots. I also need both those ".\n{1,3}" sequences before the ".exe". I'm
really confused.

Using Python 3.2 on Windows, in case it matters.


[1] http://kodos.sourceforge.net/ (using the compiled Win32 version
since it doesn't work with Python 3)

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

Re: scope of function parameters

[Mel]

Henry Olders wrote:

> I just spent a considerable amount of time and effort debugging a program.
> The made-up code snippet below illustrates the problem I encountered:
> 
> def main():
> a = ['a list','with','three elements']
> print a
> print fnc1(a)
> print a
> 
> def fnc1(b):
> return fnc2(b)
> 
> def fnc2(c):
> c[1] = 'having'
> return c
> 
> This is the output:
> ['a list', 'with', 'three elements']
> ['a list', 'having', 'three elements']
> ['a list', 'having', 'three elements']
> 
> I had expected the third print statement to give the same output as the
> first, but variable a had been changed by changing variable c in fnc2.
> 
> It seems that in Python, a variable inside a function is global unless
> it's assigned. This rule has apparently been adopted in order to reduce
> clutter by not having to have global declarations all over the place.
> 
> I would have thought that a function parameter would automatically be
> considered local to the function. It doesn't make sense to me to pass a
> global to a function as a parameter.

It doesn't look like a question of local or global.  fnc2 is passed a 
container object and replaces item 1 in that container.  You see the results 
when fnc2 prints the object it knows as `c`, and you see again when main 
prints the object it knows as `a`.  Python doesn't pass parameters by 
handing around copies that can be thought of as local or global.  Python 
passes parameters by binding objects to names in the callee's namespace.  In 
your program the list known as `a` in main is identically the same list as 
the one known as `c` in fnc2, and what happens happens.

Mel.

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

Re: scope of function parameters

[Steven D'Aprano]

On Sun, 29 May 2011 11:47:26 +0200, Wolfgang Rohdewald wrote:

> On Sonntag 29 Mai 2011, Henry Olders wrote:
>> It seems that in Python, a variable inside a function is global unless
>> it's assigned.
> 
> no, they are local

I'm afraid you are incorrect. Names inside a function are global unless 
assigned to somewhere.

>>> a = 1
>>> def f():
... print a  # Not local, global.
...
>>> f()
1


By default, names inside a function must be treated as global, otherwise 
you couldn't easily refer to global functions:

def f(x):
print len(x)

because len would be a local name, which doesn't exist. In Python, built-
in names are "variables" just like any other.

Python's scoping rule is something like this:

If a name is assigned to anywhere in the function, treat it as a local, 
and look it up in the local namespace. If not found, raise 
UnboundLocalError.

If a name is never assigned to, or if it is declared global, then look it 
up in the global namespace. If not found, look for it in the built-ins. 
If still not found, raise NameError.

Nested scopes (functions inside functions) make the scoping rules a 
little more complex.

If a name is a function parameter, that is equivalent to being assigned 
to inside the function.


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

Re: Weird problem matching with REs

[Ben Finney]

Andrew Berg  writes:

> I was able to make a regex that matches in my code, but it shouldn't:
> http://x264.nl/x264/64bit/8bit_depth/revision.\n{1,3}[0-9]{4}.\n{1,3}/x264.\n{1,3}.\n{1,3}.exe
> I have to add a dot before each "\n". There is no character not
> accounted for before those newlines, but I don't get a match without the
> dots. I also need both those ".\n{1,3}" sequences before the ".exe". I'm
> really confused.
>
> Using Python 3.2 on Windows, in case it matters.

You are aware that most text-emitting processes on Windows, and Internet
text protocols like the HTTP standard, use the two-character “CR LF”
sequence (U+000C U+000A) for terminating lines?

http://en.wikipedia.org/wiki/Newline>

-- 
 \  “What I have to do is see, at any rate, that I do not lend |
  `\  myself to the wrong which I condemn.” —Henry Thoreau, _Civil |
_o__)Disobedience_ |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Weird problem matching with REs

[Ben Finney]

Ben Finney  writes:

> the two-character “CR LF” sequence (U+000C U+000A)
> http://en.wikipedia.org/wiki/Newline>

As detailed in that Wikipedia article, the characters are of course
U+000D U+000A.

-- 
 \  “You say “Carmina”, and I say “Burana”, You say “Fortuna”, and |
  `\I say “cantata”, Carmina, Burana, Fortuna, cantata, Let's Carl |
_o__)the whole thing Orff.” —anonymous |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Weird problem matching with REs

[Steven D'Aprano]

On Sun, 29 May 2011 06:45:30 -0500, Andrew Berg wrote:

> I have an RE that should work (it even works in Kodos [1], but not in my
> code), but it keeps failing to match characters after a newline.

Not all regexes are the same. Different regex engines accept different 
symbols, and sometimes behave differently, or have different default 
behavior. That your regex works in Kodos but not Python might mean you're 
writing a Kodus regex instead of a Python regex.

> I'm writing a little program that scans the webpage of an arbitrary
> application and gets the newest version advertised on the page.

Firstly, most of the code you show is irrelevant to the problem. Please 
simplify it to the shortest, most simple example you can give. That would 
be a simplified piece of text (not the entire web page!), the regex, and 
the failed attempt to use it. The rest of your code is just noise for the 
purposes of solving this problem.

Secondly, you probably should use a proper HTML parser, rather than a 
regex. Resist the temptation to use regexes to rip out bits of text from 
HTML, it almost always goes wrong eventually.


> I was able to make a regex that matches in my code, but it shouldn't:
> http://x264.nl/x264/64bit/8bit_depth/revision.\n{1,3}[0-9]{4}.\n{1,3}/
x264.\n{1,3}.\n{1,3}.exe

What makes you think it shouldn't match?

By the way, you probably should escape the dots, otherwise it will match 
strings containing any arbitrary character, rather than *just* dots:

http://x264Znl ...blah blah blah



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

Re: Weird problem matching with REs

[Andrew Berg]

On 2011.05.29 08:00 AM, Ben Finney wrote:
> You are aware that most text-emitting processes on Windows, and Internet
> text protocols like the HTTP standard, use the two-character “CR LF”
> sequence (U+000C U+000A) for terminating lines?
Yes, but I was not having trouble with just '\n' before, and the pattern
did match in Kodos, so I figured Python was doing its newline magic like
it does with the write() method for file objects.
http://x264.nl/x264/64bit/8bit_depth/revision[\r\n]{1,3}[0-9]{4}[\r\n]{1,3}/x264[\r\n]{1,3}.exe
does indeed match. One thing that confuses me, though (and one reason I
dismissed the possibility of it being a newline issue): isn't '.'
supposed to not match '\r'?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Weird problem matching with REs

[Andrew Berg]

On 2011.05.29 08:09 AM, Steven D'Aprano wrote:
> On Sun, 29 May 2011 06:45:30 -0500, Andrew Berg wrote:
>
> > I have an RE that should work (it even works in Kodos [1], but not in my
> > code), but it keeps failing to match characters after a newline.
>
> Not all regexes are the same. Different regex engines accept different 
> symbols, and sometimes behave differently, or have different default 
> behavior. That your regex works in Kodos but not Python might mean you're 
> writing a Kodus regex instead of a Python regex.
Kodos is written in Python and uses Python's regex engine. In fact, it
is specifically intended to debug Python regexes.
> Firstly, most of the code you show is irrelevant to the problem. Please 
> simplify it to the shortest, most simple example you can give. That would 
> be a simplified piece of text (not the entire web page!), the regex, and 
> the failed attempt to use it. The rest of your code is just noise for the 
> purposes of solving this problem.
I wasn't sure how much would be relevant since it could've been a
problem with other code. I do apologize for not putting more effort into
trimming it down, though.
> Secondly, you probably should use a proper HTML parser, rather than a 
> regex. Resist the temptation to use regexes to rip out bits of text from 
> HTML, it almost always goes wrong eventually.
I find this a much simpler approach, especially since I'm dealing with
broken HTML. I guess I don't see how the effort put into learning a
parser and adding the extra code to use it pays off in this particular
endeavor.
> > I was able to make a regex that matches in my code, but it shouldn't:
> > http://x264.nl/x264/64bit/8bit_depth/revision.\n{1,3}[0-9]{4}.\n{1,3}/
> x264.\n{1,3}.\n{1,3}.exe
>
> What makes you think it shouldn't match?
AFAIK, dots aren't supposed to match carriage returns or any other
whitespace characters.
> By the way, you probably should escape the dots, otherwise it will match 
> strings containing any arbitrary character, rather than *just* dots:
You're right; I overlooked the dots in the URL.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to catch a line with Popen

[TheSaint]

Chris Rebert wrote:

> What do you mean by "on-the-fly" in this context

I just suppose to elaborate the latest line, as soon it's written on the 
pipe, and print some result on the screen.
Imaging something like

 p= Popen(['ping','-c40','www.google.com'], stdout=PIPE)
 for line in p.stdout:
 print(str(line).split()[7])

I'd like to see something like *time=54.4*
This is just an example, where if we remove the "-c40" on the command line, 
I'd expect to read the latest line(s), until the program will be killed.

-- 
goto /dev/null
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Error: child process close a socket inherited from parent

[narke]

On 2011-05-29, narke  wrote:
> Hi,
>
> As illustrated in the following simple sample:
>
> import sys
> import os
> import socket
>
> class Server:
> def __init__(self):
> self._listen_sock = None
>
> def _talk_to_client(self, conn, addr):
> text = 'The brown fox jumps over the lazy dog.\n'
> while True:
> conn.send(text)
> data = conn.recv(1024)
> if not data:
> break
> conn.close()
>
> def listen(self, port):
> self._listen_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> self._listen_sock.bind(('', port))
> self._listen_sock.listen(128)
> self._wait_conn()
>
> def _wait_conn(self):
> while True:
> conn, addr = self._listen_sock.accept()
> if os.fork() == 0:
> self._listen_sock.close()   # line x
> self._talk_to_client(conn, addr)
> else:
> conn.close()
>
> if __name__ == '__main__':
> Server().listen(int(sys.argv[1]))
>
> Unless I comment out the line x, I will get a 'Bad file descriptor'
> error when my tcp client program (e.g, telnet) closes the connection to
> the server.  But as I understood, a child process can close a unused
> socket (file descriptor).
>
> Do you know what's wrong here?
>
>

I forgot to say, it's Python 2.6.4 running on linux 2.6.33


-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

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

Re: Beginner needs advice

[Steven D'Aprano]

On Sat, 28 May 2011 21:02:47 -0500, harrismh777 wrote:

> Minor, yes,  until you need to make something work--- only to be
> frustrated to find that a detail that was not expected has risen to bite
> a sensitive place...   :)

Just like when migrating from Python 2.3 to 2.6. And 1.5 and 2.0, and 2.0 
and 2.2, and 2.2 and 2.3.


> I am amazed at how many folks are not using 3.x/  Why?  (beats me),

Because:

(1) the major operating systems either don't provide Python at all
(Windows), or are conservatively still using Python 2.6 or even 
2.5 (Mac OS, most Linux distros); 

(2) the Python website still recommends that "Python 2.x is the 
status quo, Python 3.x is the shiny new thing" 

 ; 

and

(3) the most of the big frameworks and libraries have either just
recently been upgraded to support 3.x, or haven't yet been 
upgraded.


There's very little mystery about it. Migration to 3.x is going according 
to plan. The majority aren't expected to migrate until probably 3.4 or 
even 3.5.


> but how do I know they're not using it...?   Because, if they were
> trying to use it with 2.x knowledge they would be complaining bloody
> murder..   for instance, how do we reload a module in 2.x...  with, um,
> reload.   This has always been the way... every book says so,

*Every* book? Even these?

http://diveintopython3.org/
http://www.qtrac.eu/py3book.html
http://www.mindviewinc.com/Books/Python3Patterns/Index.php


Please quote chapter and verse.



[...]
> PS   Something nobody has pointed out yet is that "completely
> incompatible" is redundant.

That's because it is not redundant. There is a difference between 1% 
compatible and 99% compatible and 100% incompatible.


>  ... its like saying totally destroyed. I
> was trying to be funny, but nobody unpinned it... I'm disappointed.
> 
> Some of the posts here are referring to the two languages as partially
> incompatible   reminds me of that line from Princess Bride... "...
> he's not dead, hes only mostly dead!... and mostly dead is partly
> alive!"  To say that 3.x is partly compatible with 2.x is silly, 

What a ridiculous statement, and one which flies in the face of major 
projects like numpy which support 2.x and 3.x out of a single code base.


I invite you to consider the difference between a legally dead person 
moments before being resuscitated by a paramedic, versus a chicken that 
has just been beheaded and is still running around the yard, versus a 
million-year-old fossilized bone that has turned to stone. Who could 
possibly justify saying that all three are equally dead?

Beware the tyranny of the discontinuous mind.

http://www.sciencemusings.com/2007/07/tyranny-of-discontinuous-mind.html

Both life and compatibility are matters of degree, not binary states. For 
proper operation, an electrical device might require a 6V 250mA 
transformer, but it might work well enough with one that provides just 5V 
and 240mA, provided you don't stress the device too much.

We often design our physical devices to force compatibility to be all-or-
nothing, e.g. you can't fit a USB plug into an audio jack, no matter how 
you try. But that's enforced by the design, not because compatibility is 
inherently true/false. Compatibility is inherently continuous, a matter 
of degree.

This is especially true when it comes to languages, both natural and 
programming. British English and American English are perhaps 99.5% 
compatible, but "table a motion" means completely opposite things in 
British and American English. (In Britain, it means to deal with it 
immediately; in the USA, it means to postpone it.) Should we conclude 
from this that British and American English are "different languages" and 
"completely incompatible"?

The differences between Python 2 and 3 are less than those between 
American and British English. To describe them as "different languages", 
as if going from Python 2 to 3 was like translating English to Italian, 
is absurd.



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

Re: How to catch a line with Popen

[TheSaint]

TheSaint wrote:

> I just suppose to elaborate the latest line, as soon it's written on the
> pipe, and print some result on the screen.

I think some info is also here:
http://alexandredeverteuil.blogspot.com/
-- 
goto /dev/null
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Weird problem matching with REs

[Steven D'Aprano]

On Sun, 29 May 2011 08:41:16 -0500, Andrew Berg wrote:

> On 2011.05.29 08:09 AM, Steven D'Aprano wrote:
[...]
> Kodos is written in Python and uses Python's regex engine. In fact, it
> is specifically intended to debug Python regexes.

Fair enough.

>> Secondly, you probably should use a proper HTML parser, rather than a
>> regex. Resist the temptation to use regexes to rip out bits of text
>> from HTML, it almost always goes wrong eventually.
>
> I find this a much simpler approach, especially since I'm dealing with
> broken HTML. I guess I don't see how the effort put into learning a
> parser and adding the extra code to use it pays off in this particular
> endeavor.

The temptation to take short-cuts leads to the Dark Side :)

Perhaps you're right, in this instance. But if you need to deal with 
broken HTML, try BeautifulSoup.


>> What makes you think it shouldn't match?
> 
> AFAIK, dots aren't supposed to match carriage returns or any other
> whitespace characters.

They won't match *newlines* \n unless you pass the DOTALL flag, but they 
do match whitespace:

>>> re.search('abc.efg', 'abc efg').group()
'abc efg'
>>> re.search('abc.efg', 'abc\refg').group()
'abc\refg'
>>> re.search('abc.efg', 'abc\nefg') is None
True


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

Re: Weird problem matching with REs

[Andrew Berg]

On 2011.05.29 09:18 AM, Steven D'Aprano wrote:
> >> What makes you think it shouldn't match?
> > 
> > AFAIK, dots aren't supposed to match carriage returns or any other
> > whitespace characters.
>
> They won't match *newlines* \n unless you pass the DOTALL flag, but they 
> do match whitespace:
>
> >>> re.search('abc.efg', 'abc efg').group()
> 'abc efg'
> >>> re.search('abc.efg', 'abc\refg').group()
> 'abc\refg'
> >>> re.search('abc.efg', 'abc\nefg') is None
> True
I got things mixed up there (was thinking whitespace instead of
newlines), but I thought dots aren't supposed to match '\r' (carriage
return). Why is '\r' not considered a newline character?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Grant Edwards]

On 2011-05-29, Wolfgang Rohdewald  wrote:
> On Sonntag 29 Mai 2011, Tim Delaney wrote:
>> There's a second part the mystery - sets and dictionaries (and
>> I think lists) assume that identify implies equality (hence
>> the second result). This was recently discussed on
>> python-dev, and the decision was to leave things as-is.
>
> On Sonntag 29 Mai 2011, Grant Edwards wrote:
>> Even if they are the same nan, it's still not equal to itself.
>
> if I understand this thread correctly, they are not equal to itself
> as specified by IEEE

And Python follows that convention.

> but Python treats them equal in sets and dictionaries for performance
> reasons

It treats them as identical (not sure if that's the right word).  The
implementation is checking for ( A is B or A == B ).  Presumably, the
assumpting being that all objects are equal to themselves.  That
assumption is not true for NaN objects, so the buggy behavior is
observed.

-- 
Grant



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

Re: The worth of comments

[Grant Edwards]

On 2011-05-29, Gregory Ewing  wrote:
> Ben Finney wrote:
>
>> You omit the common third possibility: *both* the comment and the code
>> are wrong.
>
> In that case, the correct response is to fix both of them. :-)

Only as a last resort. IMO, the best option is to fix the code so it's
purpose and operation is obvious from the code, and then delete the
comment.

-- 
Grant



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

Re: Weird problem matching with REs

[Roy Smith]

In article ,
 Andrew Berg  wrote:

> Kodos is written in Python and uses Python's regex engine. In fact, it
> is specifically intended to debug Python regexes.

Named after the governor of Tarsus IV?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Weird problem matching with REs

[Andrew Berg]

On 2011.05.29 10:19 AM, Roy Smith wrote:
> Named after the governor of Tarsus IV?
Judging by the graphic at http://kodos.sourceforge.net/help/kodos.html ,
it's named after the Simpsons character.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The worth of comments

[Roy Smith]

In article ,
 Grant Edwards  wrote:

> On 2011-05-29, Gregory Ewing  wrote:
> > Ben Finney wrote:
> >
> >> You omit the common third possibility: *both* the comment and the code
> >> are wrong.
> >
> > In that case, the correct response is to fix both of them. :-)
> 
> Only as a last resort. IMO, the best option is to fix the code so it's
> purpose and operation is obvious from the code, and then delete the
> comment.

This is a plausible(*) strategy for internal use software where all 
users have easy access to all code which depends on yours and are free 
to change interfaces willy-nilly.  That's not always the case.  Even on 
open-source projects, having stand-alone documentation is critical for 
usability, and certainly having stable interfaces is critical if you 
expect people to adopt your system and build on it.

(*)And, even in the case where it's internal code and everybody on the 
project has full and unfettered access to all the source, documenting 
interfaces adds to usability.  I've seen plenty of code which looks like 
this (pseudo-code):

Class1::f1() {
   return Class2::f2();
}

Class2::f2() {
   return Class3::f3();
}

Class3::f3() {
   return Class4::f4();
}

If you're trying to figure out what type of object f1() returns, you've 
got to chase down a long string of, "Well, f1 returns whatever f2 
returns, and f2 returns whatever f3 returns, and f3 returns whatever f4 
returns, and"  Each step in that process might involve figuring out 
just where the heck the code for ClassN is.  And Cthulhu help you if 
some step along the way involves an indirectly referenced class or 
function so you can't even grep the source tree for the name you're 
looking for.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Weird problem matching with REs

[John S]

On May 29, 10:35 am, Andrew Berg  wrote:
> On 2011.05.29 09:18 AM, Steven D'Aprano wrote:> >> What makes you think it 
> shouldn't match?
>
> > > AFAIK, dots aren't supposed to match carriage returns or any other
> > > whitespace characters.
>
> I got things mixed up there (was thinking whitespace instead of
> newlines), but I thought dots aren't supposed to match '\r' (carriage
> return). Why is '\r' not considered a newline character?

Dots don't match end-of-line-for-your-current-OS is how I think of
it.

While I almost usually nod my head at Steven D'Aprano's comments, in
this case I have to say that if you just want to grab something from a
chunk of HTML, full-blown HTML parsers are overkill. True, malformed
HTML can throw you off, but they can also throw a parser off.

I could not make your regex work on my Linux box with Python 2.6.

In your case, and because x264 might change their HTML, I suggest the
following code, which works great on my system.YMMV. I changed your
newline matches to use \s and put some capturing parentheses around
the date, so you could grab it.

>>> import urllib2
>>> import re
>>>
>>> content = urllib2.urlopen("http://x264.nl/x264_main.php";).read()
>>>
>>> rx_x264version= 
>>> re.compile(r"http://x264\.nl/x264/64bit/8bit_depth/revision\s*(\d{4})\s*/x264\s*\.exe")
>>>
>>> m = rx_x264version.search(content)
>>> if m:
... print m.group(1)
...
1995
>>>


\s is your friend -- matches space, tab, newline, or carriage return.
\s* says match 0 or more spaces, which is what's needed here in case
the web site decides to *not* put whitespace in the middle of a URL...

As Steven said, when you want match a dot, it needs to be escaped,
although it will work by accident much of the time. Also, be sure to
use a raw string when composing REs, so you don't run into backslash
issues.

HTH,
John Strickler
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Weird problem matching with REs

[Andrew Berg]

On 2011.05.29 10:48 AM, John S wrote:
> Dots don't match end-of-line-for-your-current-OS is how I think of
> it.
IMO, the docs should say the dot matches any character except a line
feed ('\n'), since that is more accurate.
> True, malformed
> HTML can throw you off, but they can also throw a parser off.
That was part of my point. html.parser.HTMLParser from the standard
library will definitely not work on x264.nl's broken HTML, and fixing it
requires lxml (I'm working with Python 3; I've looked into
BeautifulSoup, and does not work with Python 3 at all). Admittedly,
fixing x264.nl's HTML only requires one or two lines of code, but really
nasty HTML might require quite a bit of work.
> In your case, and because x264 might change their HTML, I suggest the
> following code, which works great on my system.YMMV. I changed your
> newline matches to use \s and put some capturing parentheses around
> the date, so you could grab it.
I've been meaning to learn how to use parenthesis groups.
> Also, be sure to
> use a raw string when composing REs, so you don't run into backslash
> issues.
How would I do that when grabbing strings from a config file (via the
configparser module)? Or rather, if I have a predefined variable
containing a string, how do change it into a raw string?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Weird problem matching with REs

[John S]

On May 29, 12:16 pm, Andrew Berg  wrote:
>
> I've been meaning to learn how to use parenthesis groups.
> > Also, be sure to
> > use a raw string when composing REs, so you don't run into backslash
> > issues.
>
> How would I do that when grabbing strings from a config file (via the
> configparser module)? Or rather, if I have a predefined variable
> containing a string, how do change it into a raw string?
When reading the RE from a file it's not an issue. Only literal
strings can be raw. If the data is in a file, the data will not be
parsed by the Python interpreter. This was just a general warning to
anyone working with REs. It didn't apply in this case.

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

Re: scope of function parameters

[Peter Pearson]

On Sun, 29 May 2011 04:30:52 -0400, Henry Olders wrote: 
[snip]
> def main():
>   a = ['a list','with','three elements']
>   print a
>   print fnc1(a)
>   print a
>   
> def fnc1(b):
>   return fnc2(b)
>
> def fnc2(c):
>   c[1] = 'having'
>   return c
>
> This is the output:
> ['a list', 'with', 'three elements']
> ['a list', 'having', 'three elements']
> ['a list', 'having', 'three elements']
>
> I had expected the third print statement to give the same
> output as the first, but variable a had been changed by
> changing variable c in fnc2.

For what it's worth, I've noticed that use of the word "variable"
is correlated with a misunderstanding of Python's way of doing
things.  

"Variable" seems to connote a box that has something in it,
so when fnc1 passes b to fnc2 which calls it c, you think
you have a box named b and a box named c, and you wonder
whether the contents of those boxes are the same or
different.

Python works in terms of objects having names, and one
object can have many names.  In your example, fnc1 works
with an object that it calls b, and which it passes to fnc2,
but fnc2 chooses to call that same object c.  The names b
and c aren't boxes that hold things, they are -- in the
words of one of this group's old hands -- sticky-note labels
that have been slapped on the same object.

-- 
To email me, substitute nowhere->spamcop, invalid->net.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The worth of comments

[Alister Ware]

On Sun, 29 May 2011 12:47:52 +1200, Gregory Ewing wrote:

> Irmen de Jong wrote:
> 
>> I don't see how that is opposed to what Grant was saying. It's that
>> these 'contracts' tend to change and that people forget or are too lazy
>> to update the comments to reflect those changes.
> 
> However, I can't see that deleting the comment documenting the contract
> can be the right response to the situation.
> 
> If the contract comment doesn't match what code does, then there are two
> possibilities -- the comment is wrong, or the code is wrong. The
> appropriate response is to find out which one is wrong and fix it.
> 
> If you simply delete the comment, then you're left with no redundancy to
> catch the fact that something is wrong.

"if the comments & code disagree then both are probably wrong"



-- 
Most public domain software is free, at least at first glance.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[MRAB]

On 29/05/2011 15:41, Grant Edwards wrote:

On 2011-05-29, Wolfgang Rohdewald  wrote:

On Sonntag 29 Mai 2011, Tim Delaney wrote:

There's a second part the mystery - sets and dictionaries (and
I think lists) assume that identify implies equality (hence
the second result). This was recently discussed on
python-dev, and the decision was to leave things as-is.


On Sonntag 29 Mai 2011, Grant Edwards wrote:

Even if they are the same nan, it's still not equal to itself.


if I understand this thread correctly, they are not equal to itself
as specified by IEEE


And Python follows that convention.


but Python treats them equal in sets and dictionaries for performance
reasons


It treats them as identical (not sure if that's the right word).  The
implementation is checking for ( A is B or A == B ).  Presumably, the
assumpting being that all objects are equal to themselves.  That
assumption is not true for NaN objects, so the buggy behavior is
observed.


Would there be any advantage to making NaN a singleton? I'm thinking
that it could make checking for it cheaper in the implementation of
sets and dicts. Or making NaN unhashable?
--
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Chris Angelico]

On Mon, May 30, 2011 at 3:44 AM, MRAB  wrote:
> Would there be any advantage to making NaN a singleton? I'm thinking
> that it could make checking for it cheaper in the implementation of
> sets and dicts. Or making NaN unhashable?

Doesn't matter. It still wouldn't be equal to itself, even though it
'is' itself, which will greatly confuse anything that optimizes that
away. Numbers are well-behaved; NaN is not a number; NaN is not
well-behaved. It makes sense... in a way.

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

Re: scope of function parameters

[Chris Angelico]

On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano
 wrote:
> If a name is assigned to anywhere in the function, treat it as a local,
> and look it up in the local namespace. If not found, raise
> UnboundLocalError.
>

Wait wha? I've never seen this... wouldn't it just create it in the
local namespace?

Can you give example code that will trigger this error? I'm curious, now...

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

Re: Weird problem matching with REs

[Chris Angelico]

On Mon, May 30, 2011 at 2:16 AM, Andrew Berg  wrote:
>> Also, be sure to
>> use a raw string when composing REs, so you don't run into backslash
>> issues.
> How would I do that when grabbing strings from a config file (via the
> configparser module)? Or rather, if I have a predefined variable
> containing a string, how do change it into a raw string?
>

"Raw string" is slightly inaccurate. The Python "raw string literal"
syntax is just another form of string literal:

'apostrophe-delimited string'
"quote-delimited string"
"""triple-quote string
which may
go over
multiple lines"""
'''triple-apostrophe string'''
r'raw apostrophe string'
r"raw quote string"

They're all equivalent once you have the string object. The only
difference is how they appear in your source code. If you read
something from a config file, you get a string object directly, and
you delimit it with something else (end of line, or XML closing tag,
or whatever), so you don't have to worry about string quotes.

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

Re: scope of function parameters

[Chris Rebert]

On Sun, May 29, 2011 at 10:53 AM, Chris Angelico  wrote:
> On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano
>  wrote:
>> If a name is assigned to anywhere in the function, treat it as a local,
>> and look it up in the local namespace. If not found, raise
>> UnboundLocalError.
>>
>
> Wait wha? I've never seen this... wouldn't it just create it in the
> local namespace?
>
> Can you give example code that will trigger this error? I'm curious, now...

def foo():
print bar
bar = 42

foo()

===>
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in foo
UnboundLocalError: local variable 'bar' referenced before assignment

Cheers,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Christian Heimes]

Am 29.05.2011 19:44, schrieb MRAB:
> Would there be any advantage to making NaN a singleton? I'm thinking
> that it could make checking for it cheaper in the implementation of
> sets and dicts. Or making NaN unhashable?

It can't be a singleton, because IEEE 754 specifies millions of millions
of different NaN values. There are positive and negative NaNs, quiet
NaNs and signaling NaNs. 50 of 52 mantissa bits can vary freely, one bit
makes the difference between signaling and quiet NaNs and at least one
bit must be non-zero.

Christian

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

Re: float("nan") in set or as key

[Steven D'Aprano]

On Sun, 29 May 2011 18:44:08 +0100, MRAB wrote:

> Would there be any advantage to making NaN a singleton?

Absolutely not. That would be a step backwards.

NANs can carry payload (a code indicating what sort of NAN it represents 
-- log(-1) and 1/INF are not the same). So although Python currently has 
no easy way to access that payload (you can do it with the struct 
module), it does exist and for serious work you would want to be able to 
set and get it.


> I'm thinking
> that it could make checking for it cheaper in the implementation of sets
> and dicts. 

I don't see how would it be cheaper, but even if it were, talk about a 
micro-optimization! I'd really *love* to see the code where the time it 
takes to insert a NAN in a set was the bottleneck!



> Or making NaN unhashable?

I could live with that, although I don't think it is necessary. What 
actual problem are you hoping to solve here?



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

Re: scope of function parameters

[Steven D'Aprano]

On Mon, 30 May 2011 03:53:24 +1000, Chris Angelico wrote:

> On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano
>  wrote:
>> If a name is assigned to anywhere in the function, treat it as a local,
>> and look it up in the local namespace. If not found, raise
>> UnboundLocalError.
>>
>>
> Wait wha? I've never seen this... wouldn't it just create it in the
> local namespace?
> 
> Can you give example code that will trigger this error? I'm curious,
> now...

def f():
print a  # a is not yet defined, i.e. unbound
a = 1  # this makes a local


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

Re: scope of function parameters

[Chris Angelico]

On Mon, May 30, 2011 at 4:01 AM, Chris Rebert  wrote:
> def foo():
>    print bar
>    bar = 42
>
> foo()
>
> ===>
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "", line 2, in foo
> UnboundLocalError: local variable 'bar' referenced before assignment

Wow

I thought it basically functioned top-down. You get a different error
on the print line if there's a "bar = 42" *after* it. This could make
debugging quite confusing.

Guess it's just one of the consequences of eschewing variable
declarations. Sure it's easier, but there's complications down the
road.

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

Re: float("nan") in set or as key

[Steven D'Aprano]

On Sun, 29 May 2011 20:05:07 +0200, Christian Heimes wrote:

> Am 29.05.2011 19:44, schrieb MRAB:
>> Would there be any advantage to making NaN a singleton? I'm thinking
>> that it could make checking for it cheaper in the implementation of
>> sets and dicts. Or making NaN unhashable?
> 
> It can't be a singleton, because IEEE 754 specifies millions of millions
> of different NaN values. 

A million-millioneton then? *wink*


> There are positive and negative NaNs, 

I've never quite understood that. NANs are unordered, and therefore 
cannot be said to be larger than zero (positive) or less than zero 
(negative). So even if a NAN has the sign bit set, surely the right way 
to think about that is to treat the sign bit as part of the payload?

It seems to me that talking about signed NANs is inaccurate and adds 
confusion. NANs cause enough confusion as it is, without adding to it...

(I would expect the copysign function to honour the sign bit, so I 
suppose in that sense one might describe NANs as signed.)



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

Re: scope of function parameters

[Steven D'Aprano]

On Mon, 30 May 2011 04:38:26 +1000, Chris Angelico wrote:

> On Mon, May 30, 2011 at 4:01 AM, Chris Rebert  wrote:
>> def foo():
>>    print bar
>>    bar = 42
>>
>> foo()
>>
>> ===>
>> Traceback (most recent call last):
>>  File "", line 1, in 
>>  File "", line 2, in foo
>> UnboundLocalError: local variable 'bar' referenced before assignment
> 
> Wow
> 
> I thought it basically functioned top-down. You get a different error on
> the print line if there's a "bar = 42" *after* it. This could make
> debugging quite confusing.

UnboundLocalError is a subclass of NameError, so it will still be caught 
by try...except NameError.

If you're crazy enough to be catching NameError :)

Go back to Python1.5, and there was no UnboundLocalError. It was 
introduced because people were confused when they got a NameError after 
forgetting to declare something global:


>>> def f():
... print a
... a = a + 1
...
>>> a = 42
>>> f()
Traceback (innermost last):
  File "", line 1, in ?
  File "", line 2, in f
NameError: a


While UnboundLocalError is jargon, and not the easiest error message to 
comprehend, at least it confuses in a different way :)


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

Re: Weird problem matching with REs

[Thomas 'PointedEars' Lahn]

Andrew Berg wrote:

> On 2011.05.29 10:19 AM, Roy Smith wrote:
>> Named after the governor of Tarsus IV?
> Judging by the graphic at http://kodos.sourceforge.net/help/kodos.html ,
> it's named after the Simpsons character.



I don't think that's a coincidence; both are from other planets and both are 
rather evil[tm].  Kodos the Executioner, arguably human, became a dictator 
who had thousands killed (by his own account, not to let the rest die of 
hunger); Kodos the slimy extra-terrestrial is a conqueror (and he likes to 
zap humans as well ;-))

[BTW, Tarsus IV, a planet where thousands (would) have died of hunger and 
have died in executions was probably yet another hidden Star Trek euphemism.  
I have found out that Tarsus is, among other things, the name of a 
collection of bones in the human foot next to the heel.  Bones as a 
reference to death aside, see also Achilles for the heel.  But I'm only 
speculating here.]



-- 
\\//, PointedEars (F'up2 trek)

Bitte keine Kopien per E-Mail. / Please do not Cc: me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scope of function parameters

[Ian Kelly]

On Sun, May 29, 2011 at 12:38 PM, Chris Angelico  wrote:
> I thought it basically functioned top-down. You get a different error
> on the print line if there's a "bar = 42" *after* it. This could make
> debugging quite confusing.
>
> Guess it's just one of the consequences of eschewing variable
> declarations. Sure it's easier, but there's complications down the
> road.

It's also a consequence of local variable access being optimized with
different bytecode: the type of storage has to be determined at
compile time.  The compiler could in principle figure out that "bar"
cannot be bound at that point and make it a global reference, but it
is easy to concoct situations involving loops or conditionals where
the storage cannot be determined at compile time, and so the compiler
follows the simple rule of making everything local unless it's never
assigned.

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scope of function parameters

[Chris Angelico]

On Mon, May 30, 2011 at 4:53 AM, Steven D'Aprano
 wrote:
> UnboundLocalError is a subclass of NameError, so it will still be caught
> by try...except NameError.
>
> If you're crazy enough to be catching NameError :)

Ah okay. So it is still NameError, it just doesn't look like one.

> While UnboundLocalError is jargon, and not the easiest error message to
> comprehend, at least it confuses in a different way :)

I have nothing against jargon, and specific errors are better than
generic ones (imagine if every error were thrown as Exception with a
string parameter... oh wait, that's what string exceptions are).

It still seems a little odd that a subsequent line can affect this
one. But Python's mostly doing what would be expected of it; the worst
I can come up with is this:

def f():
  print(foo) # reference a global
  ...
  for foo in bar: # variable only used in loop
pass

If you're used to C++ and declaring variables inside a for loop eg
"for (int i=0;i<10;++i)", you might not concern yourself with the fact
that 'foo' is masking a global; it's not an issue, because you don't
need that global inside that loop, right? And it would be fine, except
that that global IS used somewhere else in the function. It'd be a bit
confusing to get the UnboundLocalError up on the print(foo) line (the
one that's meant to be using the global), since that line isn't wrong;
and the "obvious fix", adding an explicit "global foo" to the top of
the function, would be worse (because it would mean that the for loop
overwrites the global).

This is why I would prefer to declare variables. The Zen of Python
says that explicit is better than implicit, but in this instance,
Python goes for DWIM, guessing whether you meant global or local. It
guesses fairly well, though.

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

Re: Beginner needs advice

[Jason Tackaberry]

On 11-05-29 04:06 AM, Ian Kelly wrote:
> I realize you are now asserting that compatibility is a boolean
> condition, and that "totally incompatible" is a redundant phrase that
> you tossed out as a joke.

As a casual lurker reading this thread, I believe he is equating
"completely incompatible" with "not completely compatible."  At least,
his arguments make more sense if I read him as arguing from the "not
completely compatible" position.  It's possible he is intentionally
equivocating for dramatic effect.

But they are different -- both connotatively and denotatively -- and to
argue against the claim that Python 2 and 3 are "completely
incompatible" it seems to me sufficient to provide a single non-trivial
counter-example, which Steven has already done.

Cheers,
Jason.
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scope of function parameters

[Henry Olders]

Henry




On 2011-05-29, at 5:47 , Wolfgang Rohdewald wrote:

> On Sonntag 29 Mai 2011, Henry Olders wrote:
>> It seems that in Python, a variable inside a function is
>> global unless it's assigned.
> 
> no, they are local
> 
>> I would have thought that a function parameter would
>> automatically be considered local to the function. It doesn't
>> make sense to me to pass a global to a function as a
>> parameter.
> 
> it is local. But consider what you actually passed:
> You did not pass a copy of the list but the list itself.
> You could also say you passed a reference to the list.
> All python variables only hold a pointer (the id) to
> an object. This object has a reference count and is
> automatically deleted when there are no more references
> to it.
> 
> If you want a local copy of the list you can either
> do what you called being ugly or do just that within
> the function itself - which I think is cleaner and
> only required once.
> 
> def fnc2(c):
>   c = c[:]
>c[1] = 'having'
>return c

Thank you, Wolfgang. That certainly works, but to me it is still a workaround 
to deal with the consequence of a particular decision. From my perspective, a 
function parameter should be considered as having been assigned (although the 
exact assignment will not be known until runtime), and as an assigned variable, 
it should be considered local.

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

Re: English Idiom in Unix: Directory Recursively

[rantingrick]

On May 18, 7:19 am, Peter Moylan 
wrote:

> It's interesting to note that the definitions of 'recursive' to be found
> in Wikipedia and Wiktionary have very little in common with the
> definitions to be found in the dictionaries covered by Onelook.  No
> wonder experts in different areas have trouble communicating with one
> another.

Yes, and when you extrapolate that conclusion into the current hodge
podge of natural languages you begin to understand the genesis of
human beings selfish nature.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scope of function parameters

[Terry Reedy]

On 5/29/2011 7:59 AM, Mel wrote:

Henry Olders wrote:


I just spent a considerable amount of time and effort debugging a program.
The made-up code snippet below illustrates the problem I encountered:

def main():
a = ['a list','with','three elements']
print a
print fnc1(a)
print a

def fnc1(b):
return fnc2(b)

def fnc2(c):
c[1] = 'having'
return c

This is the output:
['a list', 'with', 'three elements']
['a list', 'having', 'three elements']
['a list', 'having', 'three elements']

I had expected the third print statement to give the same output as the
first, but variable a had been changed by changing variable c in fnc2.

It seems that in Python, a variable inside a function is global unless
it's assigned. This rule has apparently been adopted in order to reduce
clutter by not having to have global declarations all over the place.

I would have thought that a function parameter would automatically be
considered local to the function.


Function *parameters* are names, the first *local names* of the function.


It doesn't make sense to me to pass a global to a function as a parameter.


You are right, in a way;-). Global *names* are just names. When you call 
a function, you pass *objects* as *arguments*. Of course, you may refer 
to the object by a global name to pass it, or you can pass a string 
object that contains a global name.


It doesn't look like a question of local or global. fnc2 is passed a
container object and replaces item 1 in that container.  You see the results
when fnc2 prints the object it knows as `c`, and you see again when main
prints the object it knows as `a`.  Python doesn't pass parameters by
handing around copies that can be thought of as local or global.  Python
passes parameters by binding objects to names in the callee's namespace.  In
your program the list known as `a` in main is identically the same list as
the one known as `c` in fnc2, and what happens happens.


Right. Python has one unnamed 'objectspace'. It has many, many 
namespaces: builtins, globals for each module, locals for each function 
and class, and attributes for some instances. Each name and each 
collection slot is associated with one object. Each object can have 
multiple associations, as in the example above.


--
Terry Jan Reedy

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

Re: English Idiom in Unix: Directory Recursively

[rantingrick]

On May 18, 12:59 pm, s...@sig.for.address (Victor Eijkhout) wrote:
> Harrison Hill  wrote:
> > No need - I have the Dictionary definition of recursion here:
>
> > Recursion: (N). See recursion.
>
> If you tell a joke, you have to tell it right.

Jeez, speaking of bad colloquialisms...

 """if you're going to "share" a joke you should at least "recite" it
CORRECTLY."""

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

Re: English Idiom in Unix: Directory Recursively

[rantingrick]

On May 18, 12:59 pm, s...@sig.for.address (Victor Eijkhout) wrote:
> Harrison Hill  wrote:
> > No need - I have the Dictionary definition of recursion here:
>
> > Recursion: (N). See recursion.
>
> If you tell a joke, you have to tell it right.

Jeez, speaking of bad colloquialisms...

 """if you're going to "share" a joke you should at least "recite" it
CORRECTLY."""

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

Re: English Idiom in Unix: Directory Recursively

[rantingrick]

On May 18, 3:00 pm, Xah Lee  wrote:

> In the emacs case: “Recursive delete of xx? (y or n) ”, what could it
> possibly mean by the word “recursive” there? Like, it might delete the
> directory but not delete all files in it?

Actually i think this case is more for "scare factor" than anything.
As in... Do you really want to destroy all these files FOREVER AND
EVER or did your mouse finger slip... again?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English Idiom in Unix: Directory Recursively

[rantingrick]

On May 20, 1:55 am, Steven D'Aprano  wrote:

> Trust me on this, if the audience of Carry On films could understand
> recursion, anyone can!

Well we could also say that this pathetic display of metal
masturbation is recursive also.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English Idiom in Unix: Directory Recursively

[rantingrick]

On May 24, 5:06 pm, Rikishi42  wrote:
> On 2011-05-24, Steven D'Aprano  wrote:

> > I wonder whether physicists insist that cars should have a "go faster
> > pedal" because ordinary people don't need to understand Newton's Laws of
> > Motion in order to drive cars?
>
> Gas pedal. Pedal was allraedy known when the car was invented. The simple
> addition of gas solved that need. Oh, and it's break pedal, not
> descellarator. (sp?)

Yes "Gas Pedal"... that clears up all the confusion .
However i would have thought if the vehicle had a "decelerator petal"
it would at least sport a complimentary "accelerator petal". You know
the whole "equal and opposite thing"?

> > Who are you to say that people shouldn't be exposed to words you deem
> > that they don't need to know?
>
> I'm one of the 'people'. You say exposed to, I say bothered/bored with.
>
> I have nothing against the use of a proper, precise term. And that word can
> be a complex one with many, many sylables (seems to add value, somehow).
>
> But I'm not an academic, so I don't admire the pedantic use of terms that
> need to be explained to 'lay' people. Especially if there is a widespread,
> usually shorter and much simpler one for it. A pointless effort if
> pointless, even when comming from a physicist.  :-)

You may be "right", but then again, who knows, you may be left? In
this upside down world of layperson colloquialisms -- which ironic-ly
enough are devised to "ease communication"... right? I mean i "used
to" think that choosing words that clearly described my intentions was
a good idea but heck, i would hate to think that those poor laypeople
had to languish though such tongue twisting syllable gymnastics just
for the sake of clear communications.



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

Re: English Idiom in Unix: Directory Recursively

[rantingrick]

On May 24, 7:40 pm, Chris Angelico  wrote:
> On Wed, May 25, 2011 at 8:06 AM, Rikishi42  wrote:
> > On 2011-05-24, Steven D'Aprano  wrote:

> >> I wonder whether physicists insist that cars should have a "go faster
> >> pedal" because ordinary people don't need to understand Newton's Laws of
> >> Motion in order to drive cars?
>
> > Gas pedal. Pedal was allraedy known when the car was invented. The simple
> > addition of gas solved that need. Oh, and it's break pedal, not
> > descellarator. (sp?)
>
> Americans might call it a gas pedal. We call it an accelerator. You
> don't have a "decelerator pedal" though, because it's more accurately
> called a "brake pedal" because it controls the brakes.

Actually the same argument could be applied to your observation of the
driver to vehicle interface. You say "brake petal" simple because it
controls the brakes. Well then what does the "accelerator" control
then?

Most wise observers would blubber... "I know, I know, it controls the
gas!"...and while partially correct they would be mostly wrong. Yes it
does control the "gas" but not in a direct way. Of course technically
it depends on implementation (a favorite word around c.l.py it seems
*rolls-eyes*).

In the days of carburetors the "accelerator" actually controlled a big
flap. This "big flap" (An attribute of which many round here seem to
posses and use generously) is opened to allow air to enter and the gas
is mixed into the air by secondary effect.

So if we really wanted to get pedantic we should call it an "air
petal"? However considering that any vehicle made after the early
nineties is fuel injected (which is controlled by a computer!) then we
may want to call it a "puter petal" to be precise.

Note: The remainder of your post was lucid and informative.

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

Re: English Idiom in Unix: Directory Recursively

[rantingrick]

On May 24, 7:40 pm, Chris Angelico  wrote:
> On Wed, May 25, 2011 at 8:06 AM, Rikishi42  wrote:
> > On 2011-05-24, Steven D'Aprano  wrote:

> >> I wonder whether physicists insist that cars should have a "go faster
> >> pedal" because ordinary people don't need to understand Newton's Laws of
> >> Motion in order to drive cars?
>
> > Gas pedal. Pedal was allraedy known when the car was invented. The simple
> > addition of gas solved that need. Oh, and it's break pedal, not
> > descellarator. (sp?)
>
> Americans might call it a gas pedal. We call it an accelerator. You
> don't have a "decelerator pedal" though, because it's more accurately
> called a "brake pedal" because it controls the brakes.

Actually the same argument could be applied to your observation of the
driver to vehicle interface. You say "brake petal" simple because it
controls the brakes. Well then what does the "accelerator" control
then?

Most wise observers would blubber... "I know, I know, it controls the
gas!"...and while partially correct they would be mostly wrong. Yes it
does control the "gas" but not in a direct way. Of course technically
it depends on implementation (a favorite word around c.l.py it seems
*rolls-eyes*).

In the days of carburetors the "accelerator" actually controlled a big
flap. This "big flap" (An attribute of which many round here seem to
posses and use generously) is opened to allow air to enter and the gas
is mixed into the air by secondary effect.

So if we really wanted to get pedantic we should call it an "air
petal"? However considering that any vehicle made after the early
nineties is fuel injected (which is controlled by a computer!) then we
may want to call it a "puter petal" to be precise.

Note: The remainder of your post was lucid and informative.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Nobody]

On Sun, 29 May 2011 10:29:28 +, Steven D'Aprano wrote:

>> The correct answer to "nan == nan" is to raise an exception, because
>> you have asked a question for which the answer is nether True nor False.
> 
> Wrong.

That's overstating it. There's a good argument to be made for raising an
exception. Bear in mind that an exception is not necessarily an error,
just an "exceptional" condition.

> The correct answer to "nan == nan" is False, they are not equal.

There is no correct answer to "nan == nan". Defining it to be false is
just the "least wrong" answer. Arguably, "nan != nan" should also be
false, but that would violate the invariant "(x != y) == !(x == y)".

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

Re: English Idiom in Unix: Directory Recursively

[Chris Angelico]

On Mon, May 30, 2011 at 6:58 AM, rantingrick  wrote:
> Yes "Gas Pedal"... that clears up all the confusion .
> However i would have thought if the vehicle had a "decelerator petal"
> it would at least sport a complimentary "accelerator petal". You know
> the whole "equal and opposite thing"?

Call the go-faster pedal the "Newton's Second Law pedal", and the
oops-here-comes-an-obstacle pedal the "Newton's Third Law pedal",
because if you hit that thing, you'll see the third law in action. We
then need a demonstration of Newton's First Law, which I think is the
ignition key. We should turn it into a pedal to be consistent.

For the humour-blind: 

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

Re: English Idiom in Unix: Directory Recursively

[rantingrick]

On May 26, 6:12 am, Chris Angelico  wrote:
> I just conducted a rapid poll of a non-technical userbase.
>
> (Okay, I just asked my sister who happens to be sitting here. But
> she's nontechnical.)
>
> She explained "recursive" as "it repeats until it can't go any
> further". I think that's a fair, if not perfectly accurate,
> explanation.

Yes but understanding of this sort is very general ESPECIALLY in the
case of destroying data!

What are the limits of the recursion? What forces can act on the
recursion to stop it? If (for example) I know that a "while loop" will
continue forever until "something" stops it then i really don't know
enough about while loops to start using them safely do i? I need to
know what a "break" will do or god forbid what if an exception is
thrown? What about if a condition is explicitly passed? I need to know
how to interpret the condition and it's consequences. Crikey, this is
getting complicated 8-O!

PS: Of course i could just cross my fingers, run the code, and hope
for the best but i'm not a Perl hacker.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English Idiom in Unix: Directory Recursively

[rantingrick]

On May 26, 6:12 am, Chris Angelico  wrote:
> I just conducted a rapid poll of a non-technical userbase.
>
> (Okay, I just asked my sister who happens to be sitting here. But
> she's nontechnical.)
>
> She explained "recursive" as "it repeats until it can't go any
> further". I think that's a fair, if not perfectly accurate,
> explanation.

Yes but understanding of this sort is very general ESPECIALLY in the
case of destroying data!

What are the limits of the recursion? What forces can act on the
recursion to stop it? If (for example) I know that a "while loop" will
continue forever until "something" stops it then i really don't know
enough about while loops to start using them safely do i? I need to
know what a "break" will do or god forbid what if an exception is
thrown? What about if a condition is explicitly passed? I need to know
how to interpret the condition and it's consequences. Crikey, this is
getting complicated 8-O!

PS: Of course i could just cross my fingers, run the code, and hope
for the best but i'm not a Perl hacker.
-- 
http://mail.python.org/mailman/listinfo/python-list

How to Use Setuptools, Alternatives?

[ray]

I have Python 2.7 on Win7 Pro on a tightly locked down desktop.  I
would like to install Networkx from an egg.  From what I have read,
Setuptools can be used for this.

I don't know how to install Setuptools.  The exe will not work.  On
execution, it reports that the Python version is not included in the
registry.  Further, I can not input the version and location on the
subsequent installation screen, the fields will not accept focus so I
can not input the values.

Since the exe will not install, I considered using the Setuptools
egg.  But it requires Setuptools.  It appears to be a circle.

What are some suggestions for installing this?

Thanks,
ray
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scope of function parameters

[Ben Finney]

Peter Pearson  writes:

> Python works in terms of objects having names, and one
> object can have many names.

Or no names. So it's less accurate (though better than talking of
“variables”) to speak of Python objects “having names”.

> The names b and c aren't boxes that hold things, they are -- in the
> words of one of this group's old hands -- sticky-note labels that have
> been slapped on the same object.

Right. And in that analogy, the object *still* doesn't “have a name”
(since that implies the false conclusion that the object knows its own
name); rather, the name is bound to the object, and the object is
oblivious of this.

I prefer to talk not of sticky notes, but paper tags with string; the
string leading from tag to object is an important part, and the paper
tag might not even have a name written on it, allowing the same analogy
to work for other non-name references like list indices etc.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\   Brain, but where are we going to find a duck and a hose at this |
_o__)hour?” —_Pinky and The Brain_ |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English Idiom in Unix: Directory Recursively

[Chris Angelico]

On Mon, May 30, 2011 at 7:38 AM, rantingrick  wrote:
> Yes but understanding of this sort is very general ESPECIALLY in the
> case of destroying data!
>
> What are the limits of the recursion? What forces can act on the
> recursion to stop it? If (for example) I know that a "while loop" will
> continue forever until "something" stops it then i really don't know
> enough about while loops to start using them safely do i?

That's true of anything. If I turn on the light switch, I expect there
to be a limit to the amount of light it produces; I don't want a
household fluro to produce the intensity of the worklights in a
theatre. Ought I to get the technical specs and find out exactly how
many lumens will be produced, or can I safely power it on in the
expectation that it will do the obvious thing?

Chris Angelico
PS. Why am I responding to rantingrick? I'm sure I'm going to regret this.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scope of function parameters

[Christopher Head]

On Sun, 29 May 2011 16:19:11 -0400
Henry Olders  wrote:

> > def fnc2(c):
> > c = c[:]
> >c[1] = 'having'
> >return c
> 
> Thank you, Wolfgang. That certainly works, but to me it is still a
> workaround to deal with the consequence of a particular decision.
> From my perspective, a function parameter should be considered as
> having been assigned (although the exact assignment will not be known
> until runtime), and as an assigned variable, it should be considered
> local.
> 
> Henry

This has nothing to do with function parameters and everything to do
with what a "variable name" actually means. You can get the same effect
with only globals:

>>> x=[1,2,3]
>>> y=x
>>> x.append(7)
>>> y
[1, 2, 3, 7]

Why in the world does "y" end with 7, even though it was appended to
"x"? Simple: because "x" and "y" are two names for the same list, as
Henry explained. No functions involved, no locals, no parameters, no
scoping. Again, if "y=x" were instead "y=x[:]" then the output would be
"[1,2,3]" because "y" would refer to a copy of the list rather than the
same list.

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

Alternatives to PythonPath

[ray]

I am using Win7 on a tightly locked down desktop.

Is there an alternative to using PythonPath?

What are the trade-offs?

Thanks,
ray
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Beginner needs advice

[rantingrick]

On May 28, 9:33 pm, harrismh777  wrote:
> Steven D'Aprano wrote:
> > A straw man is not when somebody points out holes in your argument, or
> > unwanted implications that you didn't realise were there. It is when
> > somebody makes claims on your behalf that you did not make to discredit
> > you, not because you don't understand the implications of your own
> > argument.
>
> The straw-man fallacy is when you erect a "straw man" to "represent" the
> actual man (or idea) which can be easily knocked down, and then you
> proceed to knock it down (the straw-man) as though the "straw man" was
> the actual man, or idea... proving your point as-it-were against your
> opponent when in fact you have only just knocked down the straw-man...
> leaving the real man standing.
>
> This fallacy has a couple of nuances (sometimes combined with metaphor
> or analogy fallacy) and you are a master at presenting both...
> thankfully you usually don't try to present both at the same time!  :)
>
> In this present case the straw-man was not "me," rather the straw-man
> was the python language itself. You chose a code-snippet (one small puny
> dangle that doesn't prove a thing) and used it to speak for the entire
> language!  As though one code-block is enough to demonstrate
> compatibility for the entire language in all of its nuances and details.
>   To prove something positive with a test case requires that you provide
> *all* test cases, or that you provide an algorithm that accounts for
> *all* test cases... you cannot prove compatibility with a code-snippet.
>
> On the other hand, all you have to do to prove incompatibility is to
> show "one" (1) test case where compatibility fails... and of course for
> the present case there are many that can be shown, in fact, hundreds of
> them.
>
> The thing that nobody has presented here yet is that *all* the books
> declare that 3.x is incompatible with 2.x/   ... some of them go out of
> their way to tell the reader that they are only going to deal with 3.x
> and not 2.x in any way... and others go out of their way to point out
> the hundreds of nuances in details between the two languages. (and a
> good thing too, for those of us who must work with both! )  So this fact
> is not alluding the press... the point being not to bust anybody in the
> chops, but to point out that it is not helpful to move the community
> forward with a new language and get mass adoption (not just early
> adopters) to lie about the differences between the two sets... yes, for
> trivial code blocks that use prime constructs, integer math, and the
> print statement, not much has changed.  But in real world applications
> of the language there are many hundreds of details that have changed or
> been added (deleted) which will make life difficult for the uninitiated.
> Don't mislead people by saying that very little has changed.  Tell them
> that the philosophy is the same (what Chris called python 'think' ) but
> be honest about the details of syntax, environment, layout, and
> morphology.


Bravo!

PS: And yes, Steven is a master at the straw man fallacy.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scope of function parameters

[Terry Reedy]

On 5/29/2011 4:19 PM, Henry Olders wrote:


From my perspective, a function parameter should be considered as
having been assigned (although the exact assignment will not be known
until runtime), and as an assigned variable, it should be considered
local.


That is exactly the case for Python functions.

>>> def f(a,b):
c,d = 3,4
print(locals())

>>> f.__code__.co_varnames # local names
('a', 'b', 'c', 'd')
>>> f(1,2)
{'a': 1, 'c': 3, 'b': 2, 'd': 4}

The requirement for a function call is that all parameters get an 
assignment and that all args are used in assignments (either directly by 
position or keyname or as part of a *args or **kwds assignment).


--
Terry Jan Reedy

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

Re: How to Use Setuptools, Alternatives?

[Irmen de Jong]

On 29-5-2011 23:41, ray wrote:
> I have Python 2.7 on Win7 Pro on a tightly locked down desktop.  I
> would like to install Networkx from an egg.  From what I have read,
> Setuptools can be used for this.

What does 'tightly locked down' mean?


> I don't know how to install Setuptools.  The exe will not work.  On
> execution, it reports that the Python version is not included in the
> registry.

That can be fixed by repairing the Python installation through its .msi.
Also, are you sure you used the python 2.7 setuptools exe?

> Further, I can not input the version and location on the
> subsequent installation screen, the fields will not accept focus so I
> can not input the values.
> 
> Since the exe will not install, I considered using the Setuptools
> egg.  But it requires Setuptools.  It appears to be a circle.
> 
> What are some suggestions for installing this?
> 
> Thanks,
> ray

Perhaps you can try VirtualEnv and PiP instead.

Irmen

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

Re: Alternatives to PythonPath

[Irmen de Jong]

On 29-5-2011 23:49, ray wrote:
> I am using Win7 on a tightly locked down desktop.
> 
> Is there an alternative to using PythonPath?
> 

What do you mean by "using PythonPath"?
What doesn't work that you want to have an alternative for?

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

[RELEASE] 3.1.4 release candidate 1

[Benjamin Peterson]

On behalf of the Python development team, I'm happy as a swallow to announce a
release candidate for the fourth bugfix release for the Python 3.1
series, Python
3.1.4.

3.1.4 will the last bug fix release in the 3.1 series before 3.1. After 3.1.4,
3.1 will be in security-only fix mode.

The Python 3.1 version series focuses on the stabilization and optimization of
the features and changes that Python 3.0 introduced.  For example, the new I/O
system has been rewritten in C for speed.  File system APIs that use unicode
strings now handle paths with undecodable bytes in them. Other features include
an ordered dictionary implementation, a condensed syntax for nested with
statements, and support for ttk Tile in Tkinter.  For a more extensive list of
changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in
the Python distribution.

This is a testing release. To download Python 3.1.4rc1 visit:

 http://www.python.org/download/releases/3.1.4/

A list of changes in 3.1.4 can be found here:

 http://hg.python.org/cpython/file/35419f276c60/Misc/NEWS

The 3.1 documentation can be found at:

 http://docs.python.org/3.1

Bugs can always be reported to:

 http://bugs.python.org


Enjoy!

--
Benjamin Peterson
Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 3.1.4's contributors)
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASE] Python 2.7.2 release candidate 1

[Benjamin Peterson]

On behalf of the Python development team, I'm happy to announce the immediate
availability of Python 2.7.2 release candidate 1.

2.7.2 is the second in bugfix release for the Python 2.7 series. 2.7 is the last
major verison of the 2.x line and will be receiving bug fixes while new feature
development focuses on 3.x.

2.7 includes many features that were first released in Python 3.1. The faster io
module, the new nested with statement syntax, improved float repr, set literals,
dictionary views, and the memoryview object have been backported from 3.1. Other
features include an ordered dictionary implementation, unittests improvements, a
new sysconfig module, auto-numbering of fields in the str/unicode format method,
and support for ttk Tile in Tkinter.  For a more extensive list of changes in
2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python
distribution.

To download Python 2.7.2rc1 visit:

 http://www.python.org/download/releases/2.7.1/

The 2.7.2 changelog is at:

 http://hg.python.org/cpython/file/439396b06416/Misc/NEWS

2.7 documentation can be found at:

 http://docs.python.org/2.7/

This is a preview release. Assuming no major problems, 2.7.2 will be released in
two weeks. Please report any bugs you find to

 http://bugs.python.org/


Enjoy!

--
Benjamin Peterson
Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 2.7.2's contributors)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English Idiom in Unix: Directory Recursively

[rantingrick]

On May 29, 4:46 pm, Chris Angelico  wrote:
> On Mon, May 30, 2011 at 7:38 AM, rantingrick  wrote:
> > Yes but understanding of this sort is very general ESPECIALLY in the
> > case of destroying data!
>
> > What are the limits of the recursion? What forces can act on the
> > recursion to stop it? If (for example) I know that a "while loop" will
> > continue forever until "something" stops it then i really don't know
> > enough about while loops to start using them safely do i?
>
> That's true of anything. If I turn on the light switch, I expect there
> to be a limit to the amount of light it produces; I don't want a
> household fluro to produce the intensity of the worklights in a
> theatre. Ought I to get the technical specs and find out exactly how
> many lumens will be produced, or can I safely power it on in the
> expectation that it will do the obvious thing?


That is a very good argument however it does not consider the fact of
"technical users" verses "non-technical users".

Anyone can be expected to understand the consequenses of switching on
a lightbulb (even a child) because the action requires no logical
thinking abilites... simply flip it and forget it.

HOWEVER not everyone understands the consequeses of recursively
deleting a directory... or whatever that means in the current context.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Beginner needs advice

[rantingrick]

On May 29, 2:28 pm, Jason Tackaberry  wrote:
> On 11-05-29 04:06 AM, Ian Kelly wrote:
>
> > I realize you are now asserting that compatibility is a boolean
> > condition, and that "totally incompatible" is a redundant phrase that
> > you tossed out as a joke.
>
> As a casual lurker reading this thread, I believe he is equating
> "completely incompatible" with "not completely compatible."  At least,
> his arguments make more sense if I read him as arguing from the "not
> completely compatible" position.  It's possible he is intentionally
> equivocating for dramatic effect.
>
> But they are different -- both connotatively and denotatively -- and to
> argue against the claim that Python 2 and 3 are "completely
> incompatible" it seems to me sufficient to provide a single non-trivial
> counter-example, which Steven has already done.

Python 2.x and Pythin 3.x are two different dialects just like Humans
(Python 3.x) and Chimpanzees (Python 2.x) are similar (compatible) but
very different versions of talking apes (languages). Sure humans
(Python 3.x) and chimps (Python 2.x) share some similarities (much
more than say humans (Python3.x) and fish (Lisp) do) however there are
many incompatible differences.

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

Re: Beginner needs advice

[Chris Angelico]

On Mon, May 30, 2011 at 9:00 AM, rantingrick  wrote:
> Python 2.x and Pythin 3.x are two different dialects just like Humans
> (Python 3.x) and Chimpanzees (Python 2.x) are similar (compatible) but
> very different versions of talking apes (languages). Sure humans
> (Python 3.x) and chimps (Python 2.x) share some similarities (much
> more than say humans (Python3.x) and fish (Lisp) do) however there are
> many incompatible differences.
>

Chimpanzees do not use language in the same way that humans do, and in
any case, it's pretty ridiculous to talk of the 'Human language' in
anything other than a fantasy roleplaying game. It's more comparable
to call Py2 "scientific English"and Py3 "medical English". There are
differences (what's a calorie?), but for the most part, they are the
same language.

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

Re: float("nan") in set or as key

[Steven D'Aprano]

On Sun, 29 May 2011 22:19:49 +0100, Nobody wrote:

> On Sun, 29 May 2011 10:29:28 +, Steven D'Aprano wrote:
> 
>>> The correct answer to "nan == nan" is to raise an exception,
>>> because
>>> you have asked a question for which the answer is nether True nor
>>> False.
>> 
>> Wrong.
> 
> That's overstating it. There's a good argument to be made for raising an
> exception. 

If so, I've never heard it, and I cannot imagine what such a good 
argument would be. Please give it.

(I can think of *bad* arguments, like "NANs confuse me and I don't 
understand the reason for their existence, therefore I'll give them 
behaviours that make no sense and aren't useful". But you did state there 
is a *good* argument.)



> Bear in mind that an exception is not necessarily an error,
> just an "exceptional" condition.

True, but what's your point? Testing two floats for equality is not an 
exceptional condition.


>> The correct answer to "nan == nan" is False, they are not equal.
> 
> There is no correct answer to "nan == nan". 

Why on earth not?


> Defining it to be false is just the "least wrong" answer.

So you say, but I think you are incorrect.


> Arguably, "nan != nan" should also be false,
> but that would violate the invariant "(x != y) == !(x == y)".

I cannot imagine what that argument would be. Please explain.



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

Re: Error: child process close a socket inherited from parent

[Chris Torek]

In article 
narke   wrote:
>As illustrated in the following simple sample:
>
>import sys
>import os
>import socket
>
>class Server:
>def __init__(self):
>self._listen_sock = None
>
>def _talk_to_client(self, conn, addr):
>text = 'The brown fox jumps over the lazy dog.\n'
>while True:
>conn.send(text)
>data = conn.recv(1024)
>if not data:
>break
>conn.close()
>
>def listen(self, port):
>self._listen_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>self._listen_sock.bind(('', port))
>self._listen_sock.listen(128)
>self._wait_conn()
>
>def _wait_conn(self):
>while True:
>conn, addr = self._listen_sock.accept()
>if os.fork() == 0:
>self._listen_sock.close()   # line x
>self._talk_to_client(conn, addr)
>else:
>conn.close()
>
>if __name__ == '__main__':
>Server().listen(int(sys.argv[1]))
>
>Unless I comment out the line x, I will get a 'Bad file descriptor'
>error when my tcp client program (e.g, telnet) closes the connection to
>the server.  But as I understood, a child process can close a unused
>socket (file descriptor).

It can.

>Do you know what's wrong here?

The problem turns out to be fairly simple.

The routine listen() forks, and the parent process (with nonzero pid)
goes into the "else" branch of _wait_conn(), hence closes the newly
accepted socket and goes back to waiting on the accept() call, which
is all just fine.

Meanwhile, the child (with pid == 0) calls close() on the listening
socket and then calls self._talk_to_client().

What happens when the client is done and closes his end?  Well,
take a look at the code in _talk_to_client(): it reaches the
"if not data" clause and breaks out of its loop, and calls close()
on the accepted socket ... and then returns to its caller, which
is _wait_conn().

What does _wait_conn() do next?  It has finished "if" branch in
the "while True:" loops, so it must skip the "else" branch and go
around the loop again.  Which means its very next operation is
to call accept() on the listening socket it closed just before
it called self._talk_to_client().

If that socket is closed, you get an EBADF error raised.  If not,
the child and parent compete for the next incoming connection.
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)  http://web.torek.net/torek/index.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scope of function parameters

[Steven D'Aprano]

On Sun, 29 May 2011 04:30:52 -0400, Henry Olders wrote:

> I just spent a considerable amount of time and effort debugging a
> program. The made-up code snippet below illustrates the problem I
> encountered:
[...]
> Are there others who feel as I do that a function parameter should
> always be local to the function? Or am I missing something here?

The nature of Henry's misunderstanding is a disguised version of the very 
common "is Python call by reference or call by value?" question that 
periodically crops up. I wrote a long, but I hope useful, explanation for 
the tu...@python.org mailing list, which I'd like to share here:

http://mail.python.org/pipermail/tutor/2010-December/080505.html


Constructive criticism welcome.


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

Re: float("nan") in set or as key

[Chris Torek]

Incidentally, note:

$ python
...
>>> nan = float("nan")
>>> nan
nan
>>> nan is nan
True
>>> nan == nan
False

In article <4de1e3e7$0$2195$742ec...@news.sonic.net>
John Nagle   wrote:
>The correct answer to "nan == nan" is to raise an exception, because
>you have asked a question for which the answer is nether True nor False.

Well, in some sense, the "correct answer" depends on which question
you *meant* to ask. :-)  Seriously, some (many?) instruction sets
have two kinds of comparison instructions: one that raises an
exception here, and one that does not.

>The correct semantics for IEEE floating point look something like
>this:
>
>   1/0 INF
>   INF + 1 INF
>   INF - INF   NaN
>   INF == INF  unordered
>   NaN == NaN  unordered
>
>INF and NaN both have comparison semantics which return
>"unordered". The FPU sets a bit for this, which most language
>implementations ignore.

Again, this depends on the implementation.

This is similar to (e.g.) the fact that on the MIPS, there are two
different integer add instructions ("addi" and "addiu"): one
raises an overflow exception, the other performs C "unsigned"
style arithmetic (where, e.g., 0x + 1 = 0, in 32 bits).

>Python should raise an exception on unordered comparisons.
>Given that the language handles integer overflow by going to
>arbitrary-precision integers, checking the FPU status bits is
>cheap.

I could go for that myself.  But then you also need a "don't raise
exception but give me an equality test result" operator (for various
special-case purposes at least) too.  Of course a simple "classify
this float as one of normal, subnormal, zero, infinity, or NaN"
operator would suffice here (along with the usual "extract sign"
and "differentiate between quiet and signalling NaN" operations).
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)  http://web.torek.net/torek/index.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Carl Banks]

On Sunday, May 29, 2011 4:31:19 PM UTC-7, Steven D'Aprano wrote:
> On Sun, 29 May 2011 22:19:49 +0100, Nobody wrote:
> 
> > On Sun, 29 May 2011 10:29:28 +, Steven D'Aprano wrote:
> > 
> >>> The correct answer to "nan == nan" is to raise an exception,
> >>> because
> >>> you have asked a question for which the answer is nether True nor
> >>> False.
> >> 
> >> Wrong.
> > 
> > That's overstating it. There's a good argument to be made for raising an
> > exception. 
> 
> If so, I've never heard it, and I cannot imagine what such a good 
> argument would be. Please give it.

Floating point arithmetic evolved more or less on languages like Fortran where 
things like exceptions were unheard of, and defining NaN != NaN was a bad trick 
they chose for testing against NaN for lack of a better way.

If exceptions had commonly existed in that environment there's no chance they 
would have chosen that behavior; comparison against NaN (or any operation with 
NaN) would have signaled a floating point exception.  That is the correct way 
to handle exceptional conditions.

The only reason to keep NaN's current behavior is to adhere to IEEE, but given 
that Python has trailblazed a path of correcting arcane mathematical behavior, 
I definitely see an argument that Python should do the same for NaN, and if it 
were done Python would be a better language.


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

Re: How to catch a line with Popen

[Chris Torek]

In article 
TheSaint   wrote:
>Chris Rebert wrote:
>I just suppose to elaborate the latest line, as soon it's written on the 
>pipe, and print some result on the screen.
>Imaging something like
>
> p= Popen(['ping','-c40','www.google.com'], stdout=PIPE)
> for line in p.stdout:
> print(str(line).split()[7])
>
>I'd like to see something like *time=54.4*
>This is just an example, where if we remove the "-c40" on the command line, 
>I'd expect to read the latest line(s), until the program will be killed.

In at least some versions of Python 2, file-like object "next"
iterators do not "work right" with unbuffered (or line-buffered)
pipe-file-objects.  (This may or may not be fixed in Python 3.)

A simple workaround is a little generator using readline():

def line_at_a_time(fileobj):
"""
Return one line at a time from a file-like object.
Works around the iter behavior of pipe files in
Python 2.x, e.g., instead of "for line in file" you can
write "for line in line_at_a_time(file)".
"""
while True:
line = fileobj.readline()
if not line:
return
yield line

Adding this to your sample code gives something that works for me,
provided I fiddle with it to make sure that the only lines
examined are those with actual ping times:

p = subprocess.Popen(["ping", "-c5", "www.google.com"],
stdout = subprocess.PIPE)
for lineno, line in enumerate(line_at_a_time(p.stdout)):
if 1 <= lineno <= 5:
print line.split()[6]
else:
print line.rstrip('\n')
p.wait() # discard final result

(Presumably the enumerate() trick would not be needed in whatever
you really use.)
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)  http://web.torek.net/torek/index.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Carl Banks]

On Sunday, May 29, 2011 7:41:13 AM UTC-7, Grant Edwards wrote:
> It treats them as identical (not sure if that's the right word).  The
> implementation is checking for ( A is B or A == B ).  Presumably, the
> assumpting being that all objects are equal to themselves.  That
> assumption is not true for NaN objects, so the buggy behavior is
> observed.

Python makes this assumption in lots of common situations (apparently in an 
implementation-defined manner):

>>> nan = float("nan")
>>> nan == nan
False
>>> [nan] == [nan]
True

Therefore, I'd recommend never to rely on NaN != NaN except in casual throwaway 
code.  It's too easy to forget that it will stop working when you throw an item 
into a list or tuple.  There's a function, math.isnan(), that should be the One 
Obvious Way to test for NaN.  NaN should also never be used as a dictionary key 
or in a set (of course).

If it weren't for compatibility with IEEE, there would be no sane argument that 
defining an object that is not equal to itself isn't a bug.  But because 
there's a lot of code out there that depends on NaN != NaN, Python has to 
tolerate it.


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

Re: float("nan") in set or as key

[Chris Angelico]

On Mon, May 30, 2011 at 10:55 AM, Carl Banks  wrote:
> If exceptions had commonly existed in that environment there's no chance they 
> would have chosen that behavior; comparison against NaN (or any operation 
> with NaN) would have signaled a floating point exception.  That is the 
> correct way to handle exceptional conditions.
>
> The only reason to keep NaN's current behavior is to adhere to IEEE, but 
> given that Python has trailblazed a path of correcting arcane mathematical 
> behavior, I definitely see an argument that Python should do the same for 
> NaN, and if it were done Python would be a better language.

If you're going to change behaviour, why have a floating point value
called "nan" at all? Other than being a title for one's grandmother,
what meaning does that string have, and why should it be able to be
cast as floating point?

Lifting from http://en.wikipedia.org/wiki/NaN a list of things that
can return a NaN (I've removed non-ASCII characters from this
snippet):
* Operations with a NaN as at least one operand.
(you need to bootstrap that somehow, so we can ignore this - it just
means that nan+1 = nan)

* The divisions 0/0 and infinity/infinity
* The multiplications 0*infinity and infinity*0
* The additions +inf + (-inf), (-inf) + +inf and equivalent subtractions
* The standard pow function and the integer exponent pown function
define 0**0, 1**inf, and inf**0 as 1.
* The powr function define all three indeterminate forms as invalid
operations and so returns NaN.
* The square root of a negative number.
* The logarithm of a negative number
* The inverse sine or cosine of a number that is less than -1 or
greater than +1.

Rather than having comparisons with NaN trigger exceptions, wouldn't
it be much cleaner to have all these operations trigger exceptions?
And, I would guess that they probably already do.

NaN has an additional use in that it can be used like a "null
pointer"; a floating-point variable can store 1.0, or 0.0005,
or "no there's no value that I'm storing in this variable". Since a
Python variable can contain None instead of a float, this use is
unnecessary too.

So, apart from float("nan"), are there actually any places where real
production code has to handle NaN? I was unable to get a nan by any of
the above methods, except for operations involving inf; for instance,
float("inf")-float("inf") == nan. All the others raised an exception
rather than return nan.

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

Re: scope of function parameters

[Ben Finney]

Steven D'Aprano  writes:

> http://mail.python.org/pipermail/tutor/2010-December/080505.html
>
>
> Constructive criticism welcome.

Informative, but it “buries the lead” as our friends in the press corps
would say.


Instead you should write as though you have no idea where the reader
will stop reading, and still give them the most useful part. Write the
most important information first, and don't bury it at the end.

In this case, I'd judge the most important information to be “what is
the Python passing model?” Give it a short name; the effbot's “pass by
object” sounds good to me.

Then explain what that means.

Then, only after giving the actual information you want the reader to go
away with, you can spend the rest of the essay giving a history behind
the craziness.

More on this style:


http://www.computerworld.com/s/article/print/93903/I_m_OK_The_Bull_Is_Dead>

-- 
 \   Moriarty: “Forty thousand million billion dollars? That money |
  `\must be worth a fortune!” —The Goon Show, _The Sale of |
_o__)   Manhattan_ |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: portable way of sending notifying a process

[Chris Torek]

In article <4de183e7$0$26108$426a7...@news.free.fr>
News123   wrote:
>I'm looking for a portable way (windows XP / Windows Vista and Linux )
>to send a signal from any python script to another one
>(one signa would be enough)

This turns out to be pretty hard to do reliably-and-securely
even *without* crossing the Windows / Linux barrier.

>It seems, that neither the signals HUP / USR1 are implemented under windows.

Signals are also very messy and easy to get wrong on Unix, with
earlier Python versions missing a few key items to make them
entirely reliable (such as the sigblock/sigsetmask/sigpause suite,
and/or setting interrupt-vs-resume behavior on system calls).

>What would be a light weight portable way, that one process can tell
>another to do something?
>
>The main requirement would be to have no CPU impact while waiting (thus
>no polling)

Your best bet here is probably to use sockets.  Both systems have
ways to create service sockets and to connect to a socket as a
client.  Of course, making these secure can be difficult: you must
decide what sort of attack(s) could occur and how much effort to
put into defending against them.

(For instance, even if there is only a "wake up, I have done
something you should look at" signal that you can transmit by
connecting to a server and then closing the connection, what happens
if someone inside or outside your local network decides to repeatedly
poke that port in the hopes of causing a Denial of Service by making
the server use lots of CPU time?)

>If nothing exists I might just write a wrapper around
>pyinotify and (Tim Goldens code snippet allowing to watch a directory
>for file changes)
>http://timgolden.me.uk/python/win32_how_do_i/watch_directory_for_changes.html
>
>and use a marker file in a marker directory
>but I wanted to be sure of not reinventing the wheel.

It really sounds like you are writing client/server code in which
the client writes a file into a queue directory.  In this case,
that may be the way to go -- or you could structure it as an actual
client and server, i.e., the client connects to the server and
writes the request directly (but then you have to decide about
security considerations, which the OS's local file system may
provide more directly).
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)  http://web.torek.net/torek/index.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scope of function parameters

[Chris Angelico]

On Mon, May 30, 2011 at 11:31 AM, Ben Finney  wrote:
>  http://www.computerworld.com/s/article/print/93903/I_m_OK_The_Bull_Is_Dead>

I agree with the gist of that. My take on this is: When I'm talking to
my boss, I always assume that the phone will ring ten seconds into my
explanation. Ten seconds is enough for "Dad, I'm OK; the bull is
dead", it's enough for "I've solved Problem X, we can move on now";
it's enough for "Foo is crashing, can't ship till I debug it". If
fortune is smiling on me and the phone isn't ringing, I can explain
that Problem X was the reason Joe was unable to demo his new module,
or that the crash in Foo is something that I know I'll be able to pin
down in a one-day debugging session, but even if I don't, my boss
knows enough to keep going with.

Of course, there's a significant difference between a mailing list
post and a detailed and well copyedited article. Quite frequently I'll
ramble on list, in a way quite inappropriate to a publication that
would be linked to as a "hey guys, here's how it is" page. Different
media, different standards.

Chris Angelico
"Forty thousand million billion THEGS quotes? That must be worth a fortune!"
-- definitely a fan of THEGS --
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: portable way of sending notifying a process

[Chris Angelico]

On Mon, May 30, 2011 at 11:44 AM, Chris Torek  wrote:
>>What would be a light weight portable way, that one process can tell
>>another to do something?
>>
>>The main requirement would be to have no CPU impact while waiting (thus
>>no polling)
>
> Your best bet here is probably to use sockets.  Both systems have
> ways to create service sockets and to connect to a socket as a
> client.

Further to this: If your two processes are going to start up, then run
concurrently for some time, and during that time alert each other (or
one alerts the other) frequently, a socket is an excellent choice. Use
a TCP socket on Windows, and either a TCP socket or a Unix socket on
Linux (I'd just use TCP on both for simplicity, but Unix sockets are
faster), and simply write a byte to it whenever you want to alert the
other side. You can largely guarantee that no other process can
accidentally or maliciously wake you, as long as you have some kind of
one-off handshake on connection - even something really simple like
sending a random nonce, having the other end send hash(nonce +
password), and compare.

Chris Angelico
Huge fan of TCP sockets (hello MUDs!)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scope of function parameters

[Ben Finney]

Chris Angelico  writes:

> Of course, there's a significant difference between a mailing list
> post and a detailed and well copyedited article. Quite frequently I'll
> ramble on list, in a way quite inappropriate to a publication that
> would be linked to as a "hey guys, here's how it is" page. Different
> media, different standards.

Right. But Steven specifically asked for constructive criticism, which I
took as permission to treat the referenced post as an article in need of
copy editing :-)

-- 
 \ “The truth is the most valuable thing we have. Let us economize |
  `\ it.” —Mark Twain, _Following the Equator_ |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Carl Banks]

On Sunday, May 29, 2011 6:14:58 PM UTC-7, Chris Angelico wrote:
> On Mon, May 30, 2011 at 10:55 AM, Carl Banks 
>  wrote:
> > If exceptions had commonly existed in that environment there's no chance 
> > they would have chosen that behavior; comparison against NaN (or any 
> > operation with NaN) would have signaled a floating point exception.  That 
> > is the correct way to handle exceptional conditions.
> >
> > The only reason to keep NaN's current behavior is to adhere to IEEE,
> > but given that Python has trailblazed a path of correcting arcane
> > mathematical behavior, I definitely see an argument that Python
> > should do the same for NaN, and if it were done Python would be a
> > better language.
> 
> If you're going to change behaviour, why have a floating point value
> called "nan" at all?

If I were designing a new floating-point standard for hardware, I would 
consider getting rid of NaN.  However, with the floating point standard that 
exists, that almost all floating point hardware mostly conforms to, there are 
certain bit pattern that mean NaN.

Python could refuse to construct float() objects out of NaN (I doubt it would 
even be a major performance penalty), but there's reasons why you wouldn't, the 
main one being to interface with other code that does use NaN.  It's better, 
then, to recognize the NaN bit patterns and do something reasonable when trying 
to operate on it.


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

Re: Alternatives to PythonPath

[rusi]

On May 30, 2:49 am, ray  wrote:
> I am using Win7 on a tightly locked down desktop.
>
> Is there an alternative to using PythonPath?
>
> What are the trade-offs?
>
> Thanks,
> ray

Externally:
1. PYTHONPATH

2. .pth files
http://bob.pythonmac.org/archives/2005/02/06/using-pth-files-for-python-development/
http://docs.python.org/library/site.html

And of course there the internal sys.path

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

Re: scope of function parameters

[Chris Angelico]

On Mon, May 30, 2011 at 12:08 PM, Ben Finney  wrote:
> Chris Angelico  writes:
>
>> Of course, there's a significant difference between a mailing list
>> post and a detailed and well copyedited article. Quite frequently I'll
>> ramble on list, in a way quite inappropriate to a publication that
>> would be linked to as a "hey guys, here's how it is" page. Different
>> media, different standards.
>
> Right. But Steven specifically asked for constructive criticism, which I
> took as permission to treat the referenced post as an article in need of
> copy editing :-)

Indeed. Was just saying that there are times when you need to get the
slug out first, and times when it's okay to be a little less impactual
(if that's a word). Although it's still important to deliver your
message promptly.

Of course, there are other contexts where you specifically do NOT want
to give everything away at the beginning. Certain styles of rhetoric
demand that you set the scene, build your situation, and only at the
climax reveal what it is you are trying to say.

Ahh! wordsmithing, how we love thee.

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

Re: float("nan") in set or as key

[Chris Angelico]

On Mon, May 30, 2011 at 12:17 PM, Carl Banks  wrote:
> If I were designing a new floating-point standard for hardware, I would 
> consider getting rid of NaN.  However, with the floating point standard that 
> exists, that almost all floating point hardware mostly conforms to, there are 
> certain bit pattern that mean NaN.
>
> Python could refuse to construct float() objects out of NaN (I doubt it would 
> even be a major performance penalty), but there's reasons why you wouldn't, 
> the main one being to interface with other code that does use NaN.  It's 
> better, then, to recognize the NaN bit patterns and do something reasonable 
> when trying to operate on it.

Okay, here's a question. The Python 'float' value - is it meant to be
"a Python representation of an IEEE double-precision floating point
value", or "a Python representation of a real number"? For the most
part, Python's data types are defined by their abstract concepts - a
list isn't defined as a linked list of pointers, it's defined as an
ordered collection of objects. Python 3 removes the distinction
between 'int' and 'long', where 'int' is <2**32 and 'long' isn't, so
now a Py3 integer is... any integer.

The sys.float_info struct exposes details of floating point
representation. In theory, a Python implementation that uses bignum
floats could quite happily set all those values to extremes and work
with enormous precision (or could use a REXX-style "numeric digits
100" command to change the internal rounding, and automatically update
sys.float_info). And in that case, there would be no NaN value.

If Python is interfacing with some other code that uses NaN, that code
won't be using Python 'float' objects - it'll be using IEEE binary
format, probably. So all it would need to entail is a special return
value from an IEEE Binary to Python Float converter function (maybe
have it return None), and NaN is no longer a part of Python.

The real question is: Would NaN's removal be beneficial? And if so,
would it be worth the effort?

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

Re: float("nan") in set or as key

[rusi]

On May 30, 7:53 am, Chris Angelico  wrote:
> On Mon, May 30, 2011 at 12:17 PM, Carl Banks  wrote:
> > If I were designing a new floating-point standard for hardware, I would 
> > consider getting rid of NaN.  However, with the floating point standard 
> > that exists, that almost all floating point hardware mostly conforms to, 
> > there are certain bit pattern that mean NaN.
>
> > Python could refuse to construct float() objects out of NaN (I doubt it 
> > would even be a major performance penalty), but there's reasons why you 
> > wouldn't, the main one being to interface with other code that does use 
> > NaN.  It's better, then, to recognize the NaN bit patterns and do something 
> > reasonable when trying to operate on it.
>
> Okay, here's a question. The Python 'float' value - is it meant to be
> "a Python representation of an IEEE double-precision floating point
> value", or "a Python representation of a real number"? For the most
> part, Python's data types are defined by their abstract concepts - a
> list isn't defined as a linked list of pointers, it's defined as an
> ordered collection of objects. Python 3 removes the distinction
> between 'int' and 'long', where 'int' is <2**32 and 'long' isn't, so
> now a Py3 integer is... any integer.
>
> The sys.float_info struct exposes details of floating point
> representation. In theory, a Python implementation that uses bignum
> floats could quite happily set all those values to extremes and work
> with enormous precision (or could use a REXX-style "numeric digits
> 100" command to change the internal rounding, and automatically update
> sys.float_info). And in that case, there would be no NaN value.
>
> If Python is interfacing with some other code that uses NaN, that code
> won't be using Python 'float' objects - it'll be using IEEE binary
> format, probably. So all it would need to entail is a special return
> value from an IEEE Binary to Python Float converter function (maybe
> have it return None), and NaN is no longer a part of Python.
>
> The real question is: Would NaN's removal be beneficial? And if so,
> would it be worth the effort?
>
> Chris Angelico

nan in floating point is like null in databases
It may be worthwhile to have a look at what choices SQL has made
http://en.wikipedia.org/wiki/Null_%28SQL%29

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

Re: Error: child process close a socket inherited from parent

[narke]

On 2011-05-29, Chris Torek  wrote:
> In article 
> narke   wrote:
>>As illustrated in the following simple sample:
>>
>>import sys
>>import os
>>import socket
>>
>>class Server:
>>def __init__(self):
>>self._listen_sock = None
>>
>>def _talk_to_client(self, conn, addr):
>>text = 'The brown fox jumps over the lazy dog.\n'
>>while True:
>>conn.send(text)
>>data = conn.recv(1024)
>>if not data:
>>break
>>conn.close()
>>
>>def listen(self, port):
>>self._listen_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>self._listen_sock.bind(('', port))
>>self._listen_sock.listen(128)
>>self._wait_conn()
>>
>>def _wait_conn(self):
>>while True:
>>conn, addr = self._listen_sock.accept()
>>if os.fork() == 0:
>>self._listen_sock.close()   # line x
>>self._talk_to_client(conn, addr)
>>else:
>>conn.close()
>>
>>if __name__ == '__main__':
>>Server().listen(int(sys.argv[1]))
>>
>>Unless I comment out the line x, I will get a 'Bad file descriptor'
>>error when my tcp client program (e.g, telnet) closes the connection to
>>the server.  But as I understood, a child process can close a unused
>>socket (file descriptor).
>
> It can.
>
>>Do you know what's wrong here?
>
> The problem turns out to be fairly simple.
>
> The routine listen() forks, and the parent process (with nonzero pid)
> goes into the "else" branch of _wait_conn(), hence closes the newly
> accepted socket and goes back to waiting on the accept() call, which
> is all just fine.
>
> Meanwhile, the child (with pid == 0) calls close() on the listening
> socket and then calls self._talk_to_client().
>
> What happens when the client is done and closes his end?  Well,
> take a look at the code in _talk_to_client(): it reaches the
> "if not data" clause and breaks out of its loop, and calls close()
> on the accepted socket ... and then returns to its caller, which
> is _wait_conn().
>
> What does _wait_conn() do next?  It has finished "if" branch in
> the "while True:" loops, so it must skip the "else" branch and go
> around the loop again.  Which means its very next operation is
> to call accept() on the listening socket it closed just before
> it called self._talk_to_client().
>
> If that socket is closed, you get an EBADF error raised.  If not,
> the child and parent compete for the next incoming connection.


Chris,

 Thanks, you helped to find out a bug in my code. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Steven D'Aprano]

On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:

> Floating point arithmetic evolved more or less on languages like Fortran
> where things like exceptions were unheard of, 

I'm afraid that you are completely mistaken.

Fortran IV had support for floating point traps, which are "things like 
exceptions". That's as far back as 1966. I'd be shocked if earlier 
Fortrans didn't also have support for traps.

http://www.bitsavers.org/pdf/ibm/7040/C28-6806-1_7040ftnMathSubrs.pdf


The IEEE standard specifies that you should be able to control whether a 
calculation traps or returns a NAN. That's how Decimal does it, that's 
how Apple's (sadly long abandoned) SANE did it, and floats should do the 
same thing.

Serious numeric languages like Fortran have supported traps long before 
exceptions were invented.



> and defining NaN != NaN
> was a bad trick they chose for testing against NaN for lack of a better
> way.

That's also completely wrong. The correct way to test for a NAN is with 
the IEEE-mandated function isnan(). The NAN != NAN trick is exactly that, 
a trick, used by programmers when their language or compiler doesn't 
support isnan().

Without support for isinf(), identifying an INF is just as hard as 
identifying an NAN, and yet their behaviour under equality is the 
complete opposite:

>>> inf = float('inf')
>>> inf == inf
True


> If exceptions had commonly existed in that environment there's no chance
> they would have chosen that behavior; 

They did exist, and they did choose that behaviour.


> comparison against NaN (or any
> operation with NaN) would have signaled a floating point exception. 
> That is the correct way to handle exceptional conditions.
> 
> The only reason to keep NaN's current behavior is to adhere to IEEE, 

And because the IEEE behaviour is far more useful than the misguided 
reliance on exceptions for things which are not exceptional.

Before spreading any more misinformation about IEEE 754 and NANs, please 
learn something about it:

http://grouper.ieee.org/groups/754/
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps

I particularly draw your attention to the FAQ about NANs:

http://grouper.ieee.org/groups/754/faq.html#exceptions


[quote]
The 754 model encourages robust programs. It is intended not only for 
numerical analysts but also for spreadsheet users, database systems, or 
even coffee pots. The propagation rules for NaNs and infinities allow 
inconsequential exceptions to vanish. Similarly, gradual underflow 
maintains error properties over a precision's range. 

When exceptional situations need attention, they can be examined 
immediately via traps or at a convenient time via status flags. Traps can 
be used to stop a program, but unrecoverable situations are extremely 
rare. Simply stopping a program is not an option for embedded systems or 
network agents. More often, traps log diagnostic information or 
substitute valid results. 

Flags offer both predictable control flow and speed. Their use requires 
the programmer be aware of exceptional conditions, but flag stickiness 
allows programmers to delay handling exceptional conditions until 
necessary.
[end quote]



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

Re: float("nan") in set or as key

[Steven D'Aprano]

On Mon, 30 May 2011 11:14:58 +1000, Chris Angelico wrote:

> So, apart from float("nan"), are there actually any places where real
> production code has to handle NaN? I was unable to get a nan by any of
> the above methods, except for operations involving inf; for instance,
> float("inf")-float("inf") == nan. All the others raised an exception
> rather than return nan.

That's Python's poor design, due to reliance on C floating point 
libraries that have half-hearted support for IEEE-754, and the 
obstruction of people who don't understand the usefulness of NANs. They 
shouldn't raise unless the caller specifies that he wants exceptions. The 
default behaviour should be the most useful one, namely quiet 
(propagating) NANs, rather than halting the calculation because of 
something which may or may not be an error and may or may not be 
recoverable.

Even Apple's Hypertalk supported them better in the late 1980s than 
Python does now, and that was a language aimed at non-programmers!

The Decimal module is a good example of what floats should do. All flags 
are supported, so you can choose whether you want exceptions or NANs. I 
don't like Decimal's default settings, but at least they can be changed.



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