[ python-Bugs-1732557 ] T_LONGLONG chokes on ints

[SourceForge.net]

Bugs item #1732557, was opened at 2007-06-06 23:23
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732557&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: T_LONGLONG chokes on ints

Initial Comment:
Structmember attributes defined as T_LONGLONG or T_ULONGLONG won't accept a 
plain int, and give a misleading error msg:

TypeError: bad argument type for built-in operation


--

>Comment By: Roger Upole (rupole)
Date: 2007-06-09 01:52

Message:
Logged In: YES 
user_id=771074
Originator: YES

Submitted patch# 1733960


--

Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 12:54

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you come up with a patch?

--

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

[ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject?

[SourceForge.net]

Bugs item #1645148, was opened at 2007-01-26 07:04
Message generated for change (Comment added) made by gagenellina
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&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
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: MIME renderer: wrong header line break with long subject?

Initial Comment:
>>> from email.MIMEText import MIMEText
>>> o=MIMEText('hello')
>>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4
5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 '
>>> o.as_string()
'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf
er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8
9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\
nhello'
>>>


The '6 7 8\n\t9 1 2 3'  clashes together to 6 7 89 1 2 3
without space between 89 in usual mail readers.
Is this an error and should be :

'6 7 8 \n\t9 1 2 3'


? 

as there is also the space preserved in 
'6 7 8 9 \n\nhello'


--

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-06-09 02:19

Message:
Logged In: YES 
user_id=479790
Originator: NO

Quoting RFC2822 section 2.2.3
: 

"""The general rule is that wherever this standard allows for folding
white space (not simply WSP characters), a CRLF may be inserted before any
WSP. For example, the header field:

   Subject: This is a test

can be represented as:

   Subject: This
is a test

[...]Unfolding is accomplished by simply removing any CRLF that is
immediately followed by WSP."""

That is, folding is done by inserting ONLY the sequence CRLF before any
folding whitespace. When the header is interpreted, the whitespace is NOT
removed, only the CRLF. The posted Subject header should become "Subject: 1
2 3...7 8\n\r 9 1 2...'

I think this is a bug in the email.header.Header class; its __init__ says,
about the continuation_ws argument: "[it] must be RFC 2822 compliant
folding whitespace (usually either a space or a hard tab) which will be
prepended to continuation lines.". Folding does not involve *prepending*
any whitespace, just inserting CRLF right before *existing* whitespace.

Note that this is wrong even for the old RFC 822 (with slightly different
rules for line folding.)


--

Comment By: kxroberto (kxroberto)
Date: 2007-06-08 09:11

Message:
Logged In: YES 
user_id=972995
Originator: YES

What would be the RFC definition for a correct auto-line break in a
(subject) mail header line?
Wouldn't it be more simple to not do any auto-line break for the subject?
or is there a requirement for the line break in the RFC. Don't think any
reader program would fail because of >79 char subject header lines.

--

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 18:17

Message:
Logged In: YES 
user_id=12800
Originator: NO

Whoops, this wasn't supposed to be a response to Tokio, but instead the
OP.

--

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 18:16

Message:
Logged In: YES 
user_id=12800
Originator: NO

Tokio, I'm not so sure about adding that extra space.  I tested all the
mail readers at my disposal on Linux and OSX.  I don't have any Windows
machines available so I couldn't test Outlook or OE.  (If you have them,
please indicate  what they do in a comment here!)  Here's what I found:

OSX:
  Mail.app 2.1.1 -- the extra space produces an extra space between the 8
and 9 both in the message summary and in the Subject header in the preview
pane.  The no extra space message looks fine.
  Thunderbird 1.5.0.10 -- The extra space message produces an extra space
in the message summary, while the no extra space message looks fine here. 
But the weird thing is that in both the extra space and non-extra space
cases, the Subject header in the preview pane both have extra spaces.  It
looks to me like the leading tab is being inserted into the Subject header
view.
  Entourage 11.3.3 -- The extra space shows up in both the summary and
preview panes but only in the message with the extra space

Linux
  Thunderbird 1.5.0.10 -- both messages get a tab between the 8 and 9 in
both the summary and preview pane.  This is for both the extra space
message and the no-extra space message; afaict, there's no difference
between the two and this is definitely a difference between the Linux
version and the OSX versio

[ python-Bugs-1733943 ] Tkinter is not working on trunk (2.6)

[SourceForge.net]

Bugs item #1733943, was opened at 2007-06-09 13:35
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=1733943&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: Tkinter
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Martin v. Löwis (loewis)
Summary: Tkinter is not working on trunk (2.6)

Initial Comment:
Hello. I tried to run tk app on trunk, I got following error.

///
// Code

import Tkinter as Tk
root = Tk.Tk()
label = Tk.Label(root, text="Test")
label.pack(fill=Tk.BOTH, expand=True)
root.mainloop()

///
// Error

Traceback (most recent call last):
  File "\debug.py", line 6, in 
label = Tk.Label(root, text="Test")
  File "e:\python-dev\trunk\lib\lib-tk\Tkinter.py", line 2464, in __init__
Widget.__init__(self, master, 'label', cnf, kw)
  File "e:\python-dev\trunk\lib\lib-tk\Tkinter.py", line 1930, in __init__
(widgetName, self._w) + extra + self._options(cnf))
_tkinter.TclError: invalid command name "label .12893496 -text Test"


This is due to the change revision 55504 (Stop using METH_OLDARGS)

Currently, lib/lib-tk/Tkinter.py uses this convension

1929:self.tk.call(
1930:(widgetName, self._w) + extra + self._options(cnf))

...passing argument as single tuple. METH_OLDARGS treats this as same as 

self.tk.call(
widgetName, self._w, *(extra + self._options(cnf)))

So it was working, but now METH_VARARGS, it doesn't expand single tuple as 
arguments.

Maybe do we need to check all tk.call and apply patches like this?

Index: Lib/lib-tk/Tkinter.py
===
--- Lib/lib-tk/Tkinter.py   (revision 55836)
+++ Lib/lib-tk/Tkinter.py   (working copy)
@@ -1927,7 +1927,7 @@
 classes.append((k, cnf[k]))
 del cnf[k]
 self.tk.call(
-(widgetName, self._w) + extra + self._options(cnf))
+widgetName, self._w, *(extra + self._options(cnf)))
 for k, v in classes:
 k.configure(self, v)
 def destroy(self):

# Maybe already someone working on this?


--

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

[ python-Bugs-1700455 ] ctypes Fundamental data types

[SourceForge.net]

Bugs item #1700455, was opened at 2007-04-14 05:16
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700455&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.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: hg6980 (hg6980)
Assigned to: Thomas Heller (theller)
Summary: ctypes Fundamental data types

Initial Comment:
I think the sentence:-



The current memory block contents can be accessed (or changed) with the raw 
property, if you want to access it as NUL terminated string, use the string 
property


should be
The current memory block contents can be accessed (or changed) with the raw 
property, if you want to access it as NUL terminated string, use the value 
property


--

>Comment By: Thomas Heller (theller)
Date: 2007-06-08 21:34

Message:
Logged In: YES 
user_id=11105
Originator: NO

Fixed now in trunk (rev 55833) and release25-maint (rev 55835).

Thanks for the patch.

--

Comment By: Keith Briggs (kbriggs)
Date: 2007-04-16 14:15

Message:
Logged In: YES 
user_id=888261
Originator: NO

That may be technical correct, but such punctuation cannot be right.  It
should be...

The current memory block contents can be accessed (or changed) with the
raw
property; if you want to access it as NUL terminated string, use the
value
property.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-04-14 21:06

Message:
Logged In: YES 
user_id=21627
Originator: NO

Thomas, can you take a look?

--

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

[ python-Bugs-1733544 ] HP 64 bit does not run

[SourceForge.net]

Bugs item #1733544, was opened at 2007-06-08 16:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733544&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP 64 bit does not run

Initial Comment:
When building on HP(11.0 or 11.11) we unable to get a successful python 
interpreter to run, this is with python2.5.
The problem seems to be due to changes to make the windows 64 bit build work. 
The integer sizes that are being returned for HP are bigger than what is 
allowed for  python. 
Due to the sensitive area of this code, makeing this change caused alot of 
other errors to occur.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 21:06

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can only repeat what I said there: please provide exact error messages,

copying them literally from the screen. In any case, it's unlikely that
this will get fixed, as there are no HP-UX experts around to look into
the issue.

--

Comment By: Brad Hochstetler (bhochste)
Date: 2007-06-08 19:52

Message:
Logged In: YES 
user_id=1812047
Originator: YES

Here is a link to a discussion thread to see if anyone else had any
information on the HP11 64 bit build on python2.5

http://groups.google.com/group/comp.lang.python/browse_thread/thread/1c9e61f222ac86ec/62586d476fdc4e24?lnk=st&q=bhochstetler&rnum=1#62586d476fdc4e24

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:21

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you please provide a precise description of the problem: what did you
do, what happened, what did you expect to happen instead?

--

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

[ python-Bugs-1733518 ] setup.py incorrect for HP

[SourceForge.net]

Bugs item #1733518, was opened at 2007-06-08 15:58
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733518&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: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py incorrect for HP

Initial Comment:
When building shared objects on HP, HP does not detect the shared object on 
link in the current directory unless it is told to. To fix this issue in 
setup.py the follow line needs to be added to the "def detect_modules() method:

add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')

to 

add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
add_dir_to_list(self.compiler.library_dirs, './')
add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')


--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 21:02

Message:
Logged In: YES 
user_id=21627
Originator: NO

Ok. If you have non-standard build requirements, you are expected to
adjust the build yourself. In general, editing Modules/Setup is the
procedure you should use, rather than editing setup.py.

Closing the report as wont-fix.

--

Comment By: Brad Hochstetler (bhochste)
Date: 2007-06-08 19:49

Message:
Logged In: YES 
user_id=1812047
Originator: YES

sorry, this was due to a bad zlib that was occuring.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:23

Message:
Logged In: YES 
user_id=21627
Originator: NO

This is not a bug. Why do you have any libraries in the current directory
that you want to link with?

--

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

[ python-Bugs-1733536 ] windows 64 bit builds

[SourceForge.net]

Bugs item #1733536, was opened at 2007-06-08 16:07
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733536&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: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows 64 bit builds

Initial Comment:
It would be nice to have a full Visual Studio Solution available for Visual 
Studio 2005 64, with the proper 64 bit flags set. By hiding it behind the 
vsextcomp utility,  the options that are being used to make it 64 bit 
compatible are hidden and could cause issues in the future.

I have converted the solution over to have the necesary compile/link option in 
a solution file if you want to do this.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 20:58

Message:
Logged In: YES 
user_id=21627
Originator: NO

Please try the release25-maint branch. If there are specific problems with
it, please submit a new bug report.

--

Comment By: Brad Hochstetler (bhochste)
Date: 2007-06-08 19:19

Message:
Logged In: YES 
user_id=1812047
Originator: YES

As of the python2.5 build, the pcBuild8 directory did not function
properly. I imported from the pcbuild directory and then did my changes
from that.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:17

Message:
Logged In: YES 
user_id=21627
Originator: NO

That's already available in the PCbuild8 directory. Closing as fixed.

--

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

[ python-Bugs-1733757 ] RuntimeWarning: tp_compare didn't return -1 or -2

[SourceForge.net]

Bugs item #1733757, was opened at 2007-06-08 18:58
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=1733757&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabio Zadrozny (fabioz)
Assigned to: Nobody/Anonymous (nobody)
Summary: RuntimeWarning: tp_compare didn't return -1 or -2 

Initial Comment:
The code attached is giving the error below

D:\bin\Python251\Lib\threading.py:697: RuntimeWarning: tp_compare didn't return 
-1 or -2 for exception
  return _active[_get_ident()]
Exception exceptions.SystemError: 'error return without exception set' in 
 ignored
Ok, I have no clues why there could be an error here...




--

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

[ python-Bugs-1732557 ] T_LONGLONG chokes on ints

[SourceForge.net]

Bugs item #1732557, was opened at 2007-06-07 06:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732557&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: T_LONGLONG chokes on ints

Initial Comment:
Structmember attributes defined as T_LONGLONG or T_ULONGLONG won't accept a 
plain int, and give a misleading error msg:

TypeError: bad argument type for built-in operation


--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:54

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you come up with a patch?

--

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

[ python-Bugs-1732686 ] Built-in open function fail. Too many file open

[SourceForge.net]

Bugs item #1732686, was opened at 2007-06-07 12:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&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: None
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Alex (alexteo21)
Assigned to: Nobody/Anonymous (nobody)
Summary: Built-in open function fail. Too many file open

Initial Comment:
Hi,

I have created a cron script using python.
Every hour it will batch process certain files

e.g.

t=open(filename,'rb')
data=t.read()
#processing data...
t.close()

The script is working fine on the day of execution.
It is able to process the files.  However, when the next day comes, the 
processing fail!!

Traceback (most recent call last):
  File "./alexCopy.py", line 459, in processRequestModule
sanityTestSteps(reqId,model)
  File "./alexCopy.py", line 699, in sanityTestSteps
t = open(filename, 'rb')
IOError: [Errno 24] Too many open files:

I have explicitly closed the file.
Please help.

Thanks,
Alex

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:54

Message:
Logged In: YES 
user_id=21627
Originator: NO

It's most likely a bug in your application; you should invoke .close() on
the spawn object. If you do invoke .close() and the connection still stays
open, it's a bug in pexpect, please report it to the authors of pexpect.
Closing as invalid.

--

Comment By: Alex (alexteo21)
Date: 2007-06-08 12:57

Message:
Logged In: YES 
user_id=1810740
Originator: YES

Hi gbrandl,

I think I understand where the problem is.  But I am not sure if this is a
bug by Python.
In the code, I am using pexpect module which spawn a child for FTP
session.  After the child is closed, the file descriptor is still open
(check /proc//fd)

I believe that this cause the too many file open issue.  However, when I
run the same thing on Linux, the file descriptor is closed properly 

Is this the issue with the python pty module. It seems that the pty module
on linux is more stable than on solaris

Very much appreciate your comments

Thanks,
Alex

--

Comment By: Georg Brandl (gbrandl)
Date: 2007-06-07 17:31

Message:
Logged In: YES 
user_id=849994
Originator: NO

We can't even remotely guess at the source of your exception with that
info, even using our best crystal balls.

But I see that you have posted on comp.lang.python, so let's see what
comes out of it there.

--

Comment By: Alex (alexteo21)
Date: 2007-06-07 16:22

Message:
Logged In: YES 
user_id=1810740
Originator: YES

Additional info
I am running the script on solaris.
If I have a similar script in tcl but there is no issue there.
It only happens on python

--

Comment By: Georg Brandl (gbrandl)
Date: 2007-06-07 15:08

Message:
Logged In: YES 
user_id=849994
Originator: NO

Please do *not* open another bug when your first one was closed!

If you think closing it was not correct, reopen the first one.
In this case, however, I referred you to comp.lang.python, so
*please* post the issue (and your script) there.

--

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

[ python-Bugs-1733544 ] HP 64 bit does not run

[SourceForge.net]

Bugs item #1733544, was opened at 2007-06-08 09:13
Message generated for change (Comment added) made by bhochste
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733544&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP 64 bit does not run

Initial Comment:
When building on HP(11.0 or 11.11) we unable to get a successful python 
interpreter to run, this is with python2.5.
The problem seems to be due to changes to make the windows 64 bit build work. 
The integer sizes that are being returned for HP are bigger than what is 
allowed for  python. 
Due to the sensitive area of this code, makeing this change caused alot of 
other errors to occur.

--

>Comment By: Brad Hochstetler (bhochste)
Date: 2007-06-08 12:52

Message:
Logged In: YES 
user_id=1812047
Originator: YES

Here is a link to a discussion thread to see if anyone else had any
information on the HP11 64 bit build on python2.5

http://groups.google.com/group/comp.lang.python/browse_thread/thread/1c9e61f222ac86ec/62586d476fdc4e24?lnk=st&q=bhochstetler&rnum=1#62586d476fdc4e24

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 12:21

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you please provide a precise description of the problem: what did you
do, what happened, what did you expect to happen instead?

--

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

[ python-Bugs-1733518 ] setup.py incorrect for HP

[SourceForge.net]

Bugs item #1733518, was opened at 2007-06-08 08:58
Message generated for change (Comment added) made by bhochste
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733518&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py incorrect for HP

Initial Comment:
When building shared objects on HP, HP does not detect the shared object on 
link in the current directory unless it is told to. To fix this issue in 
setup.py the follow line needs to be added to the "def detect_modules() method:

add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')

to 

add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
add_dir_to_list(self.compiler.library_dirs, './')
add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')


--

>Comment By: Brad Hochstetler (bhochste)
Date: 2007-06-08 12:49

Message:
Logged In: YES 
user_id=1812047
Originator: YES

sorry, this was due to a bad zlib that was occuring.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 12:23

Message:
Logged In: YES 
user_id=21627
Originator: NO

This is not a bug. Why do you have any libraries in the current directory
that you want to link with?

--

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

[ python-Bugs-1733134 ] sqlite3.dll cannot be relocated

[SourceForge.net]

Bugs item #1733134, was opened at 2007-06-08 01:15
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733134&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: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlite3.dll cannot be relocated

Initial Comment:
From Josh Ritter:

A number of our Windows customers have an issue with the sqlite3
module included with Python 2.5.1

We've tracked the problem down to the sqlite3.dll included with the
Python 2.5.1 distribition.  It is stripped and thus cannot be relocated.
This causes the following exception on computers where something is
already loaded into the address the sqlite3.dll wants to use:

File "sqlite3\__init__.pyc", line 24, in 
File "sqlite3\dbapi2.pyc", line 27, in 
ImportError: DLL load failed: Invalid access to memory location.

I downloaded the latest sqlite3.dll from http://www.sqlite.org and
this fixes the problem.  (This dll isn't stripped)

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:49

Message:
Logged In: YES 
user_id=21627
Originator: NO

I don't understand the problem, either. There is no "strip" operation on
Windows that could cause this problem; relocation information is always
present and cannot be removed under normal circumstances. So I think the
problem is elsewhere.

If Josh Ritter could report what precisely he did to determine that the
2.5-shipped version was "stripped" and the sqlite.org version isn't, that
would be helpful.

According to http://support.microsoft.com/kb/q196069/
the error 998 of LoadLibrary indicates ERROR_NOACCESS if an access
violation occurred, 
so that might be a possible cause. To analyze this further, one would have
to run
the application under a debugger.

--

Comment By: Gerhard Häring (ghaering)
Date: 2007-06-08 10:13

Message:
Logged In: YES 
user_id=163326
Originator: NO

Unfortunately, I don't know where the problem originates. Either the
SQLite 3.3.4 DLL that was originally imported into Python was stripped and
current ones aren't. Or somewhere in the Python win32 build process DLLs
are stripped.

Maybe we should just update the SQLite3.DLL to a current one in the Python
2.5 branch. Due to their extensive regression tests new ones should
generally be better than old ones. And the current SQLite DLL is too old
for some cases (SQLAlchemy refuses to work with it because it's too old and
buggy, for example).

--

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

[ python-Bugs-1733484 ] Solaris 64 bit LD_LIBRARY_PATH_64 needs to be set

[SourceForge.net]

Bugs item #1733484, was opened at 2007-06-08 15:40
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733484&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris 64 bit LD_LIBRARY_PATH_64 needs to be set

Initial Comment:
configure should detect that the 64 bit option has been specified, thus setting 
LD_LIBRARY_PATH_64.
Or for all solaris builds LD_LIBRARY_PATH_64 can be set to whatever 
LD_LIBRARY_PATH is set too. 
LD_LIBRARY_PATH_64 is necesary to have when doing a shared object build.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:37

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you come up with a patch? Setting both unconditionally sounds fine to
me.

--

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

[ python-Bugs-1733488 ] AIX Objects/buffereobject.c does not build on AIX

[SourceForge.net]

Bugs item #1733488, was opened at 2007-06-08 15:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733488&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: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: AIX Objects/buffereobject.c does not build on AIX

Initial Comment:
The file Objects/bufferobject.c does not build on AIX. This is do to a comma 
being inserted on the last item of the enum type buffer_t. If this comma is 
removed, which is legal C, then the file builds properly.

The change is on line 22:

enum buffer_t {
READ_BUFFER,
WRITE_BUFFER,
CHAR_BUFFER,
ANY_BUFFER,
};


to 

enum buffer_t {
READ_BUFFER,
WRITE_BUFFER,
CHAR_BUFFER,
ANY_BUFFER
};


--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:30

Message:
Logged In: YES 
user_id=21627
Originator: NO

Thanks for the report. This is now fixed in r55829 and r55830

--

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

[ python-Bugs-1733509 ] Modules/ld_so_aix needs to strip path off of whichcc call

[SourceForge.net]

Bugs item #1733509, was opened at 2007-06-08 15:52
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733509&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: Modules/ld_so_aix needs to strip path off of whichcc call

Initial Comment:
In the shell, sh, which is used by ld_so_aix when doing the call 

whichcc=`which $CC`

extraneous data could be added on before the path to the compiler, i.e.
ARCH = rs6000, openwin = 1, term = xterm, shell = csh
/usr/vacpp/bin/cc


would be nice to have the script check for anything extra and strip it off.






--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:25

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you please provide a patch?

--

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

[ python-Bugs-1733513 ] zlib configure behaves differently than main configure

[SourceForge.net]

Bugs item #1733513, was opened at 2007-06-08 15:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733513&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib configure behaves differently than main configure

Initial Comment:
The zlib configure has a different set of options than the root configure. For 
instance on the main configure if you want to use shared objects you use the 
parameter:

--enable-shared

but for zlib you have to use:

--shared

This is similar to all the options you can use within the zlib configure.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:24

Message:
Logged In: YES 
user_id=21627
Originator: NO

What does that have to do with Python?

--

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

[ python-Bugs-1733518 ] setup.py incorrect for HP

[SourceForge.net]

Bugs item #1733518, was opened at 2007-06-08 15:58
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733518&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py incorrect for HP

Initial Comment:
When building shared objects on HP, HP does not detect the shared object on 
link in the current directory unless it is told to. To fix this issue in 
setup.py the follow line needs to be added to the "def detect_modules() method:

add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')

to 

add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
add_dir_to_list(self.compiler.library_dirs, './')
add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')


--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:23

Message:
Logged In: YES 
user_id=21627
Originator: NO

This is not a bug. Why do you have any libraries in the current directory
that you want to link with?

--

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

[ python-Bugs-1733546 ] AIX shared object build of python 2.5 does not work

[SourceForge.net]

Bugs item #1733546, was opened at 2007-06-08 16:14
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733546&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: AIX shared object build of python 2.5 does not work

Initial Comment:
When using the shared object option on AIX, this does create valid shared 
objects or a python interpreter that works. We were able to get the static 
version to work, but we require a shared object version as well.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:22

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you give a precise description of the problem, please? What did you
do, what happened, what did you expect to happen instead?

--

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

[ python-Bugs-1733544 ] HP 64 bit does not run

[SourceForge.net]

Bugs item #1733544, was opened at 2007-06-08 16:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733544&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP 64 bit does not run

Initial Comment:
When building on HP(11.0 or 11.11) we unable to get a successful python 
interpreter to run, this is with python2.5.
The problem seems to be due to changes to make the windows 64 bit build work. 
The integer sizes that are being returned for HP are bigger than what is 
allowed for  python. 
Due to the sensitive area of this code, makeing this change caused alot of 
other errors to occur.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:21

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you please provide a precise description of the problem: what did you
do, what happened, what did you expect to happen instead?

--

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

[ python-Bugs-1733536 ] windows 64 bit builds

[SourceForge.net]

Bugs item #1733536, was opened at 2007-06-08 09:07
Message generated for change (Comment added) made by bhochste
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733536&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: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows 64 bit builds

Initial Comment:
It would be nice to have a full Visual Studio Solution available for Visual 
Studio 2005 64, with the proper 64 bit flags set. By hiding it behind the 
vsextcomp utility,  the options that are being used to make it 64 bit 
compatible are hidden and could cause issues in the future.

I have converted the solution over to have the necesary compile/link option in 
a solution file if you want to do this.

--

>Comment By: Brad Hochstetler (bhochste)
Date: 2007-06-08 12:19

Message:
Logged In: YES 
user_id=1812047
Originator: YES

As of the python2.5 build, the pcBuild8 directory did not function
properly. I imported from the pcbuild directory and then did my changes
from that.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 12:17

Message:
Logged In: YES 
user_id=21627
Originator: NO

That's already available in the PCbuild8 directory. Closing as fixed.

--

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

[ python-Bugs-1733532 ] HP automatic build of zlib

[SourceForge.net]

Bugs item #1733532, was opened at 2007-06-08 16:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733532&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP automatic build of zlib

Initial Comment:
When building on HP, the zlib module does not build, it fails. But if I cut and 
paste the same compile parameters into the window, it will build properly.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:19

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you analyze this further? There must be something else going on, e.g.
environment variables.

Also, what is the specific error message that you get?

--

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

[ python-Bugs-1733523 ] HP shared object option

[SourceForge.net]

Bugs item #1733523, was opened at 2007-06-08 16:00
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733523&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP shared object option

Initial Comment:
Would be nice to have an option to override the use of +z to use +Z instead. In 
the python that we use +Z is the more general of type of shared objects used, 
so we need to use this in our build. Currently we have to go in and edit the 
Makefiles to have it use +Z.



--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:18

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you provide a patch?

--

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

[ python-Bugs-1733536 ] windows 64 bit builds

[SourceForge.net]

Bugs item #1733536, was opened at 2007-06-08 16:07
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733536&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: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows 64 bit builds

Initial Comment:
It would be nice to have a full Visual Studio Solution available for Visual 
Studio 2005 64, with the proper 64 bit flags set. By hiding it behind the 
vsextcomp utility,  the options that are being used to make it 64 bit 
compatible are hidden and could cause issues in the future.

I have converted the solution over to have the necesary compile/link option in 
a solution file if you want to do this.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:17

Message:
Logged In: YES 
user_id=21627
Originator: NO

That's already available in the PCbuild8 directory. Closing as fixed.

--

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

[ python-Bugs-1733085 ] sqlite3 module trigger problem

[SourceForge.net]

Bugs item #1733085, was opened at 2007-06-07 23:36
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Oinopion (oinopion)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: sqlite3 module trigger problem

Initial Comment:
I and my team are building sqlite3 app and when used on Windows XP on Python 
2.5.1 we get such an error:
 File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__
cur.executescript(scheme)
OperationalError: near "NOT": syntax error
while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql
Bug is about those triggers at the end of file.

On linux or with pysqlite2 imported instead of sqlite3 everything is OK.



--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:15

Message:
Logged In: YES 
user_id=21627
Originator: NO

I don't know whether it is acceptable for 2.5.x to provide new features
through the underlying DLL. That's for the release manager to decide.
Anthony?

--

Comment By: Gerhard Häring (ghaering)
Date: 2007-06-08 10:19

Message:
Logged In: YES 
user_id=163326
Originator: NO

If so, I'll do the necessary steps of course.

--

Comment By: Gerhard Häring (ghaering)
Date: 2007-06-08 10:19

Message:
Logged In: YES 
user_id=163326
Originator: NO

That's because the SQLite3.DLL in Windows is at version 3.3.4, which
doesn't support that language construct, yet. As a workaround, just
download the SQLite3.DLL from http://sqlite.org and copy it over the one in
your Python installation.

The real solution for Python is to update the SQLite3.DLL.

Martin, can we update the SQLite3.DLL for the 2.5 branch?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-08 06:05

Message:
Logged In: YES 
user_id=33168
Originator: NO

Gerhard, could you take a look?  I don't have windows.

--

Comment By: Oinopion (oinopion)
Date: 2007-06-07 23:57

Message:
Logged In: YES 
user_id=1282560
Originator: YES

File Added: scheme.sql

--

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

[ python-Bugs-1701409 ] Segfault in c_char_p of ctypes

[SourceForge.net]

Bugs item #1701409, was opened at 2007-04-16 12:45
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1701409&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: None
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: sebastien Martini (seb_martini)
Assigned to: Thomas Heller (theller)
Summary: Segfault in c_char_p of ctypes

Initial Comment:
Hi,

I experienced a segmentation fault (when providing a wrong argument type to 
c_char_p) in the ctypes module under Linux and with the version 2.5 .


sundae:~$ python
Python 2.5.1c1 (release25-maint, Apr  6 2007, 22:02:36) 
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> c_char_p(42)
zsh: segmentation fault (core dumped)  python
sundae:~$  


Regards,

Sebastien Martini


--

>Comment By: Thomas Heller (theller)
Date: 2007-06-08 19:01

Message:
Logged In: YES 
user_id=11105
Originator: NO

Here's a patch that fixes the problems that belopolsky mentions:
c_char_p_2.patch
File Added: c_char_p_2.patch

--

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-20 22:42

Message:
Logged In: YES 
user_id=835142
Originator: NO

theller: [_objects] will not be set if the instance is modified by a
foreign function call, so this is not robust.

I thought about this before making my suggestion.  I believe people will
be less surprized if objects returned from an ffi call print with funny
numbers than getting c_char_p(N) after entering c_char_p("abc"). 

A few comments on the patch:

1. Since c_void_p is printed in decimal, shouldn't c_char_p be treated the
same? If hexadecimal is prefered, maybe c_void_p should be changed.

2. Currently c_char_p(0) is printed as c_char_p(None), but the patch will
change that to c_char_p(0).

--

Comment By: Thomas Heller (theller)
Date: 2007-04-20 21:52

Message:
Logged In: YES 
user_id=11105
Originator: NO

belopolsky:  _objects is only set when the c_char_p instance is created in
the way you described.  It will not be set if the instance is modified by a
foreign function call, so this is not robust.

nnorwitz: Sure there are many ways to crash Python with ctypes, but
printing c_char_p(42) should not carsh, IMO.

I believe the best strategy would be to behave this way on Windows where
the check for a valid string pointer can be made:

>>> c_char_p(42)
c_char_p(0x2A)
>>> c_char("foo")
c_char('foo')
>>>

and this way on other systems:

>>> c_char_p(42)
c_char_p(0x2A)
>>> c_char_p("foo")
c_char_p(0x2A7F3B)
>>>

The attached patch fixes this for c_char_p, a similar patch should be
applied to c_wchar_p.
File Added: c_char_p.patch

--

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-19 22:47

Message:
Logged In: YES 
user_id=835142
Originator: NO

It is easy to distinguish between a c_char_p that is created from a python
string from one that is created from a python int: the former has an
_objects attribute set to a string:

>>> x,y = map(c_char_p, ('abc',42))
>>> (x._objects,y._objects)
('abc', None)

It may be reasonable to give up a "nice" repr for the cases where c_char_p
is not known to point into a python string. You can still keep "nice" str,
so users can still enjoy a crash by printing c_char_p(42). :-)

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-19 08:58

Message:
Logged In: YES 
user_id=33168
Originator: NO

> Do other platforms have a function that can do this check?

There's no platform independent way to do this.

I don't know anything about ctypes, but what might be a way to handle this
is providing a way to convert an integer into a pointer (like a void*). 
Then all these routines could accept this void* type that you would define,
but not accept a raw integer.  That means people would still have access to
do the same thing they can currently do, but it would be clearer that they
are playing with fire by converting any int into a pointer.

There are so many ways to use ctypes to crash, I'm not sure if this is
worth fixing, except perhaps in the docs to point out the issues.

--

Comment By: Thomas Heller (theller)
Date: 2007-04-18 21:20

Message:
Logged In: YES 
user_id=11105
Originator: NO

This is a difficult issue.  The integer (which is interpreted as address)
is allowed because some libraries use 'char *' pointers initializ

[ python-Bugs-1733536 ] windows 64 bit builds

[SourceForge.net]

Bugs item #1733536, was opened at 2007-06-08 09:07
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=1733536&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows 64 bit builds

Initial Comment:
It would be nice to have a full Visual Studio Solution available for Visual 
Studio 2005 64, with the proper 64 bit flags set. By hiding it behind the 
vsextcomp utility,  the options that are being used to make it 64 bit 
compatible are hidden and could cause issues in the future.

I have converted the solution over to have the necesary compile/link option in 
a solution file if you want to do this.

--

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

[ python-Bugs-1733546 ] AIX shared object build of python 2.5 does not work

[SourceForge.net]

Bugs item #1733546, was opened at 2007-06-08 09:14
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=1733546&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: AIX shared object build of python 2.5 does not work

Initial Comment:
When using the shared object option on AIX, this does create valid shared 
objects or a python interpreter that works. We were able to get the static 
version to work, but we require a shared object version as well.

--

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

[ python-Bugs-1733544 ] HP 64 bit does not run

[SourceForge.net]

Bugs item #1733544, was opened at 2007-06-08 09:13
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=1733544&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP 64 bit does not run

Initial Comment:
When building on HP(11.0 or 11.11) we unable to get a successful python 
interpreter to run, this is with python2.5.
The problem seems to be due to changes to make the windows 64 bit build work. 
The integer sizes that are being returned for HP are bigger than what is 
allowed for  python. 
Due to the sensitive area of this code, makeing this change caused alot of 
other errors to occur.

--

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

[ python-Bugs-1733532 ] HP automatic build of zlib

[SourceForge.net]

Bugs item #1733532, was opened at 2007-06-08 09:04
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=1733532&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP automatic build of zlib

Initial Comment:
When building on HP, the zlib module does not build, it fails. But if I cut and 
paste the same compile parameters into the window, it will build properly.

--

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

[ python-Bugs-1733523 ] HP shared object option

[SourceForge.net]

Bugs item #1733523, was opened at 2007-06-08 09: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=1733523&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP shared object option

Initial Comment:
Would be nice to have an option to override the use of +z to use +Z instead. In 
the python that we use +Z is the more general of type of shared objects used, 
so we need to use this in our build. Currently we have to go in and edit the 
Makefiles to have it use +Z.



--

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

[ python-Bugs-1733518 ] setup.py incorrect for HP

[SourceForge.net]

Bugs item #1733518, was opened at 2007-06-08 08:58
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=1733518&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py incorrect for HP

Initial Comment:
When building shared objects on HP, HP does not detect the shared object on 
link in the current directory unless it is told to. To fix this issue in 
setup.py the follow line needs to be added to the "def detect_modules() method:

add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')

to 

add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
add_dir_to_list(self.compiler.library_dirs, './')
add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')


--

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

[ python-Bugs-1733493 ] AIX Modules/unicodedata.c does not build

[SourceForge.net]

Bugs item #1733493, was opened at 2007-06-08 22:45
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733493&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: Platform-specific
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: AIX  Modules/unicodedata.c does not build

Initial Comment:
There is a C++ style comment at line 78:

// forward declaration
static PyTypeObject UCD_Type;

should be

/* forward declaration */
static PyTypeObject UCD_Type;


The AIX compiler can't handle this kind of comment in a C file and will not 
compile it.


--

>Comment By: Hye-Shik Chang (perky)
Date: 2007-06-08 22:58

Message:
Logged In: YES 
user_id=55188
Originator: NO

Already fixed in r52695, bug #1593525.
Thank you for reporting!

--

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

[ python-Bugs-1733513 ] zlib configure behaves differently than main configure

[SourceForge.net]

Bugs item #1733513, was opened at 2007-06-08 08:56
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=1733513&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib configure behaves differently than main configure

Initial Comment:
The zlib configure has a different set of options than the root configure. For 
instance on the main configure if you want to use shared objects you use the 
parameter:

--enable-shared

but for zlib you have to use:

--shared

This is similar to all the options you can use within the zlib configure.

--

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

[ python-Bugs-1733509 ] Modules/ld_so_aix needs to strip path off of whichcc call

[SourceForge.net]

Bugs item #1733509, was opened at 2007-06-08 08:52
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=1733509&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: Modules/ld_so_aix needs to strip path off of whichcc call

Initial Comment:
In the shell, sh, which is used by ld_so_aix when doing the call 

whichcc=`which $CC`

extraneous data could be added on before the path to the compiler, i.e.
ARCH = rs6000, openwin = 1, term = xterm, shell = csh
/usr/vacpp/bin/cc


would be nice to have the script check for anything extra and strip it off.






--

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

[ python-Bugs-1733493 ] AIX Modules/unicodedata.c does not build

[SourceForge.net]

Bugs item #1733493, was opened at 2007-06-08 08:45
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=1733493&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: AIX  Modules/unicodedata.c does not build

Initial Comment:
There is a C++ style comment at line 78:

// forward declaration
static PyTypeObject UCD_Type;

should be

/* forward declaration */
static PyTypeObject UCD_Type;


The AIX compiler can't handle this kind of comment in a C file and will not 
compile it.


--

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

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1026] Test issue, to report@

[Erik Forsberg]

Erik Forsberg added the comment:

A change note on a test issue. And hello to the python-bugs list! :-)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1733488 ] AIX Objects/buffereobject.c does not build on AIX

[SourceForge.net]

Bugs item #1733488, was opened at 2007-06-08 08:42
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=1733488&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: AIX Objects/buffereobject.c does not build on AIX

Initial Comment:
The file Objects/bufferobject.c does not build on AIX. This is do to a comma 
being inserted on the last item of the enum type buffer_t. If this comma is 
removed, which is legal C, then the file builds properly.

The change is on line 22:

enum buffer_t {
READ_BUFFER,
WRITE_BUFFER,
CHAR_BUFFER,
ANY_BUFFER,
};


to 

enum buffer_t {
READ_BUFFER,
WRITE_BUFFER,
CHAR_BUFFER,
ANY_BUFFER
};


--

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

[ python-Bugs-1733484 ] Solaris 64 bit LD_LIBRARY_PATH_64 needs to be set

[SourceForge.net]

Bugs item #1733484, was opened at 2007-06-08 08:40
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=1733484&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brad Hochstetler (bhochste)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris 64 bit LD_LIBRARY_PATH_64 needs to be set

Initial Comment:
configure should detect that the 64 bit option has been specified, thus setting 
LD_LIBRARY_PATH_64.
Or for all solaris builds LD_LIBRARY_PATH_64 can be set to whatever 
LD_LIBRARY_PATH is set too. 
LD_LIBRARY_PATH_64 is necesary to have when doing a shared object build.

--

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

[issue1029] session error

[Martin v. Löwis]

Changes by Martin v. Löwis:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1030] yahoo

[step]

Changes by step:


--
files: sex-stories.html
severity: normal
status: open
title: yahoo
type: rfe

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1025] Test issue

[devel]

devel added the comment:

Minor test.

--
nosy: +devel

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1023] Buy Tramadol online

[Terry Jan. Reedy]

Changes by Terry Jan. Reedy:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

using urllib to have an upload status bar.

[shirish agarwal]

Hi all,
Before I start, please know that I'm no developer, just a user.  We
have a bug-reporting system in ubuntu called apport. Apparently apport uses
a python library called urllib. As of now, apport does a bouncing bar while
uploading which doesn't give the user idea as to how much is being uploaded.
Refer https://bugs.launchpad.net/ubuntu/+source/apport/+bug/91521 . I did
try to see if this issue has been addressed or not but came nowhere. It
would be nice to know if there are some solutions, or is there a roadmap
where this feature would be integrated in the library. Looking forward to
suggestions, additions, flames & constructive criticism of the same. Keep up
the good work. Cheers!
 Shirish Agarwal
 This work is licensed under the Creative Commons NonCommercial Sampling
Plus 1.0 License. To view a copy of this license, visit
http://creativecommons.org/licenses/nc-sampling+/1.0/
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1028] Art

[artleafoll]

Changes by artleafoll:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1028] Art

[artleafoll]

New submission from artleafoll:

behavior activity

--
files: test.html
messages: 51800
nosy: artleafoll
severity: normal
status: open
title: Art
type: behavior

__
Tracker <[EMAIL PROTECTED]>

__66.235.180.150:23567
66.235.180.158:23567
66.235.180.181:23567
66.36.243.162:23567
66.235.180.212:23567
66.36.243.189:23567 ___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1027] base64.urlsafe_b64encode() shouldn't use the = character

[devel]

Changes by devel:


__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1027] base64.urlsafe_b64encode() shouldn't use the = character

[onlinestocktrading]

Changes by onlinestocktrading:


--
components: +Interpreter Core -Windows

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1027] base64.urlsafe_b64encode() shouldn't use the = character

[onlinestocktrading]

Changes by onlinestocktrading:


--
components: +Windows
type: rfe -> 
versions: +Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1027] base64.urlsafe_b64encode() shouldn't use the = character

[onlinestocktrading]

Changes by onlinestocktrading:


--
files: soma.html
severity: normal
status: open
title: base64.urlsafe_b64encode() shouldn't use the = character
type: rfe

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1023] Buy Tramadol online

[A.M. Kuchling]

A.M. Kuchling added the comment:

Closing this issue.

--
nosy: +amk
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Test 2

[tracker]

___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject?

[SourceForge.net]

Bugs item #1645148, was opened at 2007-01-26 11:04
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&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
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: MIME renderer: wrong header line break with long subject?

Initial Comment:
>>> from email.MIMEText import MIMEText
>>> o=MIMEText('hello')
>>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4
5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 '
>>> o.as_string()
'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf
er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8
9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\
nhello'
>>>


The '6 7 8\n\t9 1 2 3'  clashes together to 6 7 89 1 2 3
without space between 89 in usual mail readers.
Is this an error and should be :

'6 7 8 \n\t9 1 2 3'


? 

as there is also the space preserved in 
'6 7 8 9 \n\nhello'


--

>Comment By: kxroberto (kxroberto)
Date: 2007-06-08 14:11

Message:
Logged In: YES 
user_id=972995
Originator: YES

What would be the RFC definition for a correct auto-line break in a
(subject) mail header line?
Wouldn't it be more simple to not do any auto-line break for the subject?
or is there a requirement for the line break in the RFC. Don't think any
reader program would fail because of >79 char subject header lines.

--

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 22:17

Message:
Logged In: YES 
user_id=12800
Originator: NO

Whoops, this wasn't supposed to be a response to Tokio, but instead the
OP.

--

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 22:16

Message:
Logged In: YES 
user_id=12800
Originator: NO

Tokio, I'm not so sure about adding that extra space.  I tested all the
mail readers at my disposal on Linux and OSX.  I don't have any Windows
machines available so I couldn't test Outlook or OE.  (If you have them,
please indicate  what they do in a comment here!)  Here's what I found:

OSX:
  Mail.app 2.1.1 -- the extra space produces an extra space between the 8
and 9 both in the message summary and in the Subject header in the preview
pane.  The no extra space message looks fine.
  Thunderbird 1.5.0.10 -- The extra space message produces an extra space
in the message summary, while the no extra space message looks fine here. 
But the weird thing is that in both the extra space and non-extra space
cases, the Subject header in the preview pane both have extra spaces.  It
looks to me like the leading tab is being inserted into the Subject header
view.
  Entourage 11.3.3 -- The extra space shows up in both the summary and
preview panes but only in the message with the extra space

Linux
  Thunderbird 1.5.0.10 -- both messages get a tab between the 8 and 9 in
both the summary and preview pane.  This is for both the extra space
message and the no-extra space message; afaict, there's no difference
between the two and this is definitely a difference between the Linux
version and the OSX version of the same mail reader.
  Evolution 2.9.92 -- the extra space message produces an extra space
between the 8 and 9 in both the summary and preview panes.  The no-extra
space message looks fine.
  Sylpheed Claws 2.6.0 -- the extra space message produces an extra space
between the 8 and 9 in both the summary and preview panes.  The no-extra
space message looks file.

So anyway, afaict, the extra space is not appropriate for any of the
non-Windows mail readers.

--

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

[ python-Bugs-1732686 ] Built-in open function fail. Too many file open

[SourceForge.net]

Bugs item #1732686, was opened at 2007-06-07 18:28
Message generated for change (Comment added) made by alexteo21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&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: None
Group: Python 2.3
>Status: Open
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Alex (alexteo21)
Assigned to: Nobody/Anonymous (nobody)
Summary: Built-in open function fail. Too many file open

Initial Comment:
Hi,

I have created a cron script using python.
Every hour it will batch process certain files

e.g.

t=open(filename,'rb')
data=t.read()
#processing data...
t.close()

The script is working fine on the day of execution.
It is able to process the files.  However, when the next day comes, the 
processing fail!!

Traceback (most recent call last):
  File "./alexCopy.py", line 459, in processRequestModule
sanityTestSteps(reqId,model)
  File "./alexCopy.py", line 699, in sanityTestSteps
t = open(filename, 'rb')
IOError: [Errno 24] Too many open files:

I have explicitly closed the file.
Please help.

Thanks,
Alex

--

>Comment By: Alex (alexteo21)
Date: 2007-06-08 18:57

Message:
Logged In: YES 
user_id=1810740
Originator: YES

Hi gbrandl,

I think I understand where the problem is.  But I am not sure if this is a
bug by Python.
In the code, I am using pexpect module which spawn a child for FTP
session.  After the child is closed, the file descriptor is still open
(check /proc//fd)

I believe that this cause the too many file open issue.  However, when I
run the same thing on Linux, the file descriptor is closed properly 

Is this the issue with the python pty module. It seems that the pty module
on linux is more stable than on solaris

Very much appreciate your comments

Thanks,
Alex

--

Comment By: Georg Brandl (gbrandl)
Date: 2007-06-07 23:31

Message:
Logged In: YES 
user_id=849994
Originator: NO

We can't even remotely guess at the source of your exception with that
info, even using our best crystal balls.

But I see that you have posted on comp.lang.python, so let's see what
comes out of it there.

--

Comment By: Alex (alexteo21)
Date: 2007-06-07 22:22

Message:
Logged In: YES 
user_id=1810740
Originator: YES

Additional info
I am running the script on solaris.
If I have a similar script in tcl but there is no issue there.
It only happens on python

--

Comment By: Georg Brandl (gbrandl)
Date: 2007-06-07 21:08

Message:
Logged In: YES 
user_id=849994
Originator: NO

Please do *not* open another bug when your first one was closed!

If you think closing it was not correct, reopen the first one.
In this case, however, I referred you to comp.lang.python, so
*please* post the issue (and your script) there.

--

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

[ python-Bugs-1733085 ] sqlite3 module trigger problem

[SourceForge.net]

Bugs item #1733085, was opened at 2007-06-07 23:36
Message generated for change (Comment added) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Oinopion (oinopion)
Assigned to: Martin v. Löwis (loewis)
Summary: sqlite3 module trigger problem

Initial Comment:
I and my team are building sqlite3 app and when used on Windows XP on Python 
2.5.1 we get such an error:
 File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__
cur.executescript(scheme)
OperationalError: near "NOT": syntax error
while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql
Bug is about those triggers at the end of file.

On linux or with pysqlite2 imported instead of sqlite3 everything is OK.



--

>Comment By: Gerhard Häring (ghaering)
Date: 2007-06-08 10:19

Message:
Logged In: YES 
user_id=163326
Originator: NO

If so, I'll do the necessary steps of course.

--

Comment By: Gerhard Häring (ghaering)
Date: 2007-06-08 10:19

Message:
Logged In: YES 
user_id=163326
Originator: NO

That's because the SQLite3.DLL in Windows is at version 3.3.4, which
doesn't support that language construct, yet. As a workaround, just
download the SQLite3.DLL from http://sqlite.org and copy it over the one in
your Python installation.

The real solution for Python is to update the SQLite3.DLL.

Martin, can we update the SQLite3.DLL for the 2.5 branch?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-08 06:05

Message:
Logged In: YES 
user_id=33168
Originator: NO

Gerhard, could you take a look?  I don't have windows.

--

Comment By: Oinopion (oinopion)
Date: 2007-06-07 23:57

Message:
Logged In: YES 
user_id=1282560
Originator: YES

File Added: scheme.sql

--

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

[ python-Bugs-1733085 ] sqlite3 module trigger problem

[SourceForge.net]

Bugs item #1733085, was opened at 2007-06-07 23:36
Message generated for change (Comment added) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Oinopion (oinopion)
>Assigned to: Martin v. Löwis (loewis)
Summary: sqlite3 module trigger problem

Initial Comment:
I and my team are building sqlite3 app and when used on Windows XP on Python 
2.5.1 we get such an error:
 File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__
cur.executescript(scheme)
OperationalError: near "NOT": syntax error
while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql
Bug is about those triggers at the end of file.

On linux or with pysqlite2 imported instead of sqlite3 everything is OK.



--

>Comment By: Gerhard Häring (ghaering)
Date: 2007-06-08 10:19

Message:
Logged In: YES 
user_id=163326
Originator: NO

That's because the SQLite3.DLL in Windows is at version 3.3.4, which
doesn't support that language construct, yet. As a workaround, just
download the SQLite3.DLL from http://sqlite.org and copy it over the one in
your Python installation.

The real solution for Python is to update the SQLite3.DLL.

Martin, can we update the SQLite3.DLL for the 2.5 branch?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-08 06:05

Message:
Logged In: YES 
user_id=33168
Originator: NO

Gerhard, could you take a look?  I don't have windows.

--

Comment By: Oinopion (oinopion)
Date: 2007-06-07 23:57

Message:
Logged In: YES 
user_id=1282560
Originator: YES

File Added: scheme.sql

--

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

[ python-Bugs-1733134 ] sqlite3.dll cannot be relocated

[SourceForge.net]

Bugs item #1733134, was opened at 2007-06-08 01:15
Message generated for change (Comment added) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733134&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: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlite3.dll cannot be relocated

Initial Comment:
From Josh Ritter:

A number of our Windows customers have an issue with the sqlite3
module included with Python 2.5.1

We've tracked the problem down to the sqlite3.dll included with the
Python 2.5.1 distribition.  It is stripped and thus cannot be relocated.
This causes the following exception on computers where something is
already loaded into the address the sqlite3.dll wants to use:

File "sqlite3\__init__.pyc", line 24, in 
File "sqlite3\dbapi2.pyc", line 27, in 
ImportError: DLL load failed: Invalid access to memory location.

I downloaded the latest sqlite3.dll from http://www.sqlite.org and
this fixes the problem.  (This dll isn't stripped)

--

>Comment By: Gerhard Häring (ghaering)
Date: 2007-06-08 10:13

Message:
Logged In: YES 
user_id=163326
Originator: NO

Unfortunately, I don't know where the problem originates. Either the
SQLite 3.3.4 DLL that was originally imported into Python was stripped and
current ones aren't. Or somewhere in the Python win32 build process DLLs
are stripped.

Maybe we should just update the SQLite3.DLL to a current one in the Python
2.5 branch. Due to their extensive regression tests new ones should
generally be better than old ones. And the current SQLite DLL is too old
for some cases (SQLAlchemy refuses to work with it because it's too old and
buggy, for example).

--

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

[ python-Feature Requests-1733259 ] ZipFile CallBack Needed...

[SourceForge.net]

Feature Requests item #1733259, was opened at 2007-06-08 09:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1733259&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
Private: No
Submitted By: durumdara (durumdara)
Assigned to: Nobody/Anonymous (nobody)
Summary: ZipFile CallBack Needed...

Initial Comment:
Hi!

I wrote about this here:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/f08c37f30b654746/a0fe8ab504b3b702
And here:
http://groups.google.com.kh/group/comp.lang.python/browse_thread/thread/c6069d12273025bf/18b9b1c286d9af7b?lnk=st&q=python+zip+callback&rnum=1#18b9b1c286d9af7b

So need a little modification in ZipFile module to get more control on 
compression.
A callback procedure needed to:
- I show progress bar when I compress a file
- I can abort the whole compression procedure
When I compress little files, no problem.

But when compress large files, I lost the control, and I don't know (I can't 
show) the compression progress, and the remaining bytes.

I can change this in my app only, but if I installed a new Python I lost it 
everytime... :-(

Thanks for your help:
dd

--

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