[ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run
Bugs item #1581906, was opened at 2006-10-21 13:02
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Skip Montanaro (montanaro)
Assigned to: Thomas Heller (theller)
Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run
Initial Comment:
I noticed a test_sqlite test failure on my Mac G5 the other day while trying
to set up a buildbot for sqlalchemy. Everything runs fine on my G4
powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0,
build 5026.
I whittled the problem down to just having test_ctypes and test_sqlite
enabled, then further whittled it down to just having Lib/ctypes/test/
test_find.py available (all other ctypes tests eliminated). More detailed
problem descriptions are in these two postings to python-dev:
http://article.gmane.org/gmane.comp.python.devel/84478
http://article.gmane.org/gmane.comp.python.devel/84481
Skip
--
>Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 05:42
Message:
Logged In: YES
user_id=44345
Originator: YES
I'll be damned... Based on your last response I ran Python
under ktrace then looked at the kdump output. As it's
marching along it sees a mention of /usr/lib/libsqlite3.so
in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
then just a few lines later I see
20023 python NAMI "/usr/lib/libsqlite3.0.dylib"
20023 python RET open 3
20023 python CALL fstat(0x3,0xbfffc770)
20023 python RET fstat 0
20023 python CALL pread(0x3,0xbfffcbd0,0x1000,0)
then a bit later I see what I had wanted to see:
20023 python NAMI
"/Users/skip/local/lib/python2.6/lib-dynload/_sqlite3.so"
20023 python RET open 6
20023 python CALL fstat(0x6,0xbfff9c00)
20023 python RET fstat 0
20023 python CALL pread(0x6,0xbfffa060,0x1000,0)
...
20023 python NAMI "/Users/skip/local/lib/libsqlite3.0.dylib"
20023 python RET open 6
20023 python CALL fstat(0x6,0xbfff99b0)
20023 python RET fstat 0
20023 python CALL pread(0x6,0xbfff9e10,0x1000,0)
I can't execute the CDLL call if I've renamed
/usr/lib/libsqlite.3.0.dylib. (I suppose that stands to
reason.)
Now the question becomes whether or not the Apple-provided
library can be replaced with something more modern.
Presumably every application that uses CoreData (most
Apple things) gets it if during startup.
Thomas, for the purposes of the Python regression test
suite do you think you can find something other than
GLUT to dynamically load?
Mark, thanks for the sleuthing.
Skip
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-06-29 22:56
Message:
Logged In: YES
user_id=703403
Originator: NO
It looks as though GLUT is a red herring. I can reproduce the problem
with a variety of frameworks in place of GLUT, for example Quartz, Cocoa,
AppKit, CoreData, as in the following lines.
import ctypes
ctypes.CDLL('/System/Library/Frameworks/CoreData.framework/CoreData')
import sqlite3
sqlite3.connect(":memory:")
Furthermore, I notice that the GLUT framework has a library dependency on
the AppKit framework, AppKit on CoreData, and CoreData depends on the
Apple-supplied libsqlite3, and that Quartz and Cocoa similarly ultimately
depend on libsqlite3. Coincidence?
I can reproduce the problem with a variety of frameworks in place of GLUT,
for example Quartz, Cocoa, AppKit, CoreData. (The .glutWireTetrahedron is
unnecessary.)
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-06-29 22:32
Message:
Logged In: YES
user_id=703403
Originator: NO
I think your minor(?) data point is a major data point. I'm using the
Macports version of sqlite3. Furthermore, after hiding the /usr/lib
version with
fibonacci:/usr/lib dickinsm$ sudo mv libsqlite3.0.dylib
libsqlite3.0.dylib.temp
I can't reproduce the problem any more. I tried sprinkling a few printf
statements through the sqlite3 source to see what was going on. Bizarrely,
it looks as though the Apple-supplied sqlite3SafetyCheck() routine is being
called from the Macports createCollation(); or at least that's the only way
that I can understand the results I'm getting. Is this possible?
Mark
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-29 21:45
Message:
Logged In: YES
user_id=44345
Originator: YES
One other minor(?) data point. I am using a version of sqlite3 which I
compiled and instal
[ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run
Bugs item #1581906, was opened at 2006-10-21 13:02
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Skip Montanaro (montanaro)
Assigned to: Thomas Heller (theller)
Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run
Initial Comment:
I noticed a test_sqlite test failure on my Mac G5 the other day while trying
to set up a buildbot for sqlalchemy. Everything runs fine on my G4
powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0,
build 5026.
I whittled the problem down to just having test_ctypes and test_sqlite
enabled, then further whittled it down to just having Lib/ctypes/test/
test_find.py available (all other ctypes tests eliminated). More detailed
problem descriptions are in these two postings to python-dev:
http://article.gmane.org/gmane.comp.python.devel/84478
http://article.gmane.org/gmane.comp.python.devel/84481
Skip
--
>Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 06:15
Message:
Logged In: YES
user_id=44345
Originator: YES
I submitted a bug report to Apple about the problem, though I don't
really expect a response. (The other bug I filed in 2004 has never
received any response as far as I can tell.) Maybe a more recent
version of SQLite will be delivered with Leopard...
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 05:42
Message:
Logged In: YES
user_id=44345
Originator: YES
I'll be damned... Based on your last response I ran Python
under ktrace then looked at the kdump output. As it's
marching along it sees a mention of /usr/lib/libsqlite3.so
in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
then just a few lines later I see
20023 python NAMI "/usr/lib/libsqlite3.0.dylib"
20023 python RET open 3
20023 python CALL fstat(0x3,0xbfffc770)
20023 python RET fstat 0
20023 python CALL pread(0x3,0xbfffcbd0,0x1000,0)
then a bit later I see what I had wanted to see:
20023 python NAMI
"/Users/skip/local/lib/python2.6/lib-dynload/_sqlite3.so"
20023 python RET open 6
20023 python CALL fstat(0x6,0xbfff9c00)
20023 python RET fstat 0
20023 python CALL pread(0x6,0xbfffa060,0x1000,0)
...
20023 python NAMI "/Users/skip/local/lib/libsqlite3.0.dylib"
20023 python RET open 6
20023 python CALL fstat(0x6,0xbfff99b0)
20023 python RET fstat 0
20023 python CALL pread(0x6,0xbfff9e10,0x1000,0)
I can't execute the CDLL call if I've renamed
/usr/lib/libsqlite.3.0.dylib. (I suppose that stands to
reason.)
Now the question becomes whether or not the Apple-provided
library can be replaced with something more modern.
Presumably every application that uses CoreData (most
Apple things) gets it if during startup.
Thomas, for the purposes of the Python regression test
suite do you think you can find something other than
GLUT to dynamically load?
Mark, thanks for the sleuthing.
Skip
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-06-29 22:56
Message:
Logged In: YES
user_id=703403
Originator: NO
It looks as though GLUT is a red herring. I can reproduce the problem
with a variety of frameworks in place of GLUT, for example Quartz, Cocoa,
AppKit, CoreData, as in the following lines.
import ctypes
ctypes.CDLL('/System/Library/Frameworks/CoreData.framework/CoreData')
import sqlite3
sqlite3.connect(":memory:")
Furthermore, I notice that the GLUT framework has a library dependency on
the AppKit framework, AppKit on CoreData, and CoreData depends on the
Apple-supplied libsqlite3, and that Quartz and Cocoa similarly ultimately
depend on libsqlite3. Coincidence?
I can reproduce the problem with a variety of frameworks in place of GLUT,
for example Quartz, Cocoa, AppKit, CoreData. (The .glutWireTetrahedron is
unnecessary.)
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-06-29 22:32
Message:
Logged In: YES
user_id=703403
Originator: NO
I think your minor(?) data point is a major data point. I'm using the
Macports version of sqlite3. Furthermore, after hiding the /usr/lib
version with
fibonacci:/usr/lib dickinsm$ sudo mv libsqlite3.0.dylib
libsqlite3.0.dylib.temp
I can't reproduce the problem any more. I tried sprinkling a few printf
statements through the sqlite3 source to see what was going on. Bizarrely,
it looks as though the Apple-supplied sqlite3SafetyCheck() r
[ python-Bugs-1745533 ] Filename providing cross platform capability
Bugs item #1745533, was opened at 2007-06-30 02:35 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Damian (atagar) Assigned to: Nobody/Anonymous (nobody) Summary: Filename providing cross platform capability Initial Comment: The help section for the open method should note that a Unix style filename work in a cross platform fashion (like Java). After scouring several resources including two O'Reilly texts on Python, a dozen web pages, all reliant help pages, I finally got my answer from a mailing list. -Damian -- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-06-30 17:54 Message: Logged In: YES user_id=942711 Originator: NO I am not getting as what you are indicating Damian. You mean to say use '/' forward slashes in all documentation as they can work cross platform? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run
Bugs item #1581906, was opened at 2006-10-21 13:02
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Skip Montanaro (montanaro)
Assigned to: Thomas Heller (theller)
Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run
Initial Comment:
I noticed a test_sqlite test failure on my Mac G5 the other day while trying
to set up a buildbot for sqlalchemy. Everything runs fine on my G4
powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0,
build 5026.
I whittled the problem down to just having test_ctypes and test_sqlite
enabled, then further whittled it down to just having Lib/ctypes/test/
test_find.py available (all other ctypes tests eliminated). More detailed
problem descriptions are in these two postings to python-dev:
http://article.gmane.org/gmane.comp.python.devel/84478
http://article.gmane.org/gmane.comp.python.devel/84481
Skip
--
>Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 08:17
Message:
Logged In: YES
user_id=44345
Originator: YES
Thomas,
Here's a possible modification to ctypes.test.test_find which appears
to be the only place that OpenGL (and thus CoreData on the Mac?) is
accessed. On Darwin I replace the GL find stuff with Tcl find stuff.
It's a bit ugly, but it might solve the problem.
Skip
File Added: test_find.diff
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 06:15
Message:
Logged In: YES
user_id=44345
Originator: YES
I submitted a bug report to Apple about the problem, though I don't
really expect a response. (The other bug I filed in 2004 has never
received any response as far as I can tell.) Maybe a more recent
version of SQLite will be delivered with Leopard...
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 05:42
Message:
Logged In: YES
user_id=44345
Originator: YES
I'll be damned... Based on your last response I ran Python
under ktrace then looked at the kdump output. As it's
marching along it sees a mention of /usr/lib/libsqlite3.so
in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
then just a few lines later I see
20023 python NAMI "/usr/lib/libsqlite3.0.dylib"
20023 python RET open 3
20023 python CALL fstat(0x3,0xbfffc770)
20023 python RET fstat 0
20023 python CALL pread(0x3,0xbfffcbd0,0x1000,0)
then a bit later I see what I had wanted to see:
20023 python NAMI
"/Users/skip/local/lib/python2.6/lib-dynload/_sqlite3.so"
20023 python RET open 6
20023 python CALL fstat(0x6,0xbfff9c00)
20023 python RET fstat 0
20023 python CALL pread(0x6,0xbfffa060,0x1000,0)
...
20023 python NAMI "/Users/skip/local/lib/libsqlite3.0.dylib"
20023 python RET open 6
20023 python CALL fstat(0x6,0xbfff99b0)
20023 python RET fstat 0
20023 python CALL pread(0x6,0xbfff9e10,0x1000,0)
I can't execute the CDLL call if I've renamed
/usr/lib/libsqlite.3.0.dylib. (I suppose that stands to
reason.)
Now the question becomes whether or not the Apple-provided
library can be replaced with something more modern.
Presumably every application that uses CoreData (most
Apple things) gets it if during startup.
Thomas, for the purposes of the Python regression test
suite do you think you can find something other than
GLUT to dynamically load?
Mark, thanks for the sleuthing.
Skip
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-06-29 22:56
Message:
Logged In: YES
user_id=703403
Originator: NO
It looks as though GLUT is a red herring. I can reproduce the problem
with a variety of frameworks in place of GLUT, for example Quartz, Cocoa,
AppKit, CoreData, as in the following lines.
import ctypes
ctypes.CDLL('/System/Library/Frameworks/CoreData.framework/CoreData')
import sqlite3
sqlite3.connect(":memory:")
Furthermore, I notice that the GLUT framework has a library dependency on
the AppKit framework, AppKit on CoreData, and CoreData depends on the
Apple-supplied libsqlite3, and that Quartz and Cocoa similarly ultimately
depend on libsqlite3. Coincidence?
I can reproduce the problem with a variety of frameworks in place of GLUT,
for example Quartz, Cocoa, AppKit, CoreData. (The .glutWireTetrahedron is
unnecessary.)
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-06-29 22:32
Message:
[ python-Feature Requests-1745722 ] please add wsgi to SimpleXMLRPCServer
Feature Requests item #1745722, was opened at 2007-06-30 13:31
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=1745722&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: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Helmut Grohne (gnarfk)
Assigned to: Nobody/Anonymous (nobody)
Summary: please add wsgi to SimpleXMLRPCServer
Initial Comment:
There should be a simple wsgi xmlrpc application and in fact it is not
difficult. You could for instance take this one and append it to
SimpleXMLRPCServer.py.
class WSGIXMLRPCRequestHandler(SimpleXMLRPCDispatcher):
def __init__(self, allow_none=False, encoding=None):
SimpleXMLRPCDispatcher.__init__(self, allow_none, encoding)
def __call__(self, environ, start_response):
"""WSGI interface"""
if environ["REQUEST_METHOD"] != "POST":
status = "400 Bad request"
headers = [("Content-type", "text/html")]
data = "400 Bad
request400 Bad request"
headers.append(("Content-length", str(len(data
start_response(status, headers)
if environ["REQUEST_METHOD"] == "HEAD":
return []
return [data]
l = int(environ["CONTENT_LENGTH"])
request = environ["wsgi.input"].read(l)
response = self._marshaled_dispatch(request)
headers = [("Content-type", "text/xml")]
headers.append(("Content-length", str(len(response
start_response("200 OK", headers)
return [response]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1745722&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-1745722 ] please add wsgi to SimpleXMLRPCServer
Feature Requests item #1745722, was opened at 2007-06-30 13:31
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1745722&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: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Helmut Grohne (gnarfk)
>Assigned to: Fredrik Lundh (effbot)
Summary: please add wsgi to SimpleXMLRPCServer
Initial Comment:
There should be a simple wsgi xmlrpc application and in fact it is not
difficult. You could for instance take this one and append it to
SimpleXMLRPCServer.py.
class WSGIXMLRPCRequestHandler(SimpleXMLRPCDispatcher):
def __init__(self, allow_none=False, encoding=None):
SimpleXMLRPCDispatcher.__init__(self, allow_none, encoding)
def __call__(self, environ, start_response):
"""WSGI interface"""
if environ["REQUEST_METHOD"] != "POST":
status = "400 Bad request"
headers = [("Content-type", "text/html")]
data = "400 Bad
request400 Bad request"
headers.append(("Content-length", str(len(data
start_response(status, headers)
if environ["REQUEST_METHOD"] == "HEAD":
return []
return [data]
l = int(environ["CONTENT_LENGTH"])
request = environ["wsgi.input"].read(l)
response = self._marshaled_dispatch(request)
headers = [("Content-type", "text/xml")]
headers.append(("Content-length", str(len(response
start_response("200 OK", headers)
return [response]
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-06-30 14:59
Message:
Logged In: YES
user_id=849994
Originator: NO
Assigned to Fredrik.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1745722&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1745761 ] Bad attributes/data handling in SGMLib
Bugs item #1745761, was opened at 2007-06-30 16:38 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=1745761&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alvaro Lopez (wolfete) Assigned to: Nobody/Anonymous (nobody) Summary: Bad attributes/data handling in SGMLib Initial Comment: When feeding an parser with a tag in which its arguments contain a < (as in example the SGMLParsers doesn't handle the data/arguments correcly. For example, with the above string I get: Fed: example Tag opened: a Arg href -> http://www.example.org/";>; Arg escaped 'http://www.example.org/">;;' Data: ;'>example Tag closed: a I have attached a small example. I'm using python2.5.1 Cheers, Álvaro. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745761&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1745035 ] DoS smtpd vulnerability
Bugs item #1745035, was opened at 2007-06-28 21:44
Message generated for change (Settings changed) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&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: 7
Private: No
Submitted By: billiejoex (billiejoex)
Assigned to: Nobody/Anonymous (nobody)
Summary: DoS smtpd vulnerability
Initial Comment:
Method "collect_incoming_data" of "SMTPChannel" class should stop buffering if
received lines are too long (possible Denial-of-Service attacks).
Without truncating such buffer a simple malicious script sending extremely long
lines without "\r\n" terminator could easily saturate system resources.
--
Comment By: billiejoex (billiejoex)
Date: 2007-06-29 20:00
Message:
Logged In: YES
user_id=1357589
Originator: YES
Sorry, I realized I've forgotten to reset to zero the bytes counter.
Here's the patch of the patch:
124a125
> self.__in_buffer_len = 0
135a137,140
> self.__in_buffer_len += len(data)
> if self.__in_buffer_len > 4096:
> self.__line = []
> self.__in_buffer_len = 0
141a147
> self.__in_buffer_len = 0
--
Comment By: billiejoex (billiejoex)
Date: 2007-06-28 21:45
Message:
Logged In: YES
user_id=1357589
Originator: YES
--- malicious script
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("127.0.0.1", 8025))
while 1:
s.sendall('x' * 1024)
--- proposed smtpd.py patch
124a125
> self.__in_buffer_len = 0
135a137,139
> self.__in_buffer_len += len(data)
> if self.__in_buffer_len > 4096:
> self.__line = []
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1743795 ] Some incorrect national characters (Polish) in unicodedata
Bugs item #1743795, was opened at 2007-06-26 20:45
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743795&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: Unicode
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: admindomeny (admindomeny)
Assigned to: Mark Hammond (mhammond)
Summary: Some incorrect national characters (Polish) in unicodedata
Initial Comment:
Hello,
This problem regards pythonwin (I haven't checked whether unix/commandline
python is affected), Python 2.5.1.
Examples on attached screenshot.
E.g. print u'\N{LATIN SMALL LETTER A WITH CIRCUMFLEX}' prints wrong character
(latin small a with some caret above it it seems) as well as
print unicodedata.name( / latin small letter a with circumflex, typed in
Windows using Polish "programmer's keyboard" / ) produces 'SUPERSCRIPT ONE',
which is obviously incorrect.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-30 19:34
Message:
Logged In: YES
user_id=21627
Originator: NO
Actually, we should close this here. Please report it through the
PythonWin bugtracker.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2007-06-27 21:38
Message:
Logged In: YES
user_id=38388
Originator: NO
Assigning to Mark Hammond who wrote Pythonwin.
--
Comment By: admindomeny (admindomeny)
Date: 2007-06-27 19:25
Message:
Logged In: YES
user_id=1829093
Originator: YES
You were correct, the attached test file for Polish national characters
shows correctt character encodings when ran in Pythonwin and edited
correctly Unicode with Polish characters from Unicode Unicode.
The problem of entering characters in Pythonwin remains, however (OS: Win
XP SP2, Polish edition): I have tried changing fonts to what are Unicode
fonts as far as I know (Times New Roman, Arial, etc), including CE fonts as
well. It doesn't work.
I made sure that Polish Programmer's Keyboard is turned on which gives me
correct encoding in almost all Windows applications, including Unicode
editors like UniRed. Still, Pythonwin shell in particular thinks that
AltGr+a (standard way of entering 'LATIN SMALL LETTER A WITH OGONEK') is
actually 'SUPERSCRIPT ONE' for example.
So, to summarize:
1. IDLE edits the text in Unicode correctly provided there's a #-*-
coding: utf-8 -*- header in first line.
2. Pythonwin executes that file correctly.
3. Pythonwin enters national characters INCORRECTLY (at least as far
Polish is concerned, but I suspect it's also the case with other
languages).
File Added: test.py
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2007-06-27 10:28
Message:
Logged In: YES
user_id=38388
Originator: NO
This sounds more like a problem with entry of Unicode characters in
pythonwin than the unicodedata module.
Please create a test.py file with the character using e.g. UTF-8 as source
code encoding and run that through the Python interpreter directly to see
if the problem persists.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743795&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1745533 ] Filename providing cross platform capability
Bugs item #1745533, was opened at 2007-06-29 14:05
Message generated for change (Comment added) made by atagar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Damian (atagar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Filename providing cross platform capability
Initial Comment:
The help section for the open method should note that a Unix style filename
work in a cross platform fashion (like Java). After scouring several resources
including two O'Reilly texts on Python, a dozen web pages, all reliant help
pages, I finally got my answer from a mailing list. -Damian
--
>Comment By: Damian (atagar)
Date: 2007-06-30 14:38
Message:
Logged In: YES
user_id=1613266
Originator: YES
No, I'm talking about the documentation when entering help(file) or
help(open). The filename parameter works in a cross platform fashion when
given a Unix path. For instance,
file = open("/path/to/content.xml", "r") # Cross platform
file = open("\\path\\to\\content.xml", "r") # Win32 only
This seemed to be an undocumented yet important detail (unless I'm
mistaken it means its advantageous to always use the former method when
coding paths). However, looking around some more I think this is largely a
misunderstanding on my part in terms of where the cross platform capability
came from (Windows accepting a forward slash rather than the open method
translating the path for the current OS). Sorry about the confusion.
--
Comment By: O.R.Senthil Kumaran (orsenthil)
Date: 2007-06-30 05:24
Message:
Logged In: YES
user_id=942711
Originator: NO
I am not getting as what you are indicating Damian. You mean to say use
'/' forward slashes in all documentation as they can work cross platform?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1745533 ] Filename providing cross platform capability
Bugs item #1745533, was opened at 2007-06-29 14:05
Message generated for change (Comment added) made by atagar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Damian (atagar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Filename providing cross platform capability
Initial Comment:
The help section for the open method should note that a Unix style filename
work in a cross platform fashion (like Java). After scouring several resources
including two O'Reilly texts on Python, a dozen web pages, all reliant help
pages, I finally got my answer from a mailing list. -Damian
--
>Comment By: Damian (atagar)
Date: 2007-06-30 14:48
Message:
Logged In: YES
user_id=1613266
Originator: YES
No, I'm talking about the documentation when entering help(file) or
help(open). The filename parameter works in a cross platform fashion when
given a Unix path. For instance,
file = open("/path/to/content.xml", "r") # Cross platform
file = open("\\path\\to\\content.xml", "r") # Win32 only
This seemed to be an undocumented yet important detail (unless I'm
mistaken it means its advantageous to always use the former method when
coding paths). However, looking around some more I think this is largely a
misunderstanding on my part in terms of where the cross platform capability
came from (Windows accepting a forward slash rather than the open method
translating the path for the current OS). Sorry about the confusion.
--
Comment By: Damian (atagar)
Date: 2007-06-30 14:38
Message:
Logged In: YES
user_id=1613266
Originator: YES
No, I'm talking about the documentation when entering help(file) or
help(open). The filename parameter works in a cross platform fashion when
given a Unix path. For instance,
file = open("/path/to/content.xml", "r") # Cross platform
file = open("\\path\\to\\content.xml", "r") # Win32 only
This seemed to be an undocumented yet important detail (unless I'm
mistaken it means its advantageous to always use the former method when
coding paths). However, looking around some more I think this is largely a
misunderstanding on my part in terms of where the cross platform capability
came from (Windows accepting a forward slash rather than the open method
translating the path for the current OS). Sorry about the confusion.
--
Comment By: O.R.Senthil Kumaran (orsenthil)
Date: 2007-06-30 05:24
Message:
Logged In: YES
user_id=942711
Originator: NO
I am not getting as what you are indicating Damian. You mean to say use
'/' forward slashes in all documentation as they can work cross platform?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
