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=detail&aid=1676823&group_id=5470&atid=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] Proposal to revert r54204 (splitext change)
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.
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.
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] 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" <[EMAIL PROTECTED]> wrote: > 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. Agreed, though implementation-wise, there is another technique for determining whether the use provided an argument to timeout or not... 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. - 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
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)
...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)
>
>
> ...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
Re: [Python-Dev] Patchs and bugs resume
>> 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... When you do, make sure you take a look at roundup's search facilities. Roundup keeps a 'last activity' field, on which you can search and sort, and a 'creation date' field (likewise). 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
