[ python-Bugs-1229646 ] httplib error checking.

[SourceForge.net]

Bugs item #1229646, was opened at 2005-06-29 21:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229646&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Johns (cjohns)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib error checking.

Initial Comment:
The httplib does not seem to handle error codes cleanly
or in a portable way. The socket could return a
ECONNRESET and does on the RTEMS platform. Also value
32 is normally EPIPE, but ECONNRESET is different so
the Python errno should be used.

 [please excuse the manual diff :-)]

line 657:
<   if v[0] == 32:  # Broken pipe
line 657:
>   if v[0] == errno.EPIPE or v[0] ==
errno.ECONNRESET:


line 803:
>   if v[0] != 32 or not self.auto_open:
line 803:
>if (v[0] != errno.EPIPE and v[0] !=
errno.ECONNRESET) or not self.auto_open:

I can provide a patch if this change make sense.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229646&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1229680 ] Tracing C function calls and keyword arguments

[SourceForge.net]

Bugs item #1229680, was opened at 2005-06-29 15:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229680&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Cieslok (fcieslok)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tracing C function calls and keyword arguments

Initial Comment:
When a tracing/profiling function is registered via 

  'PyEval_SetTrace()' or 'PyEval_SetProfile()', 

calling registered C functions should lead to calls of
the tracing function with reason 

  'PyTrace_C_CALL' and 'PyTrace_C_RETURN'.

This does not work if the function call uses keyword
arguments (test case attached) ! 

The reason seems to be that in
'Python/ceval.c:call_function ()' the macro 'C_TRACE'
is used to wrap the calling of build-in functions into
the corresponding calls of the tracing function. This
does not apply if keyword arguments are used, in that
case 'do_call ()' is called directly without being
wrapped into that macro.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229680&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1229680 ] Tracing C function calls and keyword arguments

[SourceForge.net]

Bugs item #1229680, was opened at 2005-06-29 14:00
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229680&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Cieslok (fcieslok)
>Assigned to: Nick Bastin (mondragon)
Summary: Tracing C function calls and keyword arguments

Initial Comment:
When a tracing/profiling function is registered via 

  'PyEval_SetTrace()' or 'PyEval_SetProfile()', 

calling registered C functions should lead to calls of
the tracing function with reason 

  'PyTrace_C_CALL' and 'PyTrace_C_RETURN'.

This does not work if the function call uses keyword
arguments (test case attached) ! 

The reason seems to be that in
'Python/ceval.c:call_function ()' the macro 'C_TRACE'
is used to wrap the calling of build-in functions into
the corresponding calls of the tracing function. This
does not apply if keyword arguments are used, in that
case 'do_call ()' is called directly without being
wrapped into that macro.


--

>Comment By: Michael Hudson (mwh)
Date: 2005-06-29 14:52

Message:
Logged In: YES 
user_id=6656

I think this is the right assignment!

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229680&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1229788 ] Bus error in extension with gcc 3.3

[SourceForge.net]

Bugs item #1229788, was opened at 2005-06-29 11:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Robinson (garyrob)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bus error in extension with gcc 3.3

Initial Comment:
This text contains a c module with 4 versions of the same 
extremely simple function. All they do is return a float double to 
python. 

On Windows I have received a report from someone who can built 
the module, imported it into Python, and ran it successfully. 

It has also been reported that there is no problem when the 
extension is compiled with gcc 4.0 on OS X.

However, on OS X, if the extension is compiled with gcc 3.3, the 4th 
of the 4 function results in a bus error:


>>> from check import *
 fun0()
411.0
>>> fun1()
534.37
>>> fun2()
411.0
>>> fun3()
Bus error


I originally reported this on the C++ sig's mail list. They suggested I 
try dev-python. Scott David Daniels on that list helped me refine 
some 
test cases and verified that they all worked on Windows. 

Along the way it was suggested that I post a bug report. So this is it.

The code follows:

#include "Python.h"
static double value = 411.0;

static PyObject *
fun0(PyObject *self, PyObject *args)
{
if (!PyArg_ParseTuple(args, "", NULL)) return NULL;
return Py_BuildValue("d", value);
}

static PyObject *
fun1(PyObject *self, PyObject *args)
{
return Py_BuildValue("d", 1.3*value);
}

static PyObject *
fun2(PyObject *self, PyObject *args)
{
return PyFloat_FromDouble(value);
}

static PyObject *
fun3(PyObject *self, PyObject *args)
{
return Py_BuildValue("d", value);
}


static PyMethodDef TestMethods[] = {
{"fun0", fun0, METH_VARARGS, "Read args and return value"},
{"fun1", fun1, METH_VARARGS, "Return value multiplied inline 
by 
1.3"},
{"fun2", fun2, METH_VARARGS, "Return value using 
PyFloat_FromDouble"},
{"fun3", fun3, METH_VARARGS, "Return value using 
Py_BuildValue 
without reading args -- causes bus error on OS X Panther with 
XCode 1.5 
installed"},
{NULL, NULL, 0, NULL}/* Sentinel */
};

PyMODINIT_FUNC
initcheck(void)
{
PyObject *module;

module = Py_InitModule3("check", TestMethods,
"extension module with three functions.");
if (module) {
PyModule_AddStringConstant(module, "__version__", "0.02");
}
}


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1219273 ] 'Expression' AST Node not documented

[SourceForge.net]

Bugs item #1219273, was opened at 2005-06-12 20:27
Message generated for change (Comment added) made by pterk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Miller (mrmiller)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'Expression' AST Node not documented

Initial Comment:
Python 2.4.1 documentation
===
The table at the end of section "19.3.1 AST Nodes" 
does not list Node type 'Expression' and its associated
information.

Also, the BNF for 'expression' shown in the file


> expression ::= 
>  or_test | lambda_form

can't be correct because it doesn't cover cases of a
simple literals (or identifiers) such as 42 and simple
binary operator expressions such as 1+2.


--

Comment By: Peter van Kampen (pterk)
Date: 2005-06-29 21:24

Message:
Logged In: YES 
user_id=174455

I have submitted a (very minimal) doc-patch that adds
expression to the section 19.3.1.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-18 22:34

Message:
Logged In: YES 
user_id=1188172

To your second comment: the BNF for expression is correct
since or_test can contain and_test which can contain
not_test and so on until primary, atom, literal.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1219273 ] 'Expression' AST Node not documented

[SourceForge.net]

Bugs item #1219273, was opened at 2005-06-12 20:27
Message generated for change (Comment added) made by pterk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Miller (mrmiller)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'Expression' AST Node not documented

Initial Comment:
Python 2.4.1 documentation
===
The table at the end of section "19.3.1 AST Nodes" 
does not list Node type 'Expression' and its associated
information.

Also, the BNF for 'expression' shown in the file


> expression ::= 
>  or_test | lambda_form

can't be correct because it doesn't cover cases of a
simple literals (or identifiers) such as 42 and simple
binary operator expressions such as 1+2.


--

Comment By: Peter van Kampen (pterk)
Date: 2005-06-29 21:26

Message:
Logged In: YES 
user_id=174455

See patch #1227568

--

Comment By: Peter van Kampen (pterk)
Date: 2005-06-29 21:24

Message:
Logged In: YES 
user_id=174455

I have submitted a (very minimal) doc-patch that adds
expression to the section 19.3.1.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-18 22:34

Message:
Logged In: YES 
user_id=1188172

To your second comment: the BNF for expression is correct
since or_test can contain and_test which can contain
not_test and so on until primary, atom, literal.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1210326 ] comma separated cookie values

[SourceForge.net]

Bugs item #1210326, was opened at 2005-05-28 11:13
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: tvogt (tovo)
Assigned to: Nobody/Anonymous (nobody)
Summary: comma separated cookie values

Initial Comment:
According to RFC 2109

"For backward compatibility, the separator in the
Cookie header
is semi-colon (;) everywhere.  A server should also
accept comma (,)
as the separator between cookie-values for future
compatibility."

The Cookie standard module does not support this as it
should.

>>> import Cookie
>>> c=Cookie.SimpleCookie()
>>> c.load('foo=2, bar=3')
>>> print c['foo'].value
2,



--

Comment By: John J Lee (jjlee)
Date: 2005-06-29 20:34

Message:
Logged In: YES 
user_id=261020

Unfortunately one can't take the cookie specs at face value.

Netscape cookies behaviour (the de-facto standard, ie. IE &
Firefox behaviour -- cookie_spec.html is barely worth the
web page it's written on, being flat-out wrong in several
major ways, and very under-specified) has, I'm told, always
simply been simply "split on semicolons".  Certainly that's
what IE and Mozilla do now:

(this is just the text of a CGI for viewing: I didn't make
it executable on reportlab.org)

http://www.reportlab.org/~jjlee/cookie_demo.py

IIRC RFC 2965 is only implemented by Opera, and is certainly
now quite dead as an internet standard.  (though I think it
is useful as a guide for writing cookie-handling code, you
can't follow blindly - not even close :-( )


--

Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-02 00:19

Message:
Logged In: YES 
user_id=11375

The updated cookie RFC, RFC 2965, also has this language.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1228904 ] weakref example broken

[SourceForge.net]

Bugs item #1228904, was opened at 2005-06-28 12:32
Message generated for change (Comment added) made by pterk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: paolo veronelli (paolo_veronelli)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref example broken

Initial Comment:
Surely the example in python2.4/lib/weakref-objects.html
 is untested .Bad story.

Attached a working version which I suppose correct it .

--

Comment By: Peter van Kampen (pterk)
Date: 2005-06-29 21:46

Message:
Logged In: YES 
user_id=174455

I can confirm this (in 2.5a0). It seems untested as it
contains several small errors. I have submitted a doc-patch
with working code that is also a simplified version. See
patch #1229935.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1210326 ] comma separated cookie values

[SourceForge.net]

Bugs item #1210326, was opened at 2005-05-28 11:13
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: tvogt (tovo)
Assigned to: Nobody/Anonymous (nobody)
Summary: comma separated cookie values

Initial Comment:
According to RFC 2109

"For backward compatibility, the separator in the
Cookie header
is semi-colon (;) everywhere.  A server should also
accept comma (,)
as the separator between cookie-values for future
compatibility."

The Cookie standard module does not support this as it
should.

>>> import Cookie
>>> c=Cookie.SimpleCookie()
>>> c.load('foo=2, bar=3')
>>> print c['foo'].value
2,



--

Comment By: John J Lee (jjlee)
Date: 2005-06-29 20:53

Message:
Logged In: YES 
user_id=261020

Forgot to add or demo in that CGI script: even

Set-Cookie: abc=def, ghi=jkl

is just one Netscape cookie, name 'abc', value 'def, ghi=jkl'.


--

Comment By: John J Lee (jjlee)
Date: 2005-06-29 20:34

Message:
Logged In: YES 
user_id=261020

Unfortunately one can't take the cookie specs at face value.

Netscape cookies behaviour (the de-facto standard, ie. IE &
Firefox behaviour -- cookie_spec.html is barely worth the
web page it's written on, being flat-out wrong in several
major ways, and very under-specified) has, I'm told, always
simply been simply "split on semicolons".  Certainly that's
what IE and Mozilla do now:

(this is just the text of a CGI for viewing: I didn't make
it executable on reportlab.org)

http://www.reportlab.org/~jjlee/cookie_demo.py

IIRC RFC 2965 is only implemented by Opera, and is certainly
now quite dead as an internet standard.  (though I think it
is useful as a guide for writing cookie-handling code, you
can't follow blindly - not even close :-( )


--

Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-02 00:19

Message:
Logged In: YES 
user_id=11375

The updated cookie RFC, RFC 2965, also has this language.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1028088 ] Cookies without values are silently ignored (by design?)

[SourceForge.net]

Bugs item #1028088, was opened at 2004-09-14 19:05
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028088&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Sheppard (sirilyan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cookies without values are silently ignored (by design?)

Initial Comment:
Cookie._CookiePattern is the regular expression used to
retrieve cookies from the HTTP_COOKIE environment
variable.  This pattern assumes that all cookies are in
"name=value" format.  A cookie that doesn't have an
"=value" component is silently skipped over.  (It's
easy to generate a cookie like that - in JavaScript,
document.cookie="broken" is all it takes.)

>>> import Cookie
>>> q = Cookie.SimpleCookie("pie=good; broken;
other=thing")
>>> q


If ignoring cookies without a "=value" component is
intended behaviour, it'd be nice to have a code comment
warning that's what happens.  If it's a bug, the cookie
should be set with an empty value.

--

Comment By: John J Lee (jjlee)
Date: 2005-06-29 21:02

Message:
Logged In: YES 
user_id=261020

Though I had previously assumed stability is more important
than the precise details of what module Cookie does (since
you can choose what cookies you send, the only important
thing is that behaviour is relatively sane, and does the job
-- in a standards-compliant way -- with browsers).  But I
suppose one can have JS code or other web app code
maintained by others, and have to understand cookies that
were emitted by that code.  Is that your situation?

Do 'serious' web developers use module Cookie, or do people
now tend to use web frameworks' own cookie code (personally
I don't use cookies in my web application work).  If the
former, perhaps we should not tinker with this module.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028088&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1210326 ] comma separated cookie values

[SourceForge.net]

Bugs item #1210326, was opened at 2005-05-28 05:13
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: tvogt (tovo)
>Assigned to: A.M. Kuchling (akuchling)
Summary: comma separated cookie values

Initial Comment:
According to RFC 2109

"For backward compatibility, the separator in the
Cookie header
is semi-colon (;) everywhere.  A server should also
accept comma (,)
as the separator between cookie-values for future
compatibility."

The Cookie standard module does not support this as it
should.

>>> import Cookie
>>> c=Cookie.SimpleCookie()
>>> c.load('foo=2, bar=3')
>>> print c['foo'].value
2,



--

Comment By: John J Lee (jjlee)
Date: 2005-06-29 14:53

Message:
Logged In: YES 
user_id=261020

Forgot to add or demo in that CGI script: even

Set-Cookie: abc=def, ghi=jkl

is just one Netscape cookie, name 'abc', value 'def, ghi=jkl'.


--

Comment By: John J Lee (jjlee)
Date: 2005-06-29 14:34

Message:
Logged In: YES 
user_id=261020

Unfortunately one can't take the cookie specs at face value.

Netscape cookies behaviour (the de-facto standard, ie. IE &
Firefox behaviour -- cookie_spec.html is barely worth the
web page it's written on, being flat-out wrong in several
major ways, and very under-specified) has, I'm told, always
simply been simply "split on semicolons".  Certainly that's
what IE and Mozilla do now:

(this is just the text of a CGI for viewing: I didn't make
it executable on reportlab.org)

http://www.reportlab.org/~jjlee/cookie_demo.py

IIRC RFC 2965 is only implemented by Opera, and is certainly
now quite dead as an internet standard.  (though I think it
is useful as a guide for writing cookie-handling code, you
can't follow blindly - not even close :-( )


--

Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-01 18:19

Message:
Logged In: YES 
user_id=11375

The updated cookie RFC, RFC 2965, also has this language.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1229680 ] Tracing C function calls and keyword arguments

[SourceForge.net]

Bugs item #1229680, was opened at 2005-06-29 09:00
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229680&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Cieslok (fcieslok)
Assigned to: Nick Bastin (mondragon)
Summary: Tracing C function calls and keyword arguments

Initial Comment:
When a tracing/profiling function is registered via 

  'PyEval_SetTrace()' or 'PyEval_SetProfile()', 

calling registered C functions should lead to calls of
the tracing function with reason 

  'PyTrace_C_CALL' and 'PyTrace_C_RETURN'.

This does not work if the function call uses keyword
arguments (test case attached) ! 

The reason seems to be that in
'Python/ceval.c:call_function ()' the macro 'C_TRACE'
is used to wrap the calling of build-in functions into
the corresponding calls of the tracing function. This
does not apply if keyword arguments are used, in that
case 'do_call ()' is called directly without being
wrapped into that macro.


--

>Comment By: Nick Bastin (mondragon)
Date: 2005-06-29 16:12

Message:
Logged In: YES 
user_id=430343

Yep, I'll take a look into fixing this ASAP.

--

Comment By: Michael Hudson (mwh)
Date: 2005-06-29 09:52

Message:
Logged In: YES 
user_id=6656

I think this is the right assignment!

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229680&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1227166 ] Queue class does not inherit object

[SourceForge.net]

Bugs item #1227166, was opened at 2005-06-24 13:01
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227166&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Vincent Côté-Roy (jbabel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Queue class does not inherit object

Initial Comment:
Queue class does not inherit object, and thus is not a
so-called new-style class. 

That means you can't sub-class it and do things like
call super on it.

One would expect all classes shipped with the Python
library to inherit object, especially since it's so
easy to apply such a change.

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-29 15:15

Message:
Logged In: YES 
user_id=80475

Correction, both new and old style classes can be
subclassed.  Also, super() is best used on classes that were
specifically designed for it.

In general, we've had a policy of not converting modules
from old-style to new-style.   This avoids unnecessary
inter-version issues.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227166&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1028088 ] Cookies without values are silently ignored (by design?)

[SourceForge.net]

Bugs item #1028088, was opened at 2004-09-14 13:05
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028088&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Sheppard (sirilyan)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Cookies without values are silently ignored (by design?)

Initial Comment:
Cookie._CookiePattern is the regular expression used to
retrieve cookies from the HTTP_COOKIE environment
variable.  This pattern assumes that all cookies are in
"name=value" format.  A cookie that doesn't have an
"=value" component is silently skipped over.  (It's
easy to generate a cookie like that - in JavaScript,
document.cookie="broken" is all it takes.)

>>> import Cookie
>>> q = Cookie.SimpleCookie("pie=good; broken;
other=thing")
>>> q


If ignoring cookies without a "=value" component is
intended behaviour, it'd be nice to have a code comment
warning that's what happens.  If it's a bug, the cookie
should be set with an empty value.

--

Comment By: John J Lee (jjlee)
Date: 2005-06-29 15:02

Message:
Logged In: YES 
user_id=261020

Though I had previously assumed stability is more important
than the precise details of what module Cookie does (since
you can choose what cookies you send, the only important
thing is that behaviour is relatively sane, and does the job
-- in a standards-compliant way -- with browsers).  But I
suppose one can have JS code or other web app code
maintained by others, and have to understand cookies that
were emitted by that code.  Is that your situation?

Do 'serious' web developers use module Cookie, or do people
now tend to use web frameworks' own cookie code (personally
I don't use cookies in my web application work).  If the
former, perhaps we should not tinker with this module.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028088&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1224347 ] int/long unification and hex()

[SourceForge.net]

Bugs item #1224347, was opened at 2005-06-20 14:22
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224347&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
>Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: int/long unification and hex()

Initial Comment:
There seems to be a bit of an inconsistancy with
int/long unification while using hex().  Specifically;
>>> hex(int(987259835))
'0x3ad863bb'
>>> hex(long(987259835))
'0x3AD863BBL'

I understand that longs will have the trailing 'L'
until Py3k, but I believe the capitalization should be
consistant.  If consistancy is desired, I believe that
lowercase should be the standard, being that
string.encode('hex') also produces lowercase.

If the cases are supposed to be different, or making
the change would produce known backwards
incompatibility for some set of modules, feel free to
close this bug report.

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-29 18:30

Message:
Logged In: YES 
user_id=80475

Fixed for Py2.5:
   Objects/stringobject.c 2.230
   Objects/longobject.c 1.168
   Lib/test/test_long.py 1.27
Not worth backporting and possibly breaking someone's doctests.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-06-22 13:10

Message:
Logged In: YES 
user_id=593130

The trailing L is perhaps easier to see as not a digit if other 
letters are lowercase:  0x3ad863bbL, versus above.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224347&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1227480 ] Two requests to one file are not done in parallel

[SourceForge.net]

Bugs item #1227480, was opened at 2005-06-25 12:24
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Franz (mmf1987)
Assigned to: Nobody/Anonymous (nobody)
Summary: Two requests to one file are not done in parallel

Initial Comment:
Hi! 

I am using Python for CGI scripting. I had a little cgi 
script (see the attached file).

I saved it as test1.py - and tried to load it over HTTP. So 
everything is fine.

But now I saw a very strange behaviour: I sent two 
parallel requests to 
the script (for example by sending two requests in two 
browser windows 
almost at the same time). 

My problem: The requests to the script seem NOT to be 
done in parallel: 
The first script prints "starting..." and after a short time 
"finished". And then in the other browser window the 
second request 
shows "starting...". 

But I expected that in both browser windows "starting" 
will be shown 
almost at the same time because the two requests are 
done in parallel. 

The strange behaviour goes on: 
If copied the test1.py and saved it as test2.py. Now I 
retried my test 
and sent two requests - but to these two identical files 
(that only 
differ in their filename). The the two requests seem to be 
done in 
parallel... 

(It tried my test on Fedora and Gentoo Linux, with 
Python 2.2 and 
Python 2.4, with different webservers (Apache and 
others), and with 
several different browsers - I always was the same.) 

I think the behaviour will be the same if I use my script 
on the command line...

Best regards,
Markus Franz

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-06-29 23:20

Message:
Logged In: YES 
user_id=341410

I doubt that this is a Python issue.  It seems more likely
that your web servers are only willing to spawn a single CGI
process at any one time.

--

Comment By: Sean Reifschneider (jafo)
Date: 2005-06-28 19:53

Message:
Logged In: YES 
user_id=81797

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

--

Comment By: Sean Reifschneider (jafo)
Date: 2005-06-28 19:51

Message:
Logged In: YES 
user_id=81797

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

--

Comment By: Sean Reifschneider (jafo)
Date: 2005-06-28 19:50

Message:
Logged In: YES 
user_id=81797

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

--

Comment By: Sean Reifschneider (jafo)
Date: 2005-06-28 19:46

Message:
Logged In: YES 
user_id=81797

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

--

Comment By: Sean Reifschneider (jafo)
Date: 2005-06-28 19:35

Message:
Logged In: YES 
user_id=81797

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1230161 ] Build failure

[SourceForge.net]

Bugs item #1230161, was opened at 2005-06-30 06:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230161&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: L.M (ceramond)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build failure

Initial Comment:
./configure + make fails with various errors
on FreeBSD 4.11-RELEASE 

case $MAKEFLAGS in  *-s*)  CC='gcc -pthread'
LDSHARED='gcc -shared' 
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes'
./python -E ./setup.py -q 
build;;  *)  CC='gcc -pthread' LDSHARED='gcc -shared'
OPT='-DNDEBUG -g -O3 
-Wall -Wstrict-prototypes' ./python -E ./setup.py
build;;  esac
Could not find platform independent libraries 
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
import sys, os, getopt, imp, re
ImportError: No module named os
*** Error code 1

If I run "make" again, it stops with this, instead, 
I found it strange because "pwd.so" isn't ready yet.


case $MAKEFLAGS in  *-s*)  CC='gcc -pthread'
LDSHARED='gcc -shared' 
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes'
./python -E ./setup.py -q 
build;;  *)  CC='gcc -pthread' LDSHARED='gcc -shared'
OPT='-DNDEBUG -g -O3 
-Wall -Wstrict-prototypes' ./python -E ./setup.py
build;;  esac
Traceback (most recent call last):
  File "./setup.py", line 1184, in ?
main()
  File "./setup.py", line 1178, in main
scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle',
  File
"/home/mondo/Python-2.4.1/Lib/distutils/core.py", line
123, in setup
dist.parse_config_files()
  File
"/home/mondo/Python-2.4.1/Lib/distutils/dist.py", line
339, in 
parse_config_files
filenames = self.find_config_files()
  File
"/home/mondo/Python-2.4.1/Lib/distutils/dist.py", line
302, in 
find_config_files
check_environ()
  File
"/home/mondo/Python-2.4.1/Lib/distutils/util.py", line
155, in 
check_environ
import pwd
ImportError: No module named pwd
*** Error code 1


I've tried "make clean" + retry, 
giving --prefix=so-and-so to ./configure,
and some other things without success.

I have already built exactly same Python source
on this server several weeks ago (in a different
directory),
and do not understand why it's failing, now.
(Possibly, admin updated something causing build
process to fail...)



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230161&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com