[Python-Dev] trunk and 2.5 are borken
There are several failures with both the trunk and 2.5 branch. I have fixed one problem that allows the tests to run on Windows. That was fixed by reverting 54407 on the trunk. It still needs to be reverted on the 2.5 branch. You can go back in the buildbot logs to find out more about the problem. The 3 test failures on Windows are: test_urllib test_mailbox and test_posixpath. The first 2 fail due to 'Access denied' on @test.2. I'm guessing this is due to the file not being closed before trying to delete it. I don't know where this problem showed up, but it was after rev 54406 which is when all the tests were passing on Windows (and 54407 was backed out). test_posixpath is failing in: test_relpath Patch 1490190 causes test_posix to fail on Tru64 due to chflags(). I remember some changes to PTYs which are causing test_pty to fail on Solaris. Can someone(s) try to fix these problems? Don't forget to verify that 2.5 is ok. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
On Mon, Mar 19, 2007 at 12:20:59PM +1200, Greg Ewing wrote: Damien Miller wrote: That annoyed me too, so I submitted a patch[1] that was recently committed. That looks good. Seems to me it should really be the default behaviour, but I suppose that would break code that was relying on the automatic deletion. I prefer the default of clean up after itself as is to avoid leaving temporary file turds on systems caused by us lazy programmers. -greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SoC AST generation question
Jay Parlar schrieb: 1) Who would most likely mentor this project? As Brett says, it all depends on the applications we receive and those that get accepted. That said, it might be me. 2) I've never worked in the core before (but have been using Python as my primary language for about 6 years), so I'm wondering if the potential mentor thinks it'd even be feasible for me to jump at a project like this without prior knowledge. Notice that there are really two separate AST projects listed: one is to improve usage of the AST compiler, by, say, adding more passes to it, or allowing round-tripping from the Python representation. The other one is to generate ast.c, which currently is hand-written, but could probably be generated automatically. This would not improve any end-user features, but would improve the maintainability, as currently, changing the AST is tedious as you have to change so much other stuff as well. I'm interested in this project for two reasons. The first is that I'm still trying to pick my PhD thesis, and I'm leaning in the direction of automated code generation for embedded systems. I feel like working on this project would at least push me one way or another in terms of picking. I've done a major code generation tool before, but it was for a problem domain I was already an expert in, so I didn't develop any generic methods. If you want to focus on the automated code generation aspect, pick the generation of ast.c. Generating C code from a domain-specific model is a must-know of the compiler engineer. If you want to focus on embedded systems, manipulating on the ast level may be closer as you will see how backend processing works (which you often find important when generating code for a specific target system). HTH, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
On 16 Mar, 2007, at 23:37, Stephen Hansen wrote: That may actually be a genuinely useful approach: splitext(name, ignore_leading_dot=False, all_ext=False) ... that's perfect. I updated my patch to do it that way! :) I don't agree. all_ext=True is won't do the right thing in a significant subset of filenames:: archiveType = os.path.splitext(sourceArchive, all_ext=True) This won't do what you'd want with most source distributions on the internet (product-X.Y.Z.tar.gz). The ignore_leading_dot argument seems to be there to keep everyone happy and furthermore is an argument that will be passed a constant value in the majority of usecases (I'd say all uses, but that's just asking for someone to come up with a lame counterexample). The ignore_leading_dot argument also doesn't buy you anything that can't trivially be implemented in other ways. Ronald --S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ ronaldoussoren%40mac.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non-blocking sockets, asynchronous connects and select.select.
Thanks Josiah and Neal, you were right. I am running the code on Windows, Server 2003. I should have mentioned that at the start. When I change the hostname from to localhost, the code works exactly as expected. It's odd that this behaviour exists, only on Windows. The jython code that I'm writing worked fine with an empty hostname . That jython code uses the java.net and java.nio APIs directly, and does not have any special cases for empty hostname. Which must mean that the underlying java implementations must be correctly handling the empty hostname, even when running on Windows. (Perhaps by special casing for the Windows implementation, if indeed a peculiarity of the Windows socket libraries is the cause). Which implies to me that cpython, like java, should not have different behaviour on Windows vs. other platforms; it lessens portability. Lack of portability is confirmed by Neal's report that the original unmodified snippet (i.e. with hostname == ) works correctly under cpython on Linux. Thanks guys, Alan. On 3/20/07, Josiah Carlson [EMAIL PROTECTED] wrote: [snip] SERVER_ADDRESS = (, 54321) Replacing the above with: SERVER_ADDRESS = (localhost, 54321) ...makes it work for me on Windows CPython 2.3.5 and 2.5 . - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
On March 15, Georg Brandl wrote: I'll review it tomorrow. Do you have any news about this? Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
[Facundo Batista] Do you have any news about this? Re: Patch 1676823 http://sourceforge.net/tracker/index.php?func=detailaid=1676823group_id=5470atid=305470 Since I've just written a lot of socket stuff for jython, I thought I'd have a look at the patch. I like the idea of adding better socket control to the higher-level modules like httplib, etc, because these modules don't provide access to the underlying sockets, and using the socket module methods setdefaulttimeout, etc, is a little messy. I see that your updated socket.connect() method takes a timeout parameter, which defaults to None if not present, e.g. def connect(address, timeout=None): Later in the function, this line appears if timeout is not None: sock.settimeout(timeout) The problem with this is that None has a meaning as a timeout value; it means put this socket in blocking mode. But that value can no longer be used for socket connects, since that value is being interpreted as parameter was not provided. So, if a non-standard timeout has been set, using something like import socket ; socket.setdefaulttimeout(10.0) how do I restore full blocking behaviour to a single socket? (a somewhat contrived case, I admit). If I have access to the socket object, then I can call sock_obj.settimeout(None), but in that case I don't need the new API. I could also do it with the call sock_obj.setblocking(1). If I don't have access to the socket object, i.e. I'm using timeouts indirectly through httplib/etc, then I'm stuck: there's no way I can change the blocking or timeout behaviour; back to square one. So the new proposed API partly addresses the problem of increasing control over the underlying socket, but doesn't address all cases. It specifically prevents setting a timeout value of None on a socket, which is an important use case, I think. Regards, Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SoC AST generation question
On 3/20/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Notice that there are really two separate AST projects listed: one is to improve usage of the AST compiler, by, say, adding more passes to it, or allowing round-tripping from the Python representation. The other one is to generate ast.c, which currently is hand-written, but could probably be generated automatically. This would not improve any end-user features, but would improve the maintainability, as currently, changing the AST is tedious as you have to change so much other stuff as well. Part of my desired PhD research goals are in the creation of tools that aid in the development of correct software, so a tool that improves maintainability fits perfectly. If you want to focus on the automated code generation aspect, pick the generation of ast.c. Generating C code from a domain-specific model is a must-know of the compiler engineer. If you want to focus on embedded systems, manipulating on the ast level may be closer as you will see how backend processing works (which you often find important when generating code for a specific target system). The code generator I mentioned in my first post created C code from a DSL. I learned a good deal on that, but because I was generating code for a platform I was already an expert in, I didn't really develop many general code generation strategies or techniques. Because I'm not an expert on Python's ast.c, my hope is that along the way to creating the tool, I'll be able to learn or develop more general strategies. But maybe that's a crazy thought :) Jay P. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Alan Kennedy wrote: I see that your updated socket.connect() method takes a timeout parameter, which defaults to None if not present, e.g. I did NOT update a connect() method. I created a connect() function, in the module socket.py (there's also a connect() method in the socket object, but I didn't touch it). import socket ; socket.setdefaulttimeout(10.0) how do I restore full blocking behaviour to a single socket? (a somewhat contrived case, I admit). You can not, unless you have access to the socket object itself. If I have access to the socket object, then I can call sock_obj.settimeout(None), but in that case I don't need the new API. I could also do it with the call sock_obj.setblocking(1). Exactly. If I don't have access to the socket object, i.e. I'm using timeouts indirectly through httplib/etc, then I'm stuck: there's no way I can change the blocking or timeout behaviour; back to square one. No. This method is for easily do that job from higher level libraries. The code that is in my patch, it's right now copied N times in higher level libraries (httplib, ftplib, smtplib, etc). In all those libraries, the socket is opened, used, and never changed the state between non-blocking, timeout, and nothing. Experience (personal and complains in mailing lists) shows that a timeout is needed: a lot of times people wants to make urllib2.urlopen(., timeout=10), for example. But never heard of anybody wanting to go to timeout and then back to blocking mode, with the same socket, using high level libraries. So the new proposed API partly addresses the problem of increasing control over the underlying socket, but doesn't address all cases. It specifically prevents setting a timeout value of None on a socket, which is an important use case, I think. False. If you want to set a timeout value of None on a socket, you surely can, I haven't touch any line of code in socket-the-object! Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
At 09:24 AM 3/20/2007 +0100, Ronald Oussoren wrote: I don't agree. all_ext=True is won't do the right thing in a significant subset of filenames Yes, that's understood. The problem is that splitext() in general won't do the right thing, for many definitions of the right thing, unless you're applying it to a fairly constrained range of filenames, or unless you add other code. This won't change, unless we get rid of splitext() altogether. If you're trying to match an archive extension, for example, you'll probably need to loop on repeated splitext() calls until you find an extension that matches. One benefit of using both the new keyword arguments together is that it allows you to make your loop proceed from longest match to shortest, so that if you are matching product-X.Y.Z.tar.gz, you're going to go through matching .Y.Z.tar.gz, then .Z.tar.gz, then .tar.gz. The ignore_leading_dot argument also doesn't buy you anything that can't trivially be implemented in other ways. I don't understand. Example? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Cross Compiling Python
Hi All, I have to cross compile Python to run on Arm processor based MontaVista Linux. If anyone has tried this already, please let me know the procedure. Thanks in advance, Regards, Kumar ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
[Alan Kennedy]
I see that your updated socket.connect() method takes a timeout
parameter, which defaults to None if not present, e.g.
[Facundo Batista]
I did NOT update a connect() method. I created a connect() function, in
the module socket.py (there's also a connect() method in the socket
object, but I didn't touch it).
Sorry, my mistake.
I realise now that you're creating a whole new function, dedicated to
the special (but extremely common) case of creating a fully connected
client socket. My fault for not realising that first off.
So, a question I would ask is: Is connect the right name for that function?
- Will users get confused between the connect function and
socket.connect method? They are doing different things.
- Will the naming give rise to the question the socket-module-level
function connect() takes a timeout parameter, why doesn't the
socket-method connect() take a timeout parameter as well?
Perhaps a better name might be create_connected_client_socket, or
something equally descriptive?
Another question I would ask is: How do I ensure that my newly
created connected client socket is in blocking mode, *without* making
any assumptions about the value of socket.getdefaulttimeout()?
If the answer to this question is you can't, then I would suggest a
function signature and implementation like this instead
def connect(address, **kwargs):
[snip]
if kwargs.has_key('timeout'):
sock.settimeout(kwargs['timeout'])
[snip]
This would of course mean that the user would have to explicitly name
the 'timeout' parameter, but that's a good thing in this case, IMO.
Regards,
Alan.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
Ronald Oussoren schrieb:
I don't understand. Example?
You conveniently ignored my other arguments ;-).
Given a splitext that ignores leading dot's the following function doesn't:
# from os.path import *
def splitext2(path):
dn = dirname(path)
bn, ext = splitext(basename(path))
if bn.startswith('.') and ext == '':
return dn, bn + ext
else:
return join(dn, bn), ext
I'd say that's a trivial function.
By that measure, the entire splitext function is trivial. However,
if you look closely, you find that even such a 'trivial' function
can contain many errors already, and it needs several revisions to
get it right.
This particular function has two errors (as far as I can see):
- if there are multiple leading dots, your version will return
all of them in ext, even though it's promised that ext will
contain exactly one dot. IOW, splitext2('...txt') should
give ('..', '.txt'), but does give ('', '...txt')
- The join() call will insert the module's separator, even
though the original string may have used the altsep. This
violates the promise that base+ext == path.
What I don't understand is why 'ignore_leading_dot==False' is considered
to be a valid usecase at all, except for the fact that os.path.splitext
did this until py2.5. I'm definitely in the camp that considers
'.profile' not to have an extension.
That is precisely the core of the discussion. It's not that
ignore_leading_dots=False is considered useful, in the call (except
for a few people that claim that splitext('.txt') ought to give
'','.txt'), but that the valid use case apparently is to not
pass any parameters, so that 100%, never-changing
backwards-compatibility is preserved.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cross Compiling Python
I have to cross compile Python to run on Arm processor based MontaVista Linux. If anyone has tried this already, please let me know the procedure. Dear Kiran, The python-dev mailing list is for the development *of* Python, not for the development *with* Python; use python-list@python.org for the latter. That said, please take a look at the cross-compilation patch that is currently under review in the patches tracker at sf.net/projects/python. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Alan Kennedy wrote: Sorry, my mistake. No problem. So, a question I would ask is: Is connect the right name for that function? ... Perhaps a better name might be create_connected_client_socket, or something equally descriptive? Guido proposed connect_with_timeout. I don't like your proposal, neither Guido's. But, I recognize that maybe it's not the best name. What about create_connection? Another question I would ask is: How do I ensure that my newly created connected client socket is in blocking mode, *without* making any assumptions about the value of socket.getdefaulttimeout()? Call like this: newsock = socket.connect((..., ...)) newsock.setblocking(1) Remember that this function is to replace the same code in N other places, and in any of other places I saw this usage. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
[Facundo] But, I recognize that maybe it's [connect] not the best name. What about create_connection? I have no strong feelings about it, other than to say it should not be connect. How about * connect_to_server() * open_connection() * open_client_connection() There's no need to include timeout in the name, IMO. [Alan] Another question I would ask is: How do I ensure that my newly created connected client socket is in blocking mode, *without* making any assumptions about the value of socket.getdefaulttimeout()? [Facundo] Call like this: newsock = socket.connect((..., ...)) newsock.setblocking(1) Ah, but it's too late by the time the socket.connect call returns: the timeout/blocking behaviour of the socket.connect call is the very thing we're trying to control. Whenever I look at the proposed API, I think: What happens when the socket.connect call is preceded by a call which changes the default socket timeout/blocking behaviour, e.g. socket.setdefaulttimeout(1) newsock = socket.connect(HOST, PORT, None) # -- None param ignored newsock.setblocking(1) # -- This does not affect the behaviour of the connect I.E. I do not get the blocking behaviour I want. The proposed API does not permit me to get blocking behaviour by specifying a timeout value of None. Whereas with the slightly modified API I suggested earlier, it simply becomes socket.setdefaulttimeout(1) newsock = socket.connect(HOST, PORT, timeout=None) # newsock.setblocking(1) # -- No longer relevant Regards, Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
At 04:47 PM 3/20/2007 +0100, Ronald Oussoren wrote:
On 20 Mar, 2007, at 15:54, Phillip J. Eby wrote:
At 09:24 AM 3/20/2007 +0100, Ronald Oussoren wrote:
I don't agree. all_ext=True is won't do the right thing in a
significant subset of filenames
Yes, that's understood. The problem is that splitext() in general
won't do the right thing, for many definitions of the right
thing, unless you're applying it to a fairly constrained range of
filenames, or unless you add other code. This won't change, unless
we get rid of splitext() altogether.
I know that, I actually read most of the messages in this thread. The
reason I'm pointing this out for the 'all_ext=True' case is that
adding this flag could give naive users even more reason to believe
that splitext will magicly do the right thing.
Well, that's where we need to shore up the documentation, which needs to
point out the folly of expecting DWIM. We should give some examples of
where splitext() will *not* DWIM.
If you're trying to match an archive extension, for example, you'll
probably need to loop on repeated splitext() calls until you find
an extension that matches. One benefit of using both the new
keyword arguments together is that it allows you to make your loop
proceed from longest match to shortest, so that if you are matching
product-X.Y.Z.tar.gz, you're going to go through
matching .Y.Z.tar.gz, then .Z.tar.gz, then .tar.gz.
I don't know if this is worth the additional API complexity.
Especially given the inherit problems of a splitext function.
The ignore_leading_dot argument also doesn't buy you anything that
can't
trivially be implemented in other ways.
I don't understand. Example?
You conveniently ignored my other arguments ;-).
Given a splitext that ignores leading dot's the following function
doesn't:
# from os.path import *
def splitext2(path):
dn = dirname(path)
bn, ext = splitext(basename(path))
if bn.startswith('.') and ext == '':
return dn, bn + ext
else:
return join(dn, bn), ext
I'd say that's a trivial function.
What I don't understand is why 'ignore_leading_dot==False' is
considered to be a valid usecase at all, except for the fact that
os.path.splitext did this until py2.5. I'm definitely in the camp
that considers '.profile' not to have an extension.
Okay, the part I'm confused about is what's your position on what should be
*done* about this. Are you favoring no change? Deprecating it and ripping
it out? Or what?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Amusing fan mail I got
i thought about this thing. (...) +1! -- Gustavo Niemeyer http://niemeyer.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
On 20 Mar, 2007, at 19:24, Phillip J. Eby wrote: What I don't understand is why 'ignore_leading_dot==False' is considered to be a valid usecase at all, except for the fact that os.path.splitext did this until py2.5. I'm definitely in the camp that considers '.profile' not to have an extension. Okay, the part I'm confused about is what's your position on what should be *done* about this. Are you favoring no change? Deprecating it and ripping it out? Or what? os.path.splitext works fine for what it is supposed to do, even though there currently is some confusion on what that is. IMHO the change Martin checked in into 2.6 was a good one and makes that API as good as it can get without unduly cluttering the API. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
At 05:07 PM 3/20/2007 +0100, Martin v. Löwis wrote:
Ronald Oussoren schrieb:
What I don't understand is why 'ignore_leading_dot==False' is considered
to be a valid usecase at all, except for the fact that os.path.splitext
did this until py2.5. I'm definitely in the camp that considers
'.profile' not to have an extension.
That is precisely the core of the discussion. It's not that
ignore_leading_dots=False is considered useful, in the call (except
for a few people that claim that splitext('.txt') ought to give
'','.txt')
Actually, *this* is precisely the problem: arguing that the opinion of
these few people is irrelevant, because a few *other* people think
they're wrong to find that behavior useful.
I'm able to see that considering '.profile' to not have an extension is a
*reasonable* position to take, and that doing it from the start *might*
have been a good idea.
What I disagree with is punishing people who considered the opposite
approach equally valid, and took the documentation and tests at their word.
Breaking their code without warning would be rude enough, but unfortunately
it affects not only the person who directly uses splitext(), but everyone
who uses any library, tool, or application that relies on the current behavior.
The very fact that you keep treating the current behavior as *not* useful
is the very core of our disagreement. Indeed, it seems to me quite
disrespectful that you will not take anyone at their word that they do
indeed expect, desire, and *value* the existing behavior, and wish to
continue to have access to it in future versions of Python.
Suppose that the behavior had been the other way around to begin with, and
Windows users started filing bugs about it, because it disagrees with
Windows Explorer's interpretation of the extension? Would you simply
change the Unix-oriented behavior because it's clearly a bug?
If not, then what is your rationale for changing it the other way? Make no
mistake: both behaviors are desirable, for different reasons. And both
interpretations merely reflect platform-specific shell policies, so neither
is any more true or correct in some absolute sense. (If anything,
Windows at least derives from an operating system that actually *has*
extensions as part of its filesystem, whereas Unix does not.)
The people who would like to keep the old behavior have all, to my
recollection, acknowledged that other behaviors are desirable. Why won't
the people who want to *change* the behavior acknowledge the same thing?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Alan Kennedy wrote: [Facundo] But, I recognize that maybe it's [connect] not the best name. What about create_connection? I have no strong feelings about it, other than to say it should not be connect. How about Ok. create_connection, then. Ah, but it's too late by the time the socket.connect call returns: the timeout/blocking behaviour of the socket.connect call is the very thing we're trying to control. It's not the very thing, just one of them... whatever, you have a point. Whereas with the slightly modified API I suggested earlier, it simply becomes I'm OK with that API, except that you're losing position parameters. It's OK to *always* need to put the timeout=? The problem here is that I used None to check if you passed a parameter or not, an idiom well stablished in Python, but in this very case None has a meaning for itself. I'm +0 on having the obligation to a named parameter here. So, I have two modifications to make to the patch: - change the name to create_connection - make timeout obligatory named Is everybody ok with this? Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r54457 - python/trunk/Doc/whatsnew/whatsnew26.tex
On Tue, Mar 20, 2007 at 06:08:24AM +0100, neal.norwitz wrote: Author: neal.norwitz Date: Tue Mar 20 06:08:23 2007 New Revision: 54457 +% Should there be a new section here for 3k migration? +% Or perhaps a more general section describing module changes/deprecation? +% sets module deprecated This is an interesting question: should the What's New talk about Python 3000? My initial tentative reaction is 'no', because a Py3K section would need to continue to be updated as Python 3000's definition shifts. Once previous Python 2.x versions were released, What's New documents became very static, the only changes being typo fixes and small corrections and clarifications. Having to continually update the Py3K section would be annoying, and argues for a separate document that isn't necessarily tied to Python 2.x releases. On the other hand, it would be nice to warn users away from idioms that will break in Py3K, and the What's New is a natural place to do it. Hm. But the 'porting' section already talks about features that are being deprecated; is that enough? Thoughts? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
On 3/20/07, Facundo Batista [EMAIL PROTECTED] wrote: So, I have two modifications to make to the patch: - change the name to create_connection - make timeout obligatory named Is everybody ok with this? FWLIW, +1. It was not immediately apparent to me that the third argument in:: newsock = socket.create_connection(HOST, PORT, None) is supposed to be a timeout. The modified version:: newsock = socket.create_connection(HOST, PORT, timeout=None) is much clearer to me. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Patchs and bugs resume
People: At the beginning of March, there was a thread in this list about patchs and bugs that teorically weren't checked out. From that discussion, I asked myself: How can I know the temporal location of a patch/bug?. Are there a lot of old patchs/bugs? Those that are old, don't have any update or there're a big discussion with each one? Are they abandoned? To help me with this analisys, I made a tool that taking information from SourceForge it creates a resume table, for the patchs... http://www.taniquetil.com.ar/facundo/py_patchs.html ...and the bugs: http://www.taniquetil.com.ar/facundo/py_bugs.html My idea is to update them periodically (something like each day, at the end of the html you have the update date and time). Enjoy it. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Steven Bethard wrote: is supposed to be a timeout. The modified version:: newsock = socket.create_connection(HOST, PORT, timeout=None) Warning. The correct function signature is create_connection(address[, timeout=None]) where address is a tuple (HOST, PORT). BTW, how can I indicate in the tex file (docs), that the parameter, if present, is mandatorily named? Thanks! -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Josiah Carlson wrote: sentinel = object() def connect(HOST, PORT, timeout=sentinel): ... if timeout is not sentinel: sock.settimeout(timeout) ... A keyword argument via **kwargs is also fine. I have no preference. I do. The way you showed here, I'm not restricting user options. I think this is better. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Facundo Batista [EMAIL PROTECTED] wrote: Josiah Carlson wrote: sentinel = object() def connect(HOST, PORT, timeout=sentinel): ... if timeout is not sentinel: sock.settimeout(timeout) ... A keyword argument via **kwargs is also fine. I have no preference. I do. The way you showed here, I'm not restricting user options. I think this is better. But the kwargs doesn't restrict options either... def connect(address, **kwargs): ... if 'timeout' in kwargs: sock.settimeout(kwargs['timeout']) ... With that method you can include timeout=None, and it also doesn't restrict what the user could pass as a value to timeout. It requires that you pass timeout explicitly, but that's a (relatively inconsequential) API decision. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Josiah Carlson wrote: restrict what the user could pass as a value to timeout. It requires that you pass timeout explicitly, but that's a (relatively inconsequential) API decision. This is exactly the point. It's an API decision, that you must communicate to the user, he/she must read it and remember it. Letting timeout be positional or named, it's just less error prone. So, if I can make it this way, it's what I prefer, :) Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
[Facundo] So, I have two modifications to make to the patch: - change the name to create_connection - make timeout obligatory named I was going to suggest a third change: for orthogonality with the API for socket objects, add a blocking parameter as well, i.e. def create_connection(address, timeout=sentinel, blocking=sentinel): [snip] if timeout != sentinel: new_socket.settimeout(timeout) if blocking != sentinel: new_socket.setblocking(blocking) [snip] but that may be taking it too far. But there is still an issue remaining, relating to non-blocking IO. With or without a blocking parameter, the user can still set non-blocking behaviour on a socket by setting a timeout of 0. The following snippet illustrates the issue. #-=-=-=-=-=-=-=-=-=-=-=-=-= import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(0) s.connect( (localhost, 80) ) #-=-=-=-=-=-=-=-=-=-=-=-=-= If you run this, it is very likely to generate an exception, but not guaranteed: you may have to run it a few times. Or try a host that is slower to respond. The problem is now that the connect call is now a non-blocking connect, which means that it may throw a socket.error, even after a successful connect, as follows socket.error: (10035, 'The socket operation could not complete without blocking') The standard mechanism in C for doing a non-blocking connect is to issue the connect call, and check the return value for a non-zero error code. If this error code is errno.EAGAIN (code 10035), then the call succeeded, but you should check back later for completion of the operation. It was for this reason that the connect_ex method was introduced to python socket objects. Instead of raising an exception, it directly returns the error code from the socket operation, so that it can be checked, as in C. So in the case of the new create_connection function, either A: The user should be prepared to handle an exception if they use a zero timeout (i.e. set non-blocking mode) or B: Detect the non-blocking case inside the function implementation and return the value of the connect_ex method instead of the connect method, as would be standard in a non-blocking app. This could be implemented as follows def create_connection(address, timeout=sentinel): [snip] if timeout != sentinel: new_socket.settimeout(timeout) if new_socket.gettimeout() == 0: result = new_socket.connect_ex(address) else: new_socket.connect(address) result = new_socket [snip] I know that this makes it all more complex, and I'm *not* saying the new function should be modified to include these concerns. The new function is designed to address straightforward usability cases, so it's perhaps appropriate that the API be restricted to those cases, i.e. to supporting timeout values 0. Perhaps this limit could be coded into the function? Also, people who want explicitly do non-blocking socket IO will likely use the socket API directly, so it may not be worth supporting that use in this function. Regards, Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Gregory P. Smith wrote: I prefer the default of clean up after itself as is to avoid leaving temporary file turds on systems caused by us lazy programmers. Maybe instead of an option there should be a separate function with a different name, such as NewUniqueFile. For the use cases I have in mind, the file isn't really temporary at all. Or rather, only the name is temporary, as it ultimately gets renamed. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Alan Kennedy [EMAIL PROTECTED] wrote: [snip] def create_connection(address, timeout=sentinel): [snip] if timeout != sentinel: new_socket.settimeout(timeout) if new_socket.gettimeout() == 0: result = new_socket.connect_ex(address) else: new_socket.connect(address) result = new_socket [snip] I know that this makes it all more complex, and I'm *not* saying the new function should be modified to include these concerns. [snip] But now the result could be either an error code OR a socket. One of the reasons to provide a timeout for the create_connection call, if I understand correctly, is to handle cases for which you don't get a response back in sufficient time. If the user provides zero as a timeout, then they may very well get an exception, which is what they should expect. Then again, even with an arbitrary timeout, an exception is possible (especially if a host is down, etc.), and hiding the exceptional condition (didn't connect in the allotted time) is a bad thing. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patchs and bugs resume
On 3/20/07, Facundo Batista [EMAIL PROTECTED] wrote: People: At the beginning of March, there was a thread in this list about patchs and bugs that teorically weren't checked out. From that discussion, I asked myself: How can I know the temporal location of a patch/bug?. Are there a lot of old patchs/bugs? Those that are old, don't have any update or there're a big discussion with each one? Are they abandoned? To help me with this analisys, I made a tool that taking information from SourceForge it creates a resume table, for the patchs... http://www.taniquetil.com.ar/facundo/py_patchs.html ...and the bugs: http://www.taniquetil.com.ar/facundo/py_bugs.html My idea is to update them periodically (something like each day, at the end of the html you have the update date and time). That's some interesting stuff. Took me a second to realize that the temporal column's total length is the time range from the opening of the oldest bug to the latest comment made on any bug and that the blue bar is where within that time frame the bug was opened and the last comment was made on that bug. But still interesting! Led to me closing a bug and a patch that were old and had not been touched in ages. Hopefully you will be able to easily port this over to the new tracker once it's up (that should happen 2-4 weeks after 2.5.1 is released). -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
[Josiah] But now the result could be either an error code OR a socket. One of the reasons to provide a timeout for the create_connection call, if I understand correctly, is to handle cases for which you don't get a response back in sufficient time. AFAICT, that's the only reason. It's not to handle blocking sockets, that's the default operation of sockets. And it's not to handle non-blocking sockets either. If the user provides zero as a timeout, then they may very well get an exception, which is what they should expect. Yes, they should expect it. And they would handle it like this try: new_socket = socket.create_connection(address, 0): except socket.error: import errno: if errno.errno == 10035 # or relevant platform specific symbolic constant # socket is still connecting else: # there was a real socket error Then again, even with an arbitrary timeout, an exception is possible (especially if a host is down, etc.), and hiding the exceptional condition (didn't connect in the allotted time) is a bad thing. See above. Regards, Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
[Facundo] Letting timeout be positional or named, it's just less error prone. So, if I can make it this way, it's what I prefer, :) So, if I want a timeout of, say, 80 seconds, I issue a call like this new_socket = socket.create_connection(address, 80) So is that address = host, port = 80? Or is it address = (host, port), timeout=80? I know *we* know what it is, but will the user? I prefer explicit naming of the timeout parameter. Regards, Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r54457 - python/trunk/Doc/whatsnew/whatsnew26.tex
A.M. Kuchling wrote: On Tue, Mar 20, 2007 at 06:08:24AM +0100, neal.norwitz wrote: Author: neal.norwitz Date: Tue Mar 20 06:08:23 2007 New Revision: 54457 +% Should there be a new section here for 3k migration? +% Or perhaps a more general section describing module changes/deprecation? +% sets module deprecated This is an interesting question: should the What's New talk about Python 3000? My initial tentative reaction is 'no', because a Py3K section would need to continue to be updated as Python 3000's definition shifts. Once previous Python 2.x versions were released, What's New documents became very static, the only changes being typo fixes and small corrections and clarifications. Having to continually update the Py3K section would be annoying, and argues for a separate document that isn't necessarily tied to Python 2.x releases. On the other hand, it would be nice to warn users away from idioms that will break in Py3K, and the What's New is a natural place to do it. Hm. But the 'porting' section already talks about features that are being deprecated; is that enough? Thoughts? Clearly a need for a new document. We don't want to startle people who don't want to get involved in version wars (probably 98.5% of all users aren't even aware of What's New, since they use a Python installed by someone else, typically their computer vendor or Linux/UNIX distro team). At the same time we should flag the fact that upcoming changes are indeed in the works. Possibly a 3.0 Design Snapshot whose title makes it clear this is a moving target and, among other things, whose content points the user at a definitive (set of) URL(s) for the latest information. Putting this information in What's New (except possibly for mentioning the creation of this new document) would create unnecessary FUD. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Recent Ramblings http://holdenweb.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Alan Kennedy wrote: The standard mechanism in C for doing a non-blocking connect is to issue the connect call, and check the return value for a non-zero error code. If this error code is errno.EAGAIN (code 10035), then the call succeeded, but you should check back later for completion of the operation. Hmmm. I think that this case probably isn't what people will have in mind when they specify a timeout for connecting. More likely they mean If the connection couldn't be successfully established within this time, give up and let me know. So it seems to me that a return value of EAGAIN should be handled internally by re-issuing the connect call with a suitably reduced timeout value. If the timeout gets down to zero without a successful result, throw an exception. An application that wants to do fully asynchronous connects will have to take quite a different approach, so there should probably be a different API for this. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Alan Kennedy [EMAIL PROTECTED] wrote: [Facundo] Letting timeout be positional or named, it's just less error prone. So, if I can make it this way, it's what I prefer, :) So, if I want a timeout of, say, 80 seconds, I issue a call like this new_socket = socket.create_connection(address, 80) So is that address = host, port = 80? Or is it address = (host, port), timeout=80? I know *we* know what it is, but will the user? I prefer explicit naming of the timeout parameter. Error-wise, I agree that it would be better to pass timeout explicitly with a keyword, but generally users will notice their mistake if they try to do create_connection(host, port) by ValueError(tuple expected as first argument, got str instead) Is it better than TypeError(create_connection takes 1 argument (2 given)) ? - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Greg Ewing [EMAIL PROTECTED] wrote: Alan Kennedy wrote: The standard mechanism in C for doing a non-blocking connect is to issue the connect call, and check the return value for a non-zero error code. If this error code is errno.EAGAIN (code 10035), then the call succeeded, but you should check back later for completion of the operation. An application that wants to do fully asynchronous connects will have to take quite a different approach, so there should probably be a different API for this. *cough* asyncore or twisted *cough* Sorry, what were we talking about again? Oh yeah, timeouts. From what I understand of connect and connect_ex, if a socket has a specified timeout, it is supposed to try (it only attempts once, and waits for a response) until it either fails (because the other end won't accept), or it times out. Either case is perfectly fine, and I don't really see the point of retrying (in socket.create_connection). - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
[Josiah] Error-wise, I agree that it would be better to pass timeout explicitly with a keyword, but generally users will notice their mistake if they try to do create_connection(host, port) by ValueError(tuple expected as first argument, got str instead) Is it better than TypeError(create_connection takes 1 argument (2 given)) ? Yes, it is better. Currently, the socket.connect() method takes a tuple, and fails with the following exception if 2 separate parameters are passed TypeError: connect() takes exactly one argument (2 given) Which is fine because the function does take exactly one argument. But we're discussing a function with an optional timeout parameter, so that TypeError wouldn't be raised if I called create_connection(localhost, 80). The patch as it currently is, if I am reading it right, would raise one of the following if a string was passed as the address argument, depending on the length of the string. ValueError: need more than 1 value to unpack # len(address) == 1 ValueError: too many values to unpack # len(address) 2 since it extracts the host and port like so host, port = address Which succeeds, somewhat surprisingly, if a string is passed that is 2 characters long. I was a little surprised to find that this didn't give rise to an error: host, port = ab. So with a two character hostname, the second letter would be unpacked as a port number. And the function would then fail with the following exception when it reaches the getaddrinfo (a, b, 0, SOCK_STREAM) call. socket.gaierror: (10109, 'getaddrinfo failed') I suggest updating the patch to - Explicitly check that the address passed is a tuple of (string, integer) - To raise an exception explaining the parameter expectation when it is not met - To require that the user explicitly name the timeout parameter Regards, Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patchs and bugs resume
Brett Cannon wrote: That's some interesting stuff. Took me a second to realize that the temporal column's total length is the time range from the opening of the oldest bug to the latest comment made on any bug and that the blue bar is where within that time frame the bug was opened and the last comment was made on that bug. M, you're right, I should have explained it somewhere... old and had not been touched in ages. Hopefully you will be able to easily port this over to the new tracker once it's up (that should happen 2-4 weeks after 2.5.1 is released). You can be sure I'll port it... -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Alan Kennedy wrote: So is that address = host, port = 80? Or is it address = (host, port), timeout=80? The latter, as is in the rest of Python... See your point, you say it's less error prone to make timeout mandatory. I really don't care, so I'll take your advice... -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Alan Kennedy wrote: - Explicitly check that the address passed is a tuple of (string, integer) It's more probable that a use pass a list of two values, that a host of two letters as you suggested above... - To raise an exception explaining the parameter expectation when it is not met Won't be necessary if we take into account the explicit timeout parameter... - To require that the user explicitly name the timeout parameter I already agreed on this, :) So, as a resume: - I'll make timeout mandatory - The function signature will be: create_connection(address[, timeout]) See that timeout doesn't have a default value, if you include it, it'll set the socket timeout, if you don't, the defaultimeout will work. The address is a tuple (host, port), as usual In the code, I'll just make host, port = address, I don't think it will be a problem at all. Remember that this function primary use is for higher level libraries, and that address in socket enviroment is always, always, (host, port). Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5.1, buildbots and my availability
I'm moving house today and tomorrow, and don't expect to have internet access connected up at home til sometime next week. In the meantime, if there's urgent 2.5.1 related issues, bear with me, as I'll only be on email during the working day. cc Neal (hi Neal :) is the best bet. Also, the cygwin and ubuntu/icc buildbots will be offline in the interim - I'll be unplugging them this afternoon to move them. I can still cut the 2.5.1 release - can always do it during the day, even if the stupid ISP takes longer than I expect to connect up the net. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_expat.py and unittest
Hi,
I have been working on converting some of the older test files to use
unittest. test_expat.py has a section like:
class Outputter:
def StartElementHandler(self, name, attrs):
print 'Start element:\n\t', repr(name), sortdict(attrs)
def EndElementHandler(self, name):
print 'End element:\n\t', repr(name)
def CharacterDataHandler(self, data):
data = data.strip()
if data:
print 'Character data:'
print '\t', repr(data)
def ProcessingInstructionHandler(self, target, data):
print 'PI:\n\t', repr(target), repr(data)
def StartNamespaceDeclHandler(self, prefix, uri):
print 'NS decl:\n\t', repr(prefix), repr(uri)
snip
...where it defines a set of handlers for an xml document that prints the
output to stdout. The test then parses an xml document using this class and
the stdout output is compared to a file. There are several lines of text on
stdout to be compared:
PI:
'xml-stylesheet' 'href=stylesheet.css'
Comment:
' comment data '
Notation declared: ('notation', None, 'notation.jpeg', None)
Unparsed entity decl:
('unparsed_entity', None, 'entity.file', None, 'notation')
Start element:
'root' {'attr1': 'value1', 'attr2': 'value2\xe1\xbd\x80'}
NS decl:
'myns' 'http://www.python.org/namespace'
Start element:
'http://www.python.org/namespace!subelement' {}
Character data:
'Contents of subelements'
End element:
'http://www.python.org/namespace!subelement'
End of NS decl:
'myns'
Start element:
'sub2' {}
Start of CDATA section
Character data:
'contents of CDATA section'
End of CDATA section
End element:
'sub2'
External entity ref: (None, 'entity.file', None)
End element:
'root'
unittest does not seem well suited to this type of testing, because the
stdout output comparison is testing many different pieces of functionality.
Some subset of it is probably even important. To do this same testing with
unittest would require many lines of self.assertEquals(expected_string,
string_from_stdout).
Does anyone have ideas on how this can be tested in a manner that is not as
brittle as the stdout tests, but doesn't require writing significantly more
test code? Or if not, is converting this file to use unittest a bad idea?
Jerry Seutter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_expat.py and unittest
You could use doctest, which is an accepted testing tool that lets you
compare snippets of output directly without having to check in a
golden file. Despite what is written somewhere, it is not deprecated
or discouraged. See Lib/doctest.py.
You could also use some advanced testing strategy where the callback,
instead of printing, append something to a list (perhaps an instance
variable), and later you check that the list contains the expected
sequence of values.
--Guido
On 3/20/07, Jerry Seutter [EMAIL PROTECTED] wrote:
Hi,
I have been working on converting some of the older test files to use
unittest. test_expat.py has a section like:
class Outputter:
def StartElementHandler(self, name, attrs):
print 'Start element:\n\t', repr(name), sortdict(attrs)
def EndElementHandler(self, name):
print 'End element:\n\t', repr(name)
def CharacterDataHandler(self, data):
data = data.strip()
if data:
print 'Character data:'
print '\t', repr(data)
def ProcessingInstructionHandler(self, target, data):
print 'PI:\n\t', repr(target), repr(data)
def StartNamespaceDeclHandler(self, prefix, uri):
print 'NS decl:\n\t', repr(prefix), repr(uri)
snip
...where it defines a set of handlers for an xml document that prints the
output to stdout. The test then parses an xml document using this class and
the stdout output is compared to a file. There are several lines of text on
stdout to be compared:
PI:
'xml-stylesheet' 'href=stylesheet.css'
Comment:
' comment data '
Notation declared: ('notation', None, 'notation.jpeg', None)
Unparsed entity decl:
('unparsed_entity', None, 'entity.file', None, 'notation')
Start element:
'root' {'attr1': 'value1', 'attr2': 'value2\xe1\xbd\x80'}
NS decl:
'myns' 'http://www.python.org/namespace'
Start element:
'http://www.python.org/namespace!subelement ' {}
Character data:
'Contents of subelements'
End element:
'http://www.python.org/namespace!subelement'
End of NS decl:
'myns'
Start element:
'sub2' {}
Start of CDATA section
Character data:
'contents of CDATA section'
End of CDATA section
End element:
'sub2'
External entity ref: (None, 'entity.file', None)
End element:
'root'
unittest does not seem well suited to this type of testing, because the
stdout output comparison is testing many different pieces of functionality.
Some subset of it is probably even important. To do this same testing with
unittest would require many lines of self.assertEquals(expected_string,
string_from_stdout).
Does anyone have ideas on how this can be tested in a manner that is not as
brittle as the stdout tests, but doesn't require writing significantly more
test code? Or if not, is converting this file to use unittest a bad idea?
Jerry Seutter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py
Alan Kennedy wrote:
def connect(address, **kwargs):
[snip]
if kwargs.has_key('timeout'):
sock.settimeout(kwargs['timeout'])
[snip]
A problem with interfaces like this is that it makes
it awkward to pass on a value that you received from
higher up.
An alternative would be to create and publish a
different special value to mean no timeout.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patchs and bugs resume
On 3/20/07, Facundo Batista [EMAIL PROTECTED] wrote: Brett Cannon wrote: That's some interesting stuff. Took me a second to realize that the temporal column's total length is the time range from the opening of the oldest bug to the latest comment made on any bug and that the blue bar is where within that time frame the bug was opened and the last comment was made on that bug. M, you're right, I should have explained it somewhere... old and had not been touched in ages. Hopefully you will be able to easily port this over to the new tracker once it's up (that should happen 2-4 weeks after 2.5.1 is released). You can be sure I'll port it... Great! It already led to me closing four bugs, another waiting for people to not speak up, and a sixth for me to fix! -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
