Re: float(nan) in set or as key
On 5/28/2011 6:04 PM, Gregory Ewing wrote:
MRAB wrote:
float(nan) can occur multiple times in a set or as a key in a dict:
{float(nan), float(nan)}
{nan, nan}
except that sometimes it can't:
nan = float(nan)
{nan, nan}
{nan}
NaNs are weird. They're not equal to themselves:
Python 2.7 (r27:82500, Oct 15 2010, 21:14:33)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type help, copyright, credits or license for more information.
nan = float(nan)
nan == nan
False
This confuses the daylights out of Python's dict lookup machinery,
which assumes that two references to the same object can't possibly
compare unequal, so it doesn't bother calling __eq__ on them.
Right.
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.
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. But you can turn on floating point
exception traps, and on x86 machines, they're exact - the
exception will occur exactly at the instruction which
triggered the error. In superscalar CPUs, a sizable part of
the CPU handles the unwinding necessary to do that. x86 does
it, because it's carefully emulating non-superscalar machines.
Most RISC machines don't bother.
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.
The advantage of raising an exception is that the logical operations
still work. For example,
not (a == b)
a != b
will always return the same results if exceptions are raised for
unordered comparison results. Also, exactly one of
a = b
a b
a b
is always true - something sorts tend to assume.
If you get an unordered comparison exception, your program
almost certainly was getting wrong answers.
(I used to do dynamics simulation engines, where this mattered.)
John Nagle
--
http://mail.python.org/mailman/listinfo/python-list
Re: Class decorators might also be super too
He is basically showing that using mixins for implementing logging is not such a good idea, i.e. you can get the same effect in a better way by making use of other Python features. I argued the same thing many times in the past. I even wrote a module once (strait) to reimplement 99% of multiple inheritance without multiple inheritance, just to show that in can be done in few lines of code in a language as powerful as Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Beginner needs advice
On Sat, May 28, 2011 at 8:33 PM, harrismh777 harrismh...@charter.net 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
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
On Sun, 29 May 2011 10:32:43 +1000, Chris Angelico wrote: On Sun, May 29, 2011 at 10:28 AM, Albert Hopkins mar...@letterboxes.org 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
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
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
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
On Sun, May 29, 2011 at 1:30 AM, Henry Olders henry.old...@mcgill.ca 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. snip 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
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
On Sun, May 29, 2011 at 3:02 AM, TheSaint nob...@nowhere.net.no 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
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
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
On May 29, 7:33 am, Michele Simionato michele.simion...@gmail.com 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
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:
a href=http://x264.nl/x264/64bit/8bit_depth/revision
1995
/x264
.exe
view-source-tab: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
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
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
Andrew Berg bahamutzero8...@gmail.com 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?
URL: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+pyt...@benfinney.id.au writes: the two-character “CR LF” sequence (U+000C U+000A) URL: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
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
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
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
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
On 2011-05-29, narke narkewo...@gmail.com 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
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 http://wiki.python.org/moin/Python2orPython3 ; 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 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
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
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
On 2011-05-29, Wolfgang Rohdewald wolfg...@rohdewald.de 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
On 2011-05-29, Gregory Ewing greg.ew...@canterbury.ac.nz 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
In article mailman..1306676482.9059.python-l...@python.org, Andrew Berg bahamutzero8...@gmail.com 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
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
In article irtm3d$qk3$2...@reader1.panix.com,
Grant Edwards invalid@invalid.invalid wrote:
On 2011-05-29, Gregory Ewing greg.ew...@canterbury.ac.nz 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
On May 29, 10:35 am, Andrew Berg bahamutzero8...@gmail.com 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(rhttp://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
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
On May 29, 12:16 pm, Andrew Berg bahamutzero8...@gmail.com 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
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
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
On 29/05/2011 15:41, Grant Edwards wrote: On 2011-05-29, Wolfgang Rohdewaldwolfg...@rohdewald.de 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
On Mon, May 30, 2011 at 3:44 AM, MRAB pyt...@mrabarnett.plus.com 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
On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On Mon, May 30, 2011 at 2:16 AM, Andrew Berg bahamutzero8...@gmail.com 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' rraw 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
On Sun, May 29, 2011 at 10:53 AM, Chris Angelico ros...@gmail.com wrote: On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 stdin, line 1, in module File stdin, 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
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
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
On Mon, 30 May 2011 03:53:24 +1000, Chris Angelico wrote: On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On Mon, May 30, 2011 at 4:01 AM, Chris Rebert c...@rebertia.com wrote: def foo(): print bar bar = 42 foo() === Traceback (most recent call last): File stdin, line 1, in module File stdin, 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
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
On Mon, 30 May 2011 04:38:26 +1000, Chris Angelico wrote: On Mon, May 30, 2011 at 4:01 AM, Chris Rebert c...@rebertia.com wrote: def foo(): print bar bar = 42 foo() === Traceback (most recent call last): File stdin, line 1, in module File stdin, 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 stdin, line 1, in ? File stdin, 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
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. OT 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.] /OT -- \\//, 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
On Sun, May 29, 2011 at 12:38 PM, Chris Angelico ros...@gmail.com 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
On Mon, May 30, 2011 at 4:53 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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;i10;++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
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 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
On May 18, 7:19 am, Peter Moylan inva...@peter.pmoylan.org.invalid 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
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
On May 18, 12:59 pm, s...@sig.for.address (Victor Eijkhout) wrote: Harrison Hill harrish...@gmx.com 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
On May 18, 12:59 pm, s...@sig.for.address (Victor Eijkhout) wrote: Harrison Hill harrish...@gmx.com 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
On May 18, 3:00 pm, Xah Lee xah...@gmail.com 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
On May 20, 1:55 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info 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
On May 24, 5:06 pm, Rikishi42 skunkwo...@rikishi42.net wrote: On 2011-05-24, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 /sarcasm. 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
On May 24, 7:40 pm, Chris Angelico ros...@gmail.com wrote: On Wed, May 25, 2011 at 8:06 AM, Rikishi42 skunkwo...@rikishi42.net wrote: On 2011-05-24, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On May 24, 7:40 pm, Chris Angelico ros...@gmail.com wrote: On Wed, May 25, 2011 at 8:06 AM, Rikishi42 skunkwo...@rikishi42.net wrote: On 2011-05-24, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
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
On Mon, May 30, 2011 at 6:58 AM, rantingrick rantingr...@gmail.com wrote: Yes Gas Pedal... that clears up all the confusion /sarcasm. 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: /jesting Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On May 26, 6:12 am, Chris Angelico ros...@gmail.com 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
On May 26, 6:12 am, Chris Angelico ros...@gmail.com 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?
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
Peter Pearson ppearson@nowhere.invalid 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
On Mon, May 30, 2011 at 7:38 AM, rantingrick rantingr...@gmail.com 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
On Sun, 29 May 2011 16:19:11 -0400 Henry Olders henry.old...@mcgill.ca 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
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
On May 28, 9:33 pm, harrismh777 harrismh...@charter.net 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
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?
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
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
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
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
On May 29, 4:46 pm, Chris Angelico ros...@gmail.com wrote: On Mon, May 30, 2011 at 7:38 AM, rantingrick rantingr...@gmail.com 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
On May 29, 2:28 pm, Jason Tackaberry t...@urandom.ca 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
On Mon, May 30, 2011 at 9:00 AM, rantingrick rantingr...@gmail.com 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 Englishand 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
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
In article slrniu42cm.2s8.narkewo...@cnzuhnb904.ap.bm.net
narke narkewo...@gmail.com 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
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
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 na...@animats.com 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
On Sunday, May 29, 2011 4:31:19 PM UTC-7, Steven D#39;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
In article irtj2o$h0m$1...@speranza.aioe.org
TheSaint nob...@nowhere.net.no 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
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
On Mon, May 30, 2011 at 10:55 AM, Carl Banks pavlovevide...@gmail.com 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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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: URL: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
In article 4de183e7$0$26108$426a7...@news.free.fr News123 news1...@free.fr 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
On Mon, May 30, 2011 at 11:31 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: URL: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
On Mon, May 30, 2011 at 11:44 AM, Chris Torek nos...@torek.net 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
Chris Angelico ros...@gmail.com 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
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
On May 30, 2:49 am, ray r...@aarden.us 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
On Mon, May 30, 2011 at 12:08 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: Chris Angelico ros...@gmail.com 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
On Mon, May 30, 2011 at 12:17 PM, Carl Banks pavlovevide...@gmail.com 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
On May 30, 7:53 am, Chris Angelico ros...@gmail.com wrote: On Mon, May 30, 2011 at 12:17 PM, Carl Banks pavlovevide...@gmail.com 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
On 2011-05-29, Chris Torek nos...@torek.net wrote:
In article slrniu42cm.2s8.narkewo...@cnzuhnb904.ap.bm.net
narke narkewo...@gmail.com 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
