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
Neal Norwitz schrieb:
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
[Facundo Batista]
Remember that this function primary use is for
higher level libraries
Yes, I see that clearly now.
But remember that by adding a new function to the socket module to
support httplib et al, you are also adding a function to the socket
module that will be used directly by end
Greg Ewing wrote:
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
Scott Dial wrote:
Greg Ewing wrote:
Maybe instead of an option there should be a separate
function with a different name, such as NewUniqueFile.
I'm in favor of adding such a function.
A tangential question -- why are TemporaryFile and
NamedTemporaryFile named in TitleCase, when they're
Greg Ewing wrote:
A tangential question -- why are TemporaryFile and
NamedTemporaryFile named in TitleCase, when they're
functions and not classes?
I wondered the same. At first draft of my email I wrote class
operating under the assumption that only classes got to be camel-cased.
If I had
On 3/21/07, Scott Dial [EMAIL PROTECTED] wrote:
Greg Ewing wrote:
A tangential question -- why are TemporaryFile and
NamedTemporaryFile named in TitleCase, when they're
functions and not classes?
I wondered the same. At first draft of my email I wrote class
operating under the assumption
Alan Kennedy wrote:
The proposed new function does not belong in the socket module. In
contrast to all of the other socket creation and management
functionality in the socket module, the new function does not handle
non-blocking IO.
The rest of the socket module isn't going anywhere. If you
Greg Ewing schrieb:
Scott Dial wrote:
Greg Ewing wrote:
Maybe instead of an option there should be a separate
function with a different name, such as NewUniqueFile.
I'm in favor of adding such a function.
A tangential question -- why are TemporaryFile and
NamedTemporaryFile named in
Alan Kennedy wrote:
But remember that by adding a new function to the socket module to
support httplib et al, you are also adding a function to the socket
module that will be used directly by end users.
I vote to reject this patch.
Well, you can vote to name it _create_connection(), if your
Facundo Voting is open, ;)
...
Facundo So, as a resume of the choices we still need to settle:
Facundo a) Repeat the same functionality in 5 other libraries
Facundo b) Write the function in socket.py, public
Facundo c) Write the function in socket.py, non public
I
[Facundo]
Voting is open, ;)
So what are we voting on exactly? The patch as it currently is? The
patch has not been updated to reflect recent discussions on the list.
Will the patch be updated before the vote?
I have one more issue with the patch.
I think that the exception handling in the
Georg Brandl wrote:
Greg Ewing schrieb:
Scott Dial wrote:
A tangential question -- why are TemporaryFile and
NamedTemporaryFile named in TitleCase, when they're
functions and not classes?
Probably because they are factory functions potentially returning a
Alan Kennedy wrote:
I think this patch is poorly designed and poorly implemented. There
are multiple problems in its 17 lines of socket module code; every
time I look I find a new problem.
Code which is copied verbatim from httplib, and also occurs with slight
variations in several other
Alan Kennedy wrote:
So what are we voting on exactly? The patch as it currently is? The
patch has not been updated to reflect recent discussions on the list.
Will the patch be updated before the vote?
The voting is on a, b or c.
The patch will be updated after I know what python-dev want to
Aaron Bingham schrieb:
Georg Brandl wrote:
Greg Ewing schrieb:
Scott Dial wrote:
A tangential question -- why are TemporaryFile and
NamedTemporaryFile named in TitleCase, when they're
functions and not classes?
Probably because they are factory functions potentially
On 3/21/07, Facundo Batista [EMAIL PROTECTED] wrote:
So, as a resume of the choices we still need to settle:
a) Repeat the same functionality in 5 other libraries
b) Write the function in socket.py, public
c) Write the function in socket.py, non public
The fact that it's needed in 5
[Facundo]
Talk is cheap.
I'm sorry if you see my attempts to review your patch as cheap talk.
Maybe I should have just kept my opinion to myself.
You'll get your chance to return the favour when I check in my
upcoming 1000+ line change to jython 2.3 to bring the jython socket,
select and
[Facundo]
Talk is cheap.
I'm sorry if you see my attempts to review your patch as cheap talk.
Maybe I should have just kept my opinion to myself.
You'll get your chance to return the favour when I check in my
upcoming 1000+ line change to jython 2.3 to bring the jython socket,
select and
Facundo Batista [EMAIL PROTECTED] wrote:
Alan Kennedy wrote:
I recommend modifying the patch to remove *all* proposed changes to
the socket module. Instead, the patch should restrict itself to fixing
the httplib module.
-1 to repeat the same functionality in 5 other libraries.
As I
[Josiah]
In regards to 'there is no way to
create a blocking socket this way', Alan is off his rocker.
I am not off my rocker.
And I never wrote the words you place in quotes (except in relation to
an earlier defect in the patch where the timeout=None value was
ignored).
What I clearly stated
test_posixpath is failing in: test_relpath
This is due to #1339796, r54419. I left a comment in the tracker.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 3/21/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
test_posixpath is failing in: test_relpath
This is due to #1339796, r54419. I left a comment in the tracker.
This is my check-in. I'll have a fix shortly.
Collin Winter
___
Python-Dev mailing
I updated the patch #1676823, reflecting discussion here:
- The function name changed, now it's _create_connection(). Its
signature also changed: now, timeout is mandatorily named.
- HTTPConnection has the posibility to call timeout with a number, and
also with None. In both cases, it updates
Patch 1490190 causes test_posix to fail on Tru64 due to chflags().
I have a potential fix for that in the tracker.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Josiah Carlson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Alan is off his rocker.
To me, this sort of ad hominen comment is anti-productive and out-of-place
in technical discussion.
Facundo Batista [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
It's better than
| On 3/20/07, Facundo Batista [EMAIL PROTECTED] wrote:
| Brett Cannon wrote:
| 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
On 3/21/07, Terry Reedy [EMAIL PROTECTED] wrote:
Josiah Carlson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Alan is off his rocker.
To me, this sort of ad hominen comment is anti-productive and out-of-place
in technical discussion.
Facundo Batista [EMAIL PROTECTED] wrote in
On 3/21/07, Steven Bethard [EMAIL PROTECTED] wrote:
On 3/21/07, Facundo Batista [EMAIL PROTECTED] wrote:
So, as a resume of the choices we still need to settle:
a) Repeat the same functionality in 5 other libraries
b) Write the function in socket.py, public
c) Write the function
Georg Brandl wrote:
Aaron Bingham schrieb:
Georg Brandl wrote:
Greg Ewing schrieb:
Scott Dial wrote:
A tangential question -- why are TemporaryFile and
NamedTemporaryFile named in TitleCase, when they're
functions and not classes?
Probably
What are the current thoughts on when Py2.5.1 will go out?
Do we need a bug-day beforehand?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Guido van Rossum wrote:
(like httplib before the patch), I am personally in favor of going
back to defaulting timeout to None and skipping the settimeout() call
in _create_connection() if timeout is None. IMO the use case where
there is a global timeout set and one library wants to override
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 21, 2007, at 1:51 PM, Raymond Hettinger wrote:
What are the current thoughts on when Py2.5.1 will go out?
Do we need a bug-day beforehand?
That might not be a bad idea. I've been working on some email
package fixes in the background.
On 3/21/07, Facundo Batista [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
(like httplib before the patch), I am personally in favor of going
back to defaulting timeout to None and skipping the settimeout() call
in _create_connection() if timeout is None. IMO the use case where
there
Facundo Batista wrote:
It works, but my only issue is that it gets ugly in the help():
sentinel = object()
def f(a, b=sentinel):
... pass
...
help(f)
...
f(a, b=object object at 0xb7d64460)
I know I can use a class with __str__ instead of object, but
what would one print
On Wed, Mar 21, 2007 at 01:51:37PM -0400, Raymond Hettinger wrote:
What are the current thoughts on when Py2.5.1 will go out?
Do we need a bug-day beforehand?
A bug day would be a great idea! I have a mailbox bug that'd
greatly benefit from discussion about how to fix the problem.
--amk
Guido van Rossum wrote:
This is why I proposed to *get rid of* the distinction between
timeout=None and timeout not specified. Let an unspecified timeout
default to None, and if timeout is None, skip the settimeout() call.
+1
I'll abuse of your dictatorship, and let's see if we can finally
[Raymond]
What are the current thoughts on when Py2.5.1 will go out?
Do we need a bug-day beforehand?
[AMK]
A bug day would be a great idea! I have a mailbox bug that'd
greatly benefit from discussion about how to fix the problem.
How about Sunday, April 1st?
Raymond
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 21, 2007, at 3:28 PM, Raymond Hettinger wrote:
[Raymond]
What are the current thoughts on when Py2.5.1 will go out?
Do we need a bug-day beforehand?
[AMK]
A bug day would be a great idea! I have a mailbox bug that'd
greatly benefit
I'm soliciting feedback on my extended buffer protocol that I am
proposing for inclusion in Python 3000. As soon as the Python 3.0
implementation is complete, I plan to back-port the result to Python
2.6, therefore, I think there may be some interest on this list.
Basically, the extended
Is there any reason for test_bool to contain assertions like these?
self.assertIs({}.has_key(1), False)
self.assertIs({1:1}.has_key(1), True)
A significant portion of the file is devoted to making sure various
things return bools (isinstance, operator.*) or handle bools correctly
(pickle,
How about Sunday, April 1st?
Barry I could probably show up for a few hours that day.
I can likely spend a couple hours as well. Afternoon (Central Time) would
be better. Depends on Ellen's work schedule.
Skip
___
Python-Dev mailing list
[EMAIL PROTECTED] wrote:
How about Sunday, April 1st?
Barry I could probably show up for a few hours that day.
I can likely spend a couple hours as well. Afternoon (Central Time) would
be better. Depends on Ellen's work schedule.
I'd like to put something back into Python and
I think it was just expedient to group these together when the bool
type was added. I wouldn't lose sleep over it either way.
On 3/21/07, Collin Winter [EMAIL PROTECTED] wrote:
Is there any reason for test_bool to contain assertions like these?
self.assertIs({}.has_key(1), False)
On 3/21/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Raymond]
What are the current thoughts on when Py2.5.1 will go out?
Do we need a bug-day beforehand?
[AMK]
A bug day would be a great idea! I have a mailbox bug that'd
greatly benefit from discussion about how to fix the problem.
Facundo Batista schrieb:
I updated the patch #1676823, reflecting discussion here:
- The function name changed, now it's _create_connection(). Its
signature also changed: now, timeout is mandatorily named.
- HTTPConnection has the posibility to call timeout with a number, and
also with
On Wed, Mar 21, 2007 at 03:37:02PM -0500, Collin Winter wrote:
Is there any reason for test_bool to contain assertions like these?
self.assertIs({}.has_key(1), False)
self.assertIs({1:1}.has_key(1), True)
A significant portion of the file is devoted to making sure various
things return
Raymond Hettinger schrieb:
[Raymond]
What are the current thoughts on when Py2.5.1 will go out?
Do we need a bug-day beforehand?
[AMK]
A bug day would be a great idea! I have a mailbox bug that'd
greatly benefit from discussion about how to fix the problem.
How about Sunday, April 1st?
Attached is the PEP.
:PEP: XXX
:Title: Revising the buffer protocol
:Version: $Revision: $
:Last-Modified: $Date: $
:Author: Travis Oliphant [EMAIL PROTECTED]
:Status: Draft
:Type: Standards Track
:Content-Type: text/x-rst
:Created: 28-Aug-2006
:Python-Version: 3000
Abstract
This PEP
Georg Brandl wrote:
The class/function distinction is not so clear in Python from the user's
point of view since there is no different calling syntax.
There *is* a visible distinction, though --
you can subclass classes but not functions.
If these are uppercased because they wrap
classes, why
Facundo Batista wrote:
So, as a resume of the choices we still need to settle:
a) Repeat the same functionality in 5 other libraries
b) Write the function in socket.py, public
c) Write the function in socket.py, non public
or
d) Put it in another module
Is it time for a
[EMAIL PROTECTED] wrote:
Facundo c) Write the function in socket.py, non public
Also this option has the problem that it would be
a strange usage of non-public, since the function
would be designed for use by other modules and not
used at all in the module it's supposedly private
to.
--
Travis Oliphant:
3) information about discontiguous memory segments
Number 3 is where I could use feedback --- especially from PIL users and
developers. Strides are a common way to think about a possibly
discontiguous chunk of memory (which appear in NumPy when you select a
sub-region
On 3/21/07, Neil Hodgson [EMAIL PROTECTED] wrote:
Travis Oliphant:
3) information about discontiguous memory segments
Number 3 is where I could use feedback --- especially from PIL users and
developers. Strides are a common way to think about a possibly
discontiguous chunk of
Neil Hodgson wrote:
I think one of the motivations for discontiguous segments was for
split buffers which are commonly used in text editors.
Note that this is different from the case of an array
of pointers to arrays, which is a multi-dimensional
array structure, whereas a split buffer is a
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount of user code in 2.6 for the sake of
stricter argument checking for object.__init__ and object.__new__. I
think it probably isn't; but the strict version could be added to 3.0
and a warning
On 3/21/07, Alan Kennedy [EMAIL PROTECTED] wrote:
[Greg Ewing]
or
d) Put it in another module
Is it time for a sockettools module, maybe?
+1!
-1. The new module would be just as much a jumble of unrelated APIs as
the socket module already is, so there's no particularly good
[Greg Ewing]
or
d) Put it in another module
Is it time for a sockettools module, maybe?
+1!
Alan.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Nick Maclaren [EMAIL PROTECTED] wrote:
Well, I have seen it hundreds of times on a dozen different Unices;
it is very common. You don't always SEE the stuck process - sometimes
the 'kill -9' causes the pid to become invisible to ps etc., and
just occasionally it can continue to use CPU until
[Facundo]
Talk is cheap.
I'm sorry if you see my attempts to review your patch as cheap talk.
Maybe I should have just kept my opinion to myself.
You'll get your chance to return the favour when I check in my
upcoming 1000+ line change to jython 2.3 to bring the jython socket,
select and
On Sat, Mar 17, 2007 at 08:09:06PM -0500, Collin Winter wrote:
On 3/17/07, Ewan Mellor [EMAIL PROTECTED] wrote:
I have a problem being reported (by Xen users) where inspect.stack() is
throwing IndexError. I think that this is a bug in inspect.py --
findsource
generally throws IOError when
On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED] wrote:
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount of user code in 2.6 for the sake of
stricter argument checking for object.__init__ and object.__new__. I
think it
ACTIVITY SUMMARY (03/11/07 - 03/18/07)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1645 open ( +1) / 8581 closed ( +0) / 10226 total ( +1)
Average duration of open issues: 738 days.
For some time I'm interested in regular expressions and Finite State Machine.
Recently, I saw that Python uses Secret Labs' Regular Expression Engine,
which very often works too slow. Its pesymistic time complexity is O(2^n),
although other solutions, with time complexity O(n*m) ( O(n*m^2), m
The xxsubtype.c module gives an example of calling a parent method if it is in
a slot:
static int
spamlist_init(spamlistobject *self, PyObject *args, PyObject *kwds)
{
if (PyList_Type.tp_init((PyObject *)self, args, kwds) 0)
return -1;
self-state = 0;
return 0;
}
How you
Travis Oliphant wrote:
The question is should we eliminate the possibility of sharing memory
for objects that store data basically as arrays of arrays (i.e. true
C-style arrays).
Can you clarify what you mean by this? Are you talking
about an array of pointers to other arrays? (This is
not
Greg Ewing:
So an array-of-pointers interface wouldn't be a direct
substitute for the existing multi-segment buffer
interface.
Providing an array of (pointer,length) wouldn't be too much extra
work for a split vector implementation.
Guido van Rossum:
But there's always a call to remove
Greg Ewing wrote:
A tangential question -- why are TemporaryFile and
NamedTemporaryFile named in TitleCase, when they're
functions and not classes?
I wondered the same. At first draft of my email I wrote class
operating under the assumption that only classes got to be camel-cased.
If I had
Greg Ewing wrote:
Travis Oliphant wrote:
The question is should we eliminate the possibility of sharing memory
for objects that store data basically as arrays of arrays (i.e. true
C-style arrays).
Can you clarify what you mean by this? Are you talking
about an array of pointers to
Jean-Paul Calderone wrote:
Perhaps I misunderstand the patch, but it would appear to break not just
some inadvisable uses of super(), but an actual core feature of super().
Maybe someone can set me right. Is this correct?
class Base(object):
def __init__(self, important):
If so,
On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED]
wrote:
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount of user code in 2.6 for the sake of
stricter argument
Guido van Rossum wrote:
Is it time for a sockettools module, maybe?
+1!
-1. The new module would be just as much a jumble of unrelated APIs as
the socket module already is, so there's no particularly good reason
to create an arbitrary separation. Also, KISS.
I agree with Guido on this
Raymond Hettinger wrote:
class List(list):
def append(self, x):
print x
List.append(self, x) # What is the C equivalent of this call?
Something like
PyObject *meth, *result;
meth = PyObject_GetAttrString(PyList_Type, append)
result =
Guido van Rossum wrote:
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount of user code in 2.6 for the sake of
stricter argument checking for object.__init__
Personally I have never written code that relies on
being able to pass arbitrary
Bart³omiej Wo³owiec [EMAIL PROTECTED] wrote:
For some time I'm interested in regular expressions and Finite State Machine.
Recently, I saw that Python uses Secret Labs' Regular Expression Engine,
which very often works too slow. Its pesymistic time complexity is O(2^n),
although other
On Wed, Mar 21, 2007, Guido van Rossum wrote:
On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
I think I understand the desire to pull keyword arguments out at each
step of the upcalling process, but I don't see how it can work, since
up calling isn't always what's going on - given a
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| There are different philosophies about the correct style for
| cooperative super calls.
|
| The submitter of the bug report likes to remove consumed arguments
| and pass the others on, having something at the root that
On 3/21/07, Guido van Rossum [EMAIL PROTECTED] wrote:
On 3/21/07, Adam Olsen [EMAIL PROTECTED] wrote:
super() has always felt strange to me.
When used in __init__? Or in general? If the former, that's because
it's a unique Python wart to even be able to use super for __init__.
In general.
On 3/21/07, Adam Olsen [EMAIL PROTECTED] wrote:
On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED]
wrote:
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount
On 3/21/07, Aahz [EMAIL PROTECTED] wrote:
Maybe so, but this would massively break my company's application, if we
were actually using new-style classes and the built-in super(). We have
a web application that commonly passes all form fields down as **kwargs;
the application uses lots of
At 09:41 PM 3/21/2007 -0700, Guido van Rossum wrote:
On 3/21/07, Greg Ewing [EMAIL PROTECTED] wrote:
Every time I've considered using super, I've eventually
decided against it for reasons like this. I've always
found a better way that doesn't introduce so may
strange interactions between
On 3/21/07, Greg Ewing [EMAIL PROTECTED] wrote:
Every time I've considered using super, I've eventually
decided against it for reasons like this. I've always
found a better way that doesn't introduce so may
strange interactions between the classes involved.
I end up feeling the same way, for
On 3/21/07, Terry Reedy [EMAIL PROTECTED] wrote:
It seems to me that to get the exact behavior one wants at the apex of a
diamond structure, one should subclass object and override .__init__ with
a function that does not call object.__init__ and use that subclass as the
apex instead of
On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED]
wrote:
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount of user code in 2.6 for the sake of
stricter argument
Travis Oliphant wrote:
I'm talking about arrays of pointers to other arrays:
i.e. if somebody defined in C
float B[10][20]
then B would B an array of pointers to arrays of floats.
No, it wouldn't, it would be a contiguously stored
2-dimensional array of floats. An array of pointers
At 09:41 PM 3/21/2007 -0700, Guido van Rossum wrote:
Also make a big distinction between super calls of __init__ (which are
a Pythonic wart and don't exist in other languages practicing multiple
inheritance AFAIK)
Since I filed the bug, I should clarify that the primary reason I'm
using
86 matches
Mail list logo
