[ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility
Bugs item #1086854, was opened at 2004-12-17 05:07 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&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 Submitted By: Jeremy Friesner (jfriesne) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME
Bugs item #959576, was opened at 2004-05-24 19:16
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't build Python on POSIX w/o $HOME
Initial Comment:
If you're building Python on os.name == 'posix' but
when there is no $HOME defined in your environment, you
cannot build Python. This is because in the bowels of
distutils, you end up in check_environ(), which has
these lines:
if os.name == 'posix' and not
os.environ.has_key('HOME'):
import pwd
os.environ['HOME'] = pwd.getpwuid(os.getuid())[5]
However, in a from-scratch build, the pwd module isn't
built by the time you get here. I found this when
using SCons to build Python, since by default the
enclosing environment isn't passed to subprocesses.
I can work around this in my builds but Python's
setup.py should probably synthesize a $HOME if one
doesn't exist. (Or maybe someone has a better idea for
a workaround).
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-22 09:19
Message:
Logged In: YES
user_id=1188172
Seems that the pwdmodule entry in Modules/Setup.dist must be
uncommented.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-939699 ] Building python 2.3.3 RPM on Mandrake 9.2. fails
Bugs item #939699, was opened at 2004-04-22 01:35
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=939699&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.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: fabien wahl (fwahl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building python 2.3.3 RPM on Mandrake 9.2. fails
Initial Comment:
The command (run as root)
$ rpm --rebuild python2.3-2.3.3-2pydotorg.src.rpm
yields the following (Two files not found)
RPM build errors:
user jafo does not exist - using root
group jafo does not exist - using root
user jafo does not exist - using root
group jafo does not exist - using root
user jafo does not exist - using root
group jafo does not exist - using root
File not found:
/var/tmp/python2.3-2.3.3-root/usr/man/man1/python2.3.1.gz
File not found:
/var/tmp/python2.3-2.3.3-root/usr/lib/python2.3/Tools/freeze/.cvsignore
Does that mean that your src.rpm file is not complete?
In the ../man/man1 directory, i have the file
python2.3.1.bz2. This does not match line 227 and 310
of the .spec file ???
changing gz in bz2 solves this problem (at least it seems)
In the .spec file, in the Tools section starting, line
233, the variable %{_prefix} is used, but it seems it
should be %{__prefix} ??
Correcting __prefix yields another error
what is the variable %{_bindir} pointing on? seems to
be /usr/bin, but no instanciation found in the spec file.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-22 09:21
Message:
Logged In: YES
user_id=1188172
Both the 2.3.5 and 2.4.1 source RPMs build fine here.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=939699&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1276509 ] 2.4.1 make fails on Solaris 10
Bugs item #1276509, was opened at 2005-08-30 12:48 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: csmuc (chrschaffer) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 make fails on Solaris 10 Initial Comment: Hi all, my efforts building Python 2.4.1 on Solaris 10(x386) failed. The error mesage reads: (...)Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus *** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' I found bug 970334 dealing with that topic, but I didn't find a solution provided. I tried with various compilers and libraries, e.g. /opt/sfw/bin/gcc --version gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. /opt/csw/gcc3/bin/gcc --version gcc (GCC) 3.4.4 Copyright (C) 2004 Free Software Foundation, Inc. /usr/local/bin/gcc --version gcc (GCC) 3.3.2 The same result with any of them. I didn't get the solution provided in http://mail.python.org/pipermail/python-list/2005-August/293795.html to work for me, unfortunately. I'd be glad, if you could have a look into this issue. Thanks in advance, Chris -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 09:03 Message: Logged In: YES user_id=1188172 Looks like HUGE_VAL is defined in a curious way on your platform. Can you find out what header defines HUGE_VAL and to what it expands? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&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-1297986 ] hashable and mutable functions
Feature Requests item #1297986, was opened at 2005-09-21 18:55 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: hashable and mutable functions Initial Comment: It is not easy to check if an object is hashable, ie hasattr(list(), '__hash__') -> True try: hash(list()) except TypeError: pass seems to be a possible way to see if an object is hashable, however it is not satisfiable that this information needs to be retrieved by using exception handling. My proposal: There should be a hashable(obj) function returning a bool object and additionally it would be nice to have something like ismutable(obj) function, possibly as built-in functions. Reason: callable() is a built-in function and returns information about an object whether it's callable or not, that is a basic info about this object. If an object is hashable or mutable is a state of an object that is also very important to know. -- >Comment By: Michael Hudson (mwh) Date: 2005-09-22 09:16 Message: Logged In: YES user_id=6656 def ishashable(ob): try: hash(ob) return True except TypeError: return False is the only reasonable way to implement this function (incidentally, do you know how hasattr works?). I don't see the need for a builtin, but am not feeling bolshy enough to just close the tracker item. Maybe someone else does. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 07:27 Message: Logged In: YES user_id=1188172 > try: hash(list()) > except TypeError: pass > > seems to be a possible way to see if an object is > hashable, however it is not satisfiable that this > information needs to be retrieved by using exception > handling. Why? > My proposal: > There should be a hashable(obj) function returning a > bool object and additionally it would be nice to have > something like ismutable(obj) function, possibly as > built-in functions. How should "ismutable" be implemented? > Reason: > callable() is a built-in function and returns > information about an object whether it's callable or > not, that is a basic info about this object. > If an object is hashable or mutable is a state of an > object that is also very important to know. It's easier to ask for forgiveness than permission. Even callable() has been called a mistake. Just call it and see where you come. So, -1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-999767 ] Setup.local ignored by setup.py
Bugs item #999767, was opened at 2004-07-29 00:06 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stephan A. Terre (sfiedler) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Setup.local ignored by setup.py Initial Comment: This applies to Python 2.2.x, 2.3.x, and 2.4a1. Platforms seem to be all Unix flavors. I have zlib, readline, and Tk in an unusual location. There are also often older versions in the usual locations (/usr/local/lib, etc.). I put -L and -I flags pointing to the desired location of these libraries in entries for the appropriate extension modules in Setup.local, per the README. I specify all three extension modules as *shared* . When I build, the extension modules I specify in Setup.local get built twice: once directly from the Makefile, with the flags I request in Setup.local, then again from setup.py's build_ext phase, with the default flags. The second build is what's installed, so I end up using the wrong version of libz, libreadline, and libtk . The problem appears to be around line 152 of setup.py (CVS revision 1.190). There is code to ignore modules defined in Modules/Setup, but not modules defined in Modules/Setup.local . I'm not familiar with the text_file.TextFile class, so there may be a better way to do this, but one the fix is to loop over ['Modules/Setup', 'Modules/Setup.local'] rather than only reading Modules/Setup. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-836035 ] strftime month name is encoded somehow
Bugs item #836035, was opened at 2003-11-04 21:49
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&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: Python 2.4
Status: Open
>Resolution: None
Priority: 5
Submitted By: Tim Evans (tim_evans)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime month name is encoded somehow
Initial Comment:
On Windows XP, with some locales the month name
returned by time.strftime('%B') is encoded somehow.
For example:
>>> import time, locale
>>> locale.setlocale(locale.LC_ALL, '')
"Chinese_People's Republic of China.936"
>>> time.strftime('%B')
'\xca\xae\xd2\xbb\xd4\xc2'
>>> time.strftime('%d %B %Y')
'05 \xca\xae\xd2\xbb\xd4\xc2 2003'
>>> locale.setlocale(locale.LC_ALL, '')
'French_France.1252'
>>> time.strftime('%B', (2003,12,1,0,0,0,0,0,0))
'd\xe9cembre'
I'm not sure what encoding the Chinese version is
using, but the French is compatible with latin-1. It
would appear that the encoding used is locale-dependent.
Ideally, the win32 version of time.strftime would call
the wide-character version of strftime (called
wcsftime) and return a unicode object.
I haven't looked at what this does under any other
operating system.
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-11-07 19:56
Message:
Logged In: YES
user_id=21627
This tells me that we need a function to return the current
locale's code page; this should return "cp936" in your case.
The fact that Python does not have a codec for cp936 is an
independent issue.
--
Comment By: Tim Evans (tim_evans)
Date: 2003-11-06 23:21
Message:
Logged In: YES
user_id=561705
I have looked at the source code for the MS C library (it
comes with VC++6) and I believe that that something
equivalent to the following is used:
char codepage[16];
GetLocaleInfo(
GetThreadLocale(),
LOCALE_IDEFAULTANSICODEPAGE,
codepage, 16);
This returns "1252" for "C" locale, and for the chinese
locale that I was expirmenting with it returns "936".
Python does not have an encoding "cp936", but from C the
conversion with an explicit codepage produces the same
results as mbstwcs.
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-11-06 22:33
Message:
Logged In: YES
user_id=21627
Is there any way to find out the encoding that mbstowcs uses?
--
Comment By: Tim Evans (tim_evans)
Date: 2003-11-06 22:00
Message:
Logged In: YES
user_id=561705
The windows C lib docs say that calling mbstowcs on the
output of strftime (or calling wcsftime instead of strftime)
will return the correct wide-character (utf-16?) string.
This produces something that looks like it could be correct.
Decoding with the 'mbcs' encoding in Python is not
equivalent to calling mbstowcs because mbstowcs is
locale-dependent.
Perhaps it would be a good idea to have time.strftime return
a unicode string. As this wouldn't be backward compatible,
it could be done via a new function time.ustrftime, or via
an optional unicode=True argument to the existing function.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2003-11-06 09:53
Message:
Logged In: YES
user_id=38388
Tim, there's nothing much we can do about this since the
strftime()
API is a direct interface to the underlying C lib API. Python
simply passes through the arguments to this function and
returns whatever teh C lib has to offer.
Please refer to the C lib documentation for your platform
for details about the encoding being used for the strings.
BTW, a simpe table with the month names in your application
should nicely solve your problem; addtitionally it gives you
full control ove the encoding and wording being used.
--
Comment By: Tim Evans (tim_evans)
Date: 2003-11-05 23:45
Message:
Logged In: YES
user_id=561705
I'm reopening the bug, because that doesn't seem to work:
>>> import time, locale
>>> locale.setlocale(locale.LC_ALL, '')
"Chinese_People's Republic of China.936"
>>> x = time.strftime('%B')
>>> x
'\xca\xae\xd2\xbb\xd4\xc2'
>>> x.decode('mbcs')
'\xca\xae\xd2\xbb\xd4\xc2'
>>> locale.getpreferredencoding()
'cp1252'
>>> x.decode('cp1252')
'\xca\xae\xd2\xbb\xd4\xc2'
The preferred encoding is returned as cp1252, which can't be
correct. And niether cp1252 nor mbcs appear to decode the
string into anything containing the high-numbered characters
I would expect for chinese (neither of them changes the
string at all).
The follo
[ python-Bugs-901727 ] extra_path kwarg to setup() undocumented
Bugs item #901727, was opened at 2004-02-21 16:04
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901727&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: Distutils
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Thomas Heller (theller)
Summary: extra_path kwarg to setup() undocumented
Initial Comment:
I can't find documentation for extra_path anywhere.. but this is the
documentation I found by searching google ( http://
mail.python.org/pipermail/distutils-sig/2000-March/000803.html ),
from an old USAGE.txt that sits in the CVS attic now:
extra_path:
information about extra intervening directories to put between
'install_lib' and 'install_sitelib', along with a .pth file to
ensure that those directories wind up in sys.path. Can be a 1-
or
2-tuple, or a comma-delimited string with 1 or 2 parts. The
1-element case is simpler: the .pth file and directory have the
same
name (except for ".pth"). Eg. if extra_path is "foo" or ("foo",),
then Distutils sets 'install_site_lib' to 'install_lib' +
"site-packages/foo", and puts foo.path in the "site-packages"
directory; it contains just "foo". The 2-element case allows the
.pth file and intervening directories to be named differently;
eg.
if 'extra_path' is ("foo","foo/bar/baz") (or "foo,foo/bar/baz"),
then Distutils will set 'install_site_lib' to 'install_lib' +
"site-packages/foo/bar/baz", and put "foo.pth" containing
"foo/bar/baz" in the "site-packages" directory.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2005-05-17 18:16
Message:
Logged In: YES
user_id=580910
extra_path also doesn't have a command-line equivalent.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901727&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-984219 ] hotspot.stats.load is very slow
Bugs item #984219, was opened at 2004-07-02 19:53 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984219&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: hotspot.stats.load is very slow Initial Comment: hotspot.Profile generates a very large (10-70Mbytes) file for complex applications. hotspot.stats.load loads the profile file very slow. -- Comment By: Viktor Ferenczi (complex) Date: 2004-07-02 20:10 Message: Logged In: YES user_id=142612 OS: WinXP Prof ENG SP1 CPU: Intel P4 Northwood 1.6G MEM: 512Mbyte, 800MHz RDRAM -- Comment By: Viktor Ferenczi (complex) Date: 2004-07-02 20:09 Message: Logged In: YES user_id=142612 Python version: 2.3.4 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984219&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-1296581 ] datetime.replace could take a dict
Feature Requests item #1296581, was opened at 2005-09-20 18:56 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1296581&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: 1 Submitted By: Tom Lynn (tlynn) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: datetime.replace could take a dict Initial Comment: Python 2.4.1. datetime.replace uses its kwargs to specify the fields, which I found a bit surprising. It could also take an equivalent dict. (Failing that, it could have a fuller docstring.) What I was actually trying to do was round to the nearest half hour. floor and ceil methods taking a timedelta would be nice too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1296581&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-880951 ] "ez" format code for ParseTuple()
Feature Requests item #880951, was opened at 2004-01-21 00:03 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=880951&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: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Willeke (willeke) Assigned to: M.-A. Lemburg (lemburg) Summary: "ez" format code for ParseTuple() Initial Comment: I'm using Python 2.3.3 on SuSE Linux 8.2. It would be nice to have an "ez" format code that is to "es" as "z" is to "s". Whereas the "s" and "z" codes depend on the default encoding, "es" lets you specify the encoding, which is useful for interfacing with GTK+ and GNOME libraries, which have largely standardized on UTF-8. I think it is possible to simulate the desired behavior with "O&", but it would be simpler with "ez". -- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-02 18:01 Message: Logged In: YES user_id=38388 No answers... lowering the priority. -- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 18:41 Message: Logged In: YES user_id=38388 Can you elaborate on the use case ? I'm asking because I don't find the 'z' code particulary useful myself because there are more elegant ways to deal with optional arguments. -- Comment By: Jon Willeke (willeke) Date: 2004-01-22 00:29 Message: Logged In: YES user_id=185468 I'm attaching a patch that adds support for the "ez" and "ez#" format codes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=880951&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-467924 ] Improve the ZipFile Interface
Feature Requests item #467924, was opened at 2001-10-04 17:54
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve the ZipFile Interface
Initial Comment:
There exist two methods to write to a ZipFile
write(self, filename, arcname=None, compress_type=None)
writestr(self, zinfo, bytes)
but only one to read from it
read(self, name)
Additionally, the two 'write's behave differently with respect to compression.
---
(a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a
ZipFile,
but 'read' is not the reverse operation. 'read' should be called 'readstr'
since it
much better matches to 'writestr'.
(b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a
file,
or into the ZipFile? It would be more obvious if ZipFile has 4 methods
which
pair-wise fit together:
writestr (self, zinfo, bytes)
# same as now
readstr (self, name)
# returns bytes (as string), currently called 'read'
# 'read' could still live but should be deprecated
add (self, filename, arcname=None, compress_type=None)
# currently 'write'
# 'write' could still live but should be deprecated
extract (self, name, filename, arcname=None)
# new, desired functionality
(c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that
was
passed to the constructor of 'ZipFile'. Currently, 'write' does it,
'writestr' via
zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED'
:-(
It should not do that! It rather should:
- allow more parameters in the signature of the constructor
to also pass the compression type (and some other attributes, too)
- default to 'None', so that 'writestr' can see this, and then take
the default from the 'ZipFile' instance.
--
Comment By: Myers Carpenter (myers_carpenter)
Date: 2004-05-09 20:23
Message:
Logged In: YES
user_id=335935
The zipfile interface should match the tarfile interface.
At the mininum is should work for this example:
import zipfile
zip = zipfile.open("sample.zip", "r")
for zipinfo in zip:
print tarinfo.name, "is", tarinfo.size, "bytes in size
and is",
zip.extract(zipinfo)
zip.close()
This closely matchs the 'tarfile' module.
--
Comment By: Matt Zimmerman (mzimmerman)
Date: 2003-07-31 16:22
Message:
Logged In: YES
user_id=196786
It would also be very useful to be able to have ZipFile
read/write the uncompressed file data from/to a file-like
object, instead of just strings and files (respectively).
I would like to use this module to work with zip files
containing large files, but this is unworkable because the
current implementation would use excessive amounts of memory.
Currently, read() reads all of the compressed data into
memory, then uncompresses it into memory. For files which
may be hundreds of megabytes compressed, this is undesirable.
Likewise for write(), I would like to be able to stream data
into a zip file, passing in a ZipInfo to specify the
metadata as is done with writestr().
The implementation of this functionality is quite
straightforward, but I am not sure whether (or how) the
interface should change. Some other parts of the library
allow for a file object to be passed to the same interface
which accepts a filename. The object is examined to see if
it has the necessary read/write methods and if not, it is
assumed to be a filename. Would this be the correct way to
do it?
I, too, am a bit irked by the lack of symmetry exhibited by
read vs. write/writestr, and think that the interface
suggested above would be a significant improvement.
--
Comment By: Just van Rossum (jvr)
Date: 2003-01-05 21:54
Message:
Logged In: YES
user_id=92689
In Python 2.3, writestr() has an enhanced signature: the
first arg may now also be an archive name, in which case the
correct default settings are used (ie. the compression value
is taken from the file). See patch #651621.
extract() could be moderately useful (although I don't
understand the 'arcname' arg, how's that different from
'name'?) but would have to deal with file modes (bin/text).
The file mode isn't in the archive so would have to
(optionally) be supplied by the caller.
-
[ python-Feature Requests-750423 ] event handling support
Feature Requests item #750423, was opened at 2003-06-07 04:58 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=750423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lila Chase (lchase) Assigned to: Nobody/Anonymous (nobody) Summary: event handling support Initial Comment: We are interested in a general solution to the problem of getting various Python packages that must deal with events to cooperate. Python currently provides a hook to readline (PyOS_InputHook) that packages use for event handling. However, we have found so far that the following Python packages conflict over use of readline: - Tkinter and PyGist - PyMPI and PyGist As Dave Munro explains below, the best solution to this problem is to add more general event handling capability to Python. We ask Python developers to seriously consider this important change. Thank you. Lila Chase [EMAIL PROTECTED] An explanation of the event handling problem is provided in the following note from Dave Munro: Date: Wed, 14 May 2003 12:11:16 -0700 From: "David H. Munro"Reply-To: [EMAIL PROTECTED] Gist does not really care about readline, of course. There are only two requirements: (1) Gist must receive an idle event. That is, whenever all other events have been processed (or during idle processing), gist needs to be called in order to process its own deferred tasks. This is where the apparent readline dependence appears: When it has nothing left to do, python calls readline to wait for the next input line. This is the only hook I know of in python for getting an idle event delivered. Unfortunately, it is way overloaded (for example, tkinter steals the same hook as well). The problem is that the python event loop is "inside out" -- it needs to be fixed such that readline is called only as the result of input on stdin, putting stdin on the same footing as any other input source. (2) The file descriptor for gist's X socket(s) must be included in the list of descriptors that will trigger python to "wake up" when it is blocked waiting for new input. Technically, this means that python must call either poll() or select() when it goes idle, and that gist's X socket must be among the descriptors included in the list provided for those routines. Furthermore, when input actually arrives on that socket, python must call gist's event handler. Python currently has no direct support for asynchronous input, which is why gist steals the readline hook. That approach will break anyone else who needs such a callback, since the current gist input hook only wakes up for its own X socket(s) and stdin. Gist does have a full event model, so other packages could register with gist if they wanted to get event callbacks of their own, but of course any package which did that would itself become dependent on gist. The only correct place to do this job is therefore in python itself; it currently just does not support such a notion. Part of the technical problem with such support is that things are quitedifferent under both Windows and MacOS <=9. It is quite challenging to find an abstraction which covers all those cases. For example, (2) is not necessary (for gist) at all under Windows, since the OS ensures that events on gist window s generate gist event callbacks. I hope this helps to clarify the problems gist has in coexisting with python. Neither of these problems is particularly difficult, although the politics of getting such changes into the python distribution is probably very tricky. The good news is that these are the only really serious problems; everything else is purely a pygist problem. I don't know enough about python to judge the path of least resistance to get them implemented, or to accomodate the other packages that have gone after python's existing input hooks, but I'm sure there must be a fairly unobtrusive way to go about it. Dave P.S.-There is a subtlety in the semantics of idle events, which makes it impossible for gist to rely on the Tcl/Tk model for handling them. If anyone undertakes the addition of idle event machinery to python, they should take care to avoid the same pitfall: In Tcl/Tk, you can request an idle event, and after this request you will indeed get a callback just before Tcl/Tk goes idle. However, with Tcl/Tk semantics, you only get one such callback, and you need to renew your request to get another idle callback. This makes the entire mechanism worthless for gist, as it is currently implemented, because gist does not have hooks at the (many) points it might generate idle tasks; it expects to be able to permanently register an idle event handler, and to have the caller actually
[ python-Feature Requests-1015254 ] Create cgi.FieldStorage._get_new_instance method as factory
Feature Requests item #1015254, was opened at 2004-08-24 15:41 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1015254&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andreas Ames (yxcv) Assigned to: Nobody/Anonymous (nobody) Summary: Create cgi.FieldStorage._get_new_instance method as factory Initial Comment: and use this factory method instead of calling self.__class__ or FieldStorage.FieldStorageClass in FieldStorage.read_multi directly. This would allow people deriving from FieldStorage to customize the list of parameters given to the constructor. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1015254&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-1106316 ] slightly easier way to debug from the exception handler
Feature Requests item #1106316, was opened at 2005-01-20 23:06 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1106316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leonardo Rochael Almeida (rochael) Assigned to: Nobody/Anonymous (nobody) Summary: slightly easier way to debug from the exception handler Initial Comment: When interactively developing/debugging a program it'd be nice if we could throw the user into the pdb prompt straight from the exception handler. Currently, pdb.pm() only works outside of the exception handler, after "sys.last_traceback" has already been set, which doesn't happen inside the "except:" clause. The alternative is to use: try: something... except: import sys, pdb pdb.post_mortem(sys.exc_info()[2]) I propose, as a convenience to the programmer, that the first parameter to pdb.post_mortem() be made optional, defaulting to None. In this case, it'd automatically use the value of sys.exc_info()[2] in place of it's otherwise mandatory first parameter. The example above would be reduced to: try: something... except: import pdb;pdb.post_mortem() alternatively, we could make it so that if "sys.last_traceback" is not set "pdb.pm()" would pick up sys.exc_info()[2] instead... -- Comment By: Leonardo Rochael Almeida (rochael) Date: 2005-01-21 14:20 Message: Logged In: YES user_id=200267 I don't have any particular reason to prefer post_mortem() to pm(). The knowledgeable Python maintainers surely are better equiped than I am to know if pm() looking beyond sys.last_traceback is a worse break of assumptions than post_mortem() having it's only parameter being optional or the other way around :-) -- Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 23:51 Message: Logged In: YES user_id=139309 Why put this in pdb.post_mortem() if we can just put it in pdb.pm()? pdb.pm() seems to already be for this purpose (except it currently only works from the interactive interpreter as you mention). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1106316&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1013800 ] No documentation for PyFunction_* (C-Api)
Bugs item #1013800, was opened at 2004-08-22 16:10 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013800&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Henning Günther (der_eq) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: No documentation for PyFunction_* (C-Api) Initial Comment: I'm missing documentation for the PyFunction_* api-calls. They don't appear in the documentation but in http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Objects/funcobject.c?rev=2.66&view=log -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013800&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-1297986 ] hashable and mutable functions
Feature Requests item #1297986, was opened at 2005-09-21 12:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&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: Closed >Resolution: Rejected Priority: 5 Submitted By: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: hashable and mutable functions Initial Comment: It is not easy to check if an object is hashable, ie hasattr(list(), '__hash__') -> True try: hash(list()) except TypeError: pass seems to be a possible way to see if an object is hashable, however it is not satisfiable that this information needs to be retrieved by using exception handling. My proposal: There should be a hashable(obj) function returning a bool object and additionally it would be nice to have something like ismutable(obj) function, possibly as built-in functions. Reason: callable() is a built-in function and returns information about an object whether it's callable or not, that is a basic info about this object. If an object is hashable or mutable is a state of an object that is also very important to know. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-22 04:20 Message: Logged In: YES user_id=80475 Adding a third -1 from me and closing the RFE. -- Comment By: Michael Hudson (mwh) Date: 2005-09-22 03:16 Message: Logged In: YES user_id=6656 def ishashable(ob): try: hash(ob) return True except TypeError: return False is the only reasonable way to implement this function (incidentally, do you know how hasattr works?). I don't see the need for a builtin, but am not feeling bolshy enough to just close the tracker item. Maybe someone else does. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 01:27 Message: Logged In: YES user_id=1188172 > try: hash(list()) > except TypeError: pass > > seems to be a possible way to see if an object is > hashable, however it is not satisfiable that this > information needs to be retrieved by using exception > handling. Why? > My proposal: > There should be a hashable(obj) function returning a > bool object and additionally it would be nice to have > something like ismutable(obj) function, possibly as > built-in functions. How should "ismutable" be implemented? > Reason: > callable() is a built-in function and returns > information about an object whether it's callable or > not, that is a basic info about this object. > If an object is hashable or mutable is a state of an > object that is also very important to know. It's easier to ask for forgiveness than permission. Even callable() has been called a mistake. Just call it and see where you come. So, -1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1298709 ] _socket module not build under cygwin
Bugs item #1298709, was opened at 2005-09-22 15:59 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=1298709&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: _socket module not build under cygwin Initial Comment: Hello, Bulding Python-2.4.2c1 under cygwin gives the following: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -I. -I/home/mtebeka/src/Python-2.4.2c1/./Include -I/home/mtebeka/src/Python-2.4.2c1/Include -I/home/mtebeka/src/Python-2.4.2c1 -c /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c -o build/temp.cygwin-1.5.18-i686-2.4/socketmodule.o /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c: In function `socket_inet_ntop': /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: `INET_ADDRSTRLEN' undeclared (first use in this function) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: (Each undeclared identifier is reported only once /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: for each function it appears in.) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: warning: unused variable `ip' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1298709 ] _socket module not build under cygwin
Bugs item #1298709, was opened at 2005-09-22 15:59 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: _socket module not build under cygwin Initial Comment: Hello, Bulding Python-2.4.2c1 under cygwin gives the following: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -I. -I/home/mtebeka/src/Python-2.4.2c1/./Include -I/home/mtebeka/src/Python-2.4.2c1/Include -I/home/mtebeka/src/Python-2.4.2c1 -c /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c -o build/temp.cygwin-1.5.18-i686-2.4/socketmodule.o /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c: In function `socket_inet_ntop': /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: `INET_ADDRSTRLEN' undeclared (first use in this function) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: (Each undeclared identifier is reported only once /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: for each function it appears in.) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: warning: unused variable `ip' -- >Comment By: Miki Tebeka (tebeka) Date: 2005-09-22 16:22 Message: Logged In: YES user_id=358087 The problem can be sloved by adding the following lines in socketmodule.c beginning. /* FIXME: We should include ws2tcpip.h, however this causes compilation problems */ #if defined(__CYGWIN__) #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 #endif /* __CYGWIN__ */ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&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-467924 ] Improve the ZipFile Interface
Feature Requests item #467924, was opened at 2001-10-04 10:54
Message generated for change (Comment added) made by crhode
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve the ZipFile Interface
Initial Comment:
There exist two methods to write to a ZipFile
write(self, filename, arcname=None, compress_type=None)
writestr(self, zinfo, bytes)
but only one to read from it
read(self, name)
Additionally, the two 'write's behave differently with respect to compression.
---
(a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a
ZipFile,
but 'read' is not the reverse operation. 'read' should be called 'readstr'
since it
much better matches to 'writestr'.
(b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a
file,
or into the ZipFile? It would be more obvious if ZipFile has 4 methods
which
pair-wise fit together:
writestr (self, zinfo, bytes)
# same as now
readstr (self, name)
# returns bytes (as string), currently called 'read'
# 'read' could still live but should be deprecated
add (self, filename, arcname=None, compress_type=None)
# currently 'write'
# 'write' could still live but should be deprecated
extract (self, name, filename, arcname=None)
# new, desired functionality
(c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that
was
passed to the constructor of 'ZipFile'. Currently, 'write' does it,
'writestr' via
zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED'
:-(
It should not do that! It rather should:
- allow more parameters in the signature of the constructor
to also pass the compression type (and some other attributes, too)
- default to 'None', so that 'writestr' can see this, and then take
the default from the 'ZipFile' instance.
--
Comment By: Chuck Rhode (crhode)
Date: 2005-09-22 10:56
Message:
Logged In: YES
user_id=988879
I've been trying to read map files put out by the Census
Bureau. These ZIP archives are downloaded from government
contractors' sites by county. Within each county archive
are several ZIP files for each map layer (roads, streams,
waterbodies, etc). Each contains the elements of an ESRI
shapefile database (.shp, .shx., and .dbf files). This
doesn't make a lot of sense to me, either, because there's
no compression advantage to making an archive of an archive.
The technique is used purely for organizational purposes
because ZIP does not compress subdirectories.
Note: I've never seen a TAR of TAR files because TAR *does*
compress subdirectories.
What I've been struggling with is a way to leave these
archives in their compressed form and still do *python* I/O
on them. There is a tree organization to them, after all,
just as with traditional os.path directories. I've designed
some objects that let me retrieve the most recent file, ZIP
member, or TAR member by name from a given path to a
repository of such archives. What I get is a StreamIO
object that I can subsequently put back where it came from.
What would be nice is if there already were objects
available to manipulate normal os.path directories comingled
with ZIP and TAR archives. What would be nicer is if I/O
could be opened at the character/line level transparently
without regard to whether the source/destination was a file
or an archive member within such a structure. In the days
of hardware compression and on-the-fly encryption/decryption
of I/O, is this too much to ask? -ccr-
--
Comment By: Myers Carpenter (myers_carpenter)
Date: 2004-05-09 13:23
Message:
Logged In: YES
user_id=335935
The zipfile interface should match the tarfile interface.
At the mininum is should work for this example:
import zipfile
zip = zipfile.open("sample.zip", "r")
for zipinfo in zip:
print tarinfo.name, "is", tarinfo.size, "bytes in size
and is",
zip.extract(zipinfo)
zip.close()
This closely matchs the 'tarfile' module.
--
Comment By: Matt Zimmerman (mzimmerman)
Date: 2003-07-31 09:22
Message:
Logged In: YES
user_id=196786
It would also be very useful to be able to have ZipFile
read/write the uncompressed file data from/to a file-like
object, instead of just strings and files (respectively).
I would like to use this module to work with zip f
[ python-Bugs-1298962 ] MSI installer does not pass values from UI
Bugs item #1298962, was opened at 2005-09-22 17:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&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: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Nobody/Anonymous (nobody) Summary: MSI installer does not pass values from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1299051 ] "Howto RE" link is dead
Bugs item #1299051, was opened at 2005-09-22 12:32 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=1299051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Macs R We (macsrwe) Assigned to: Nobody/Anonymous (nobody) Summary: "Howto RE" link is dead Initial Comment: On page http://www.python.org/doc/2.3.5/lib/re-syntax.html The link to "Regular expressions HOWTO" documentation ends up at http://www.amk.ca/python/howto/, which is a dead host. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1296433 ] expat crash python
Bugs item #1296433, was opened at 2005-09-20 07:10
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&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: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Mike Rozhnov (rozhnov)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat crash python
Initial Comment:
This simple script crash python.
Parsing of commented xml string work good.
(i.e. raised exception not crash python)
Buffer overflow during convertion to unicode?
Tested on Win XP and linux with kernel 2.4 with same
results.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-22 14:54
Message:
Logged In: YES
user_id=33168
I can reproduce on Linux with current CVS and expat
1.95.5-2. Note the size of the data only needs to be
greater than 1024.
xml = "%s" %
('a' * 1025)
I am not certain this problem is specific to Python. It
might be down in expat only. Need to investigate further.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1299187 ] build fails on Solaris 10 for Objects/complexobject.c
Bugs item #1299187, was opened at 2005-09-22 22:19 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=1299187&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kenneth Simpson (dharmakat) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on Solaris 10 for Objects/complexobject.c Initial Comment: Solaris 10 gcc 3.4.4 gas 2.16.1 python 2.4.2c1 /usr/devtools/bin/gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -fPIC -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299187&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1299520 ] Tkinter Scale returns only integer from/to values
Bugs item #1299520, was opened at 2005-09-22 18: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=1299520&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Goddard (tom_goddard) Assigned to: Martin v. Löwis (loewis) Summary: Tkinter Scale returns only integer from/to values Initial Comment: Tk "scale" widgets allow floating point range values. But Tkinter.Scale returns integer values for 'from' and 'to' attributes even when they were set to non-integer values. >>> s = Tkinter.Scale() >>> s['from'] = 1.23 >>> s['from'] 1.0 The problem is in the Tkinter.Scale.get method. It converts the floating point value to an integer. >From Tkinter.py: getint = int class Scale(Widget): def get(self): """Get the current value as integer or float.""" value = self.tk.call(self._w, 'get') try: return getint(value) except ValueError: return getdouble(value) def set(self, value): """Set the value to VALUE.""" self.tk.call(self._w, 'set', value) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299520&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1299520 ] Tkinter Scale returns only integer from/to values
Bugs item #1299520, was opened at 2005-09-22 18:45 Message generated for change (Settings changed) made by tom_goddard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299520&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.4 >Status: Deleted Resolution: None Priority: 5 Submitted By: Tom Goddard (tom_goddard) Assigned to: Martin v. Löwis (loewis) Summary: Tkinter Scale returns only integer from/to values Initial Comment: Tk "scale" widgets allow floating point range values. But Tkinter.Scale returns integer values for 'from' and 'to' attributes even when they were set to non-integer values. >>> s = Tkinter.Scale() >>> s['from'] = 1.23 >>> s['from'] 1.0 The problem is in the Tkinter.Scale.get method. It converts the floating point value to an integer. >From Tkinter.py: getint = int class Scale(Widget): def get(self): """Get the current value as integer or float.""" value = self.tk.call(self._w, 'get') try: return getint(value) except ValueError: return getdouble(value) def set(self, value): """Set the value to VALUE.""" self.tk.call(self._w, 'set', value) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299520&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1297059 ] Incorrect return type for search() method
Bugs item #1297059, was opened at 2005-09-20 17:12 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297059&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: Fixed Priority: 5 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect return type for search() method Initial Comment: The documentation for search() method of the IMAP4 object says that it returns a string, but it actually returns a tuple. >>> print imaplib.IMAP4.search.__doc__ Search mailbox for matching messages. (typ, [data]) = .search(charset, criterion, ...) 'data' is space separated list of matching message numbers. Error can be seen in docs on page: http://docs.python.org/lib/imap4-objects.html Yours, Noah -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 21:28 Message: Logged In: YES user_id=33168 Thanks. I removed the sentance about returned data since there is a description of all return values at the top of the doc. I also corrected the examples. Checked in as: * Doc/lib/libimaplib.tex 1.34 and 1.30.4.3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297059&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1298709 ] _socket module not build under cygwin
Bugs item #1298709, was opened at 2005-09-22 05:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Jason Tishler (jlt63) Summary: _socket module not build under cygwin Initial Comment: Hello, Bulding Python-2.4.2c1 under cygwin gives the following: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -I. -I/home/mtebeka/src/Python-2.4.2c1/./Include -I/home/mtebeka/src/Python-2.4.2c1/Include -I/home/mtebeka/src/Python-2.4.2c1 -c /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c -o build/temp.cygwin-1.5.18-i686-2.4/socketmodule.o /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c: In function `socket_inet_ntop': /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: `INET_ADDRSTRLEN' undeclared (first use in this function) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: (Each undeclared identifier is reported only once /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: for each function it appears in.) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: warning: unused variable `ip' -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 21:31 Message: Logged In: YES user_id=33168 Jason, are you still working on Cygwin issues? -- Comment By: Miki Tebeka (tebeka) Date: 2005-09-22 06:22 Message: Logged In: YES user_id=358087 The problem can be sloved by adding the following lines in socketmodule.c beginning. /* FIXME: We should include ws2tcpip.h, however this causes compilation problems */ #if defined(__CYGWIN__) #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 #endif /* __CYGWIN__ */ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1299187 ] build fails on Solaris 10 for Objects/complexobject.c
Bugs item #1299187, was opened at 2005-09-22 15:19 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299187&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Kenneth Simpson (dharmakat) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on Solaris 10 for Objects/complexobject.c Initial Comment: Solaris 10 gcc 3.4.4 gas 2.16.1 python 2.4.2c1 /usr/devtools/bin/gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -fPIC -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 21:46 Message: Logged In: YES user_id=33168 Dupe of 1276509 and possibly others. If you could work on a patch that would be great. I don't have access to Solaris 10. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299187&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1276509 ] 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL)
Bugs item #1276509, was opened at 2005-08-30 03:48 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: csmuc (chrschaffer) Assigned to: Nobody/Anonymous (nobody) >Summary: 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL) Initial Comment: Hi all, my efforts building Python 2.4.1 on Solaris 10(x386) failed. The error mesage reads: (...)Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus *** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' I found bug 970334 dealing with that topic, but I didn't find a solution provided. I tried with various compilers and libraries, e.g. /opt/sfw/bin/gcc --version gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. /opt/csw/gcc3/bin/gcc --version gcc (GCC) 3.4.4 Copyright (C) 2004 Free Software Foundation, Inc. /usr/local/bin/gcc --version gcc (GCC) 3.3.2 The same result with any of them. I didn't get the solution provided in http://mail.python.org/pipermail/python-list/2005-August/293795.html to work for me, unfortunately. I'd be glad, if you could have a look into this issue. Thanks in advance, Chris -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 00:03 Message: Logged In: YES user_id=1188172 Looks like HUGE_VAL is defined in a curious way on your platform. Can you find out what header defines HUGE_VAL and to what it expands? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1298709 ] _socket module not build under cygwin
Bugs item #1298709, was opened at 2005-09-22 05:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Jason Tishler (jlt63) Summary: _socket module not build under cygwin Initial Comment: Hello, Bulding Python-2.4.2c1 under cygwin gives the following: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -I. -I/home/mtebeka/src/Python-2.4.2c1/./Include -I/home/mtebeka/src/Python-2.4.2c1/Include -I/home/mtebeka/src/Python-2.4.2c1 -c /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c -o build/temp.cygwin-1.5.18-i686-2.4/socketmodule.o /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c: In function `socket_inet_ntop': /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: `INET_ADDRSTRLEN' undeclared (first use in this function) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: (Each undeclared identifier is reported only once /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: for each function it appears in.) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: warning: unused variable `ip' -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 21:56 Message: Logged In: YES user_id=33168 Patch is also #1275079. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 21:31 Message: Logged In: YES user_id=33168 Jason, are you still working on Cygwin issues? -- Comment By: Miki Tebeka (tebeka) Date: 2005-09-22 06:22 Message: Logged In: YES user_id=358087 The problem can be sloved by adding the following lines in socketmodule.c beginning. /* FIXME: We should include ws2tcpip.h, however this causes compilation problems */ #if defined(__CYGWIN__) #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 #endif /* __CYGWIN__ */ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
