[ python-Bugs-1252733 ] os.system on win32 can't handle pathnames with spaces
Bugs item #1252733, was opened at 2005-08-05 20:55
Message generated for change (Comment added) made by salty-horse
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252733&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Ori Avtalion (salty-horse)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.system on win32 can't handle pathnames with spaces
Initial Comment:
when calling os.system("file with spaces.exe"), Windows
outputs the following:
'file' is not recognized as an internal or external
command,
operable program or batch file.
I tried quoting the filename. Still got the same error.
--
>Comment By: Ori Avtalion (salty-horse)
Date: 2005-08-06 13:13
Message:
Logged In: YES
user_id=854801
os.execute("\file with spaces\") seems to solve the problem.
Documentation here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp
Turns out this is NOT a bug.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-05 21:41
Message:
Logged In: YES
user_id=1188172
Can you escape the spaces with backslashes? Or with
circumflexes?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252733&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis'
Bugs item #1251921, was opened at 2005-08-04 16:11
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&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: Closed
>Resolution: Invalid
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Fail codecs.lookup() on 'mbcs' and 'tactis'
Initial Comment:
$ python
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import codecs
>>> codecs.lookup('ascii')
(, , , )
>>> codecs.lookup('mbcs')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/encodings/__init__.py", line
96, in search_function
globals(), locals(), _import_tail)
File "/usr/lib/python2.4/encodings/mbcs.py", line 14,
in ?
class Codec(codecs.Codec):
File "/usr/lib/python2.4/encodings/mbcs.py", line 18,
in Codec
encode = codecs.mbcs_encode
AttributeError: 'module' object has no attribute
'mbcs_encode'
>>> codecs.lookup('tactis')
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: tactis
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 13:56
Message:
Logged In: YES
user_id=21627
Yes, UTF-8 is a multi-byte character set, but no, UTF-8 and
mbcs are not synonyms. See
http://docs.python.org/lib/standard-encodings.html
for the documentation. encodings.aliases.aliases is no
registration - it is an alias databse. So if somebody refers
to "dbcs", this will be aliased to "mbcs". That does not
mean "mbcs" needs to be supported - it only means "dbcs" is
not supported on Linux, either.
tactis was never part of a Python release, so its lack is
not a bug.
Closing this report as invalid.
--
Comment By: liturgist (liturgist)
Date: 2005-08-04 17:00
Message:
Logged In: YES
user_id=197677
If 'mbcs' is Windows-only, then why does it appear in the
list of registered codecs in encodings.aliases.aliases on
the Linux platform? Shouldn't it not be registered on other
platforms?
--
Comment By: liturgist (liturgist)
Date: 2005-08-04 16:55
Message:
Logged In: YES
user_id=197677
UTF-8 is an MBCS encoding in that is is a "multiple byte
character set", right? :-) UTF-16 is an MSCS; multiple
short character set.
There appears to have been some discussion on 'tactis' and
'tactis260' earlier in bug 854511.
http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-04 16:38
Message:
Logged In: YES
user_id=38388
mbcs is only available on Windows.
I'm not sure what happened to the tactis codec - it's
possible that it never got checked in.
Do you have a reference for the tactis encoding ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249749 ] Encodings and aliases do not match runtime
Bugs item #1249749, was opened at 2005-08-01 20:23
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: Nobody/Anonymous (nobody)
Summary: Encodings and aliases do not match runtime
Initial Comment:
2.4.1 documentation has a list of standard encodings in
4.9.2. However, this list does not seem to match what
is returned by the runtime. Below is code to dump out
the encodings and aliases. Please tell me if anything
is incorrect.
In some cases, there are many more valid aliases than
listed in the documentation. See 'cp037' as an example.
I see that the identifiers are intended to be case
insensitive. I would prefer to see the documentation
provide the identifiers as they will appear in
encodings.aliases.aliases. The only alias containing
any upper case letters appears to be 'hp_roman8'.
$ cat encodingaliases.py
#!/usr/bin/env python
import sys
import encodings
def main():
enchash = {}
for enc in encodings.aliases.aliases.values():
enchash[enc] = []
for encalias in encodings.aliases.aliases.keys():
enchash[encodings.aliases.aliases[encalias]].append(encalias)
elist = enchash.keys()
elist.sort()
for enc in elist:
print enc, enchash[enc]
if __name__ == '__main__':
main()
sys.exit(0)
13:12 pwatson [
ruth.knightsbridge.com:/home/pwatson/src/python ] 366
$ ./encodingaliases.py
ascii ['iso_ir_6', 'ansi_x3_4_1968', 'ibm367',
'iso646_us', 'us', 'cp367', '646', 'us_ascii',
'csascii', 'ansi_x3.4_1986', 'iso_646.irv_1991',
'ansi_x3.4_1968']
base64_codec ['base_64', 'base64']
big5 ['csbig5', 'big5_tw']
big5hkscs ['hkscs', 'big5_hkscs']
bz2_codec ['bz2']
cp037 ['ebcdic_cp_wt', 'ebcdic_cp_us', 'ebcdic_cp_nl',
'037', 'ibm039', 'ibm037', 'csibm037', 'ebcdic_cp_ca']
cp1026 ['csibm1026', 'ibm1026', '1026']
cp1140 ['1140', 'ibm1140']
cp1250 ['1250', 'windows_1250']
cp1251 ['1251', 'windows_1251']
cp1252 ['windows_1252', '1252']
cp1253 ['1253', 'windows_1253']
cp1254 ['1254', 'windows_1254']
cp1255 ['1255', 'windows_1255']
cp1256 ['1256', 'windows_1256']
cp1257 ['1257', 'windows_1257']
cp1258 ['1258', 'windows_1258']
cp424 ['ebcdic_cp_he', 'ibm424', '424', 'csibm424']
cp437 ['ibm437', '437', 'cspc8codepage437']
cp500 ['csibm500', 'ibm500', '500', 'ebcdic_cp_ch',
'ebcdic_cp_be']
cp775 ['cspc775baltic', '775', 'ibm775']
cp850 ['ibm850', 'cspc850multilingual', '850']
cp852 ['ibm852', '852', 'cspcp852']
cp855 ['csibm855', 'ibm855', '855']
cp857 ['csibm857', 'ibm857', '857']
cp860 ['csibm860', 'ibm860', '860']
cp861 ['csibm861', 'cp_is', 'ibm861', '861']
cp862 ['cspc862latinhebrew', 'ibm862', '862']
cp863 ['csibm863', 'ibm863', '863']
cp864 ['csibm864', 'ibm864', '864']
cp865 ['csibm865', 'ibm865', '865']
cp866 ['csibm866', 'ibm866', '866']
cp869 ['csibm869', 'ibm869', '869', 'cp_gr']
cp932 ['mskanji', '932', 'ms932', 'ms_kanji']
cp949 ['uhc', 'ms949', '949']
cp950 ['ms950', '950']
euc_jis_2004 ['eucjis2004', 'jisx0213', 'euc_jis2004']
euc_jisx0213 ['eucjisx0213']
euc_jp ['eucjp', 'ujis', 'u_jis']
euc_kr ['ksc5601', 'korean', 'euckr', 'ksx1001',
'ks_c_5601', 'ks_c_5601_1987', 'ks_x_1001']
gb18030 ['gb18030_2000']
gb2312 ['chinese', 'euc_cn', 'csiso58gb231280',
'iso_ir_58', 'euccn', 'eucgb2312_cn', 'gb2312_1980',
'gb2312_80']
gbk ['cp936', 'ms936', '936']
hex_codec ['hex']
hp_roman8 ['csHPRoman8', 'r8', 'roman8']
hz ['hzgb', 'hz_gb_2312', 'hz_gb']
iso2022_jp ['iso2022jp', 'iso_2022_jp', 'csiso2022jp']
iso2022_jp_1 ['iso_2022_jp_1', 'iso2022jp_1']
iso2022_jp_2 ['iso_2022_jp_2', 'iso2022jp_2']
iso2022_jp_2004 ['iso_2022_jp_2004', 'iso2022jp_2004']
iso2022_jp_3 ['iso_2022_jp_3', 'iso2022jp_3']
iso2022_jp_ext ['iso2022jp_ext', 'iso_2022_jp_ext']
iso2022_kr ['iso_2022_kr', 'iso2022kr', 'csiso2022kr']
iso8859_10 ['csisolatin6', 'l6', 'iso_8859_10_1992',
'iso_ir_157', 'iso_8859_10', 'latin6']
iso8859_11 ['iso_8859_11', 'thai', 'iso_8859_11_2001']
iso8859_13 ['iso_8859_13']
iso8859_14 ['iso_celtic', 'iso_ir_199', 'l8',
'iso_8859_14_1998', 'iso_8859_14', 'latin8']
iso8859_15 ['iso_8859_15']
iso8859_16 ['iso_8859_16_2001', 'l10', 'iso_ir_226',
'latin10', 'iso_8859_16']
iso8859_2 ['l2', 'csisolatin2', 'iso_ir_101',
'iso_8859_2', 'iso_8859_2_1987', 'latin2']
iso8859_3 ['iso_8859_3_1988', 'l3', 'iso_ir_109',
'csisolatin3', 'iso_8859_3', 'latin3']
iso8859_4 ['csisolatin4', 'l4', 'iso_ir_110',
'iso_8859_4', 'iso_8859_4_1988', 'latin4']
iso8859_5 ['iso_8859_5_1988', 'iso_8859_5', 'cyrillic',
'csisolatincyrillic', 'iso_ir_144']
iso8859_6 ['iso_8859_6_1987', 'iso_ir_127',
'csisolatinarabic', 'asmo_708', 'iso_8859_6',
'ecma_114', 'arabic']
iso8859_7 ['ecma_118', 'greek8', 'is
[ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7
Bugs item #1244610, was opened at 2005-07-25 18:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:43 Message: Logged In: YES user_id=21627 So can you tell us whether there are missing prerequisite headers? One would need to have access to your operating system to resolve this issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241006 ] Distutils does not use logging
Bugs item #1241006, was opened at 2005-07-19 19:21
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distutils does not use logging
Initial Comment:
distutils.log creates its own PEP 282-like logger
class, which is fine from the distutils point of view,
but not exactly brilliant if you want to intercept the
calls using the logging facilities that have been in
python since 2.3.
Recommended fix:
If, in fact, distutils.log has to be kept compatible
with 2.1 as is claimed in the source file then
something along the lines of:
try:
import logging
_global_log = logging.getLogger('distutils')
except ImportError:
#insert current Log class definition here
_global_log = Log()
Also, changing the values for DEBUG, INFO, WARN, ERROR and
FATAL to be the same as the ones in logging.py is
probably a good idea.
The distutils logger should have its own formatter that
prints out lines as the thing currently does, but this
formatter should be set within the code for setup()
rather than in the log module.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 14:45
Message:
Logged In: YES
user_id=21627
Can you provide a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1239948 ] distutils: MetroWerks support can go
Bugs item #1239948, was opened at 2005-07-17 23:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239948&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: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: distutils: MetroWerks support can go Initial Comment: I'm not sure how far back the current distutils (i.e. the one from the CVS trunk) is supposed to be backward compatible, but from 2.4 onwards Python does not support Mac OS 9 anymore, and therefore support for the MetroWerks C compiler can be ripped out. Theoretically there's an MW compiler on windows too, but nobody uses it and the mwerkscompiler object in distutils currently only support the Mac compiler. And actually only that in the exact way that MacPython used it. I'm basically asking for an opinion here: is it a good idea to rip mwerkscompiler out. Feel free to assign back to me to do the work. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:46 Message: Logged In: YES user_id=21627 distutils is meant to be compatible with Python 2.1. Don't know whether this means it still needs to support Metrowerks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239948&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1232947 ] non-admin install may fail (win xp pro)
Bugs item #1232947, was opened at 2005-07-05 20:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&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: Python 2.4 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Patrick Vrijlandt (pvrijlandt) Assigned to: Nobody/Anonymous (nobody) Summary: non-admin install may fail (win xp pro) Initial Comment: concerns: python 2.4.1 msi When trying to do a non-admin install on Windows XP Pro, the installer probably tries to make shortcuts in a non-accessible directory. The status-window is displaying: creating shortcuts A messagebox appears and says the installer lacks priveliges on a certain directory: please try again as an administrator, (which i am obviously not). The cancel-option now leads to a rollback of the installation. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:47 Message: Logged In: YES user_id=21627 Closed because of lack of response. -- Comment By: Martin v. Löwis (loewis) Date: 2005-07-06 07:16 Message: Logged In: YES user_id=21627 It works fine for me... Can you please install with msiexec /i python-2.4.1.msi /l*v python.log and attach a zipped version of python.log? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1232947 ] non-admin install may fail (win xp pro)
Bugs item #1232947, was opened at 2005-07-05 20:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&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: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Patrick Vrijlandt (pvrijlandt) Assigned to: Nobody/Anonymous (nobody) Summary: non-admin install may fail (win xp pro) Initial Comment: concerns: python 2.4.1 msi When trying to do a non-admin install on Windows XP Pro, the installer probably tries to make shortcuts in a non-accessible directory. The status-window is displaying: creating shortcuts A messagebox appears and says the installer lacks priveliges on a certain directory: please try again as an administrator, (which i am obviously not). The cancel-option now leads to a rollback of the installation. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:48 Message: Logged In: YES user_id=21627 Oops, missed the attachment. -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:47 Message: Logged In: YES user_id=21627 Closed because of lack of response. -- Comment By: Martin v. Löwis (loewis) Date: 2005-07-06 07:16 Message: Logged In: YES user_id=21627 It works fine for me... Can you please install with msiexec /i python-2.4.1.msi /l*v python.log and attach a zipped version of python.log? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249749 ] Encodings and aliases do not match runtime
Bugs item #1249749, was opened at 2005-08-01 20:23
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: Nobody/Anonymous (nobody)
Summary: Encodings and aliases do not match runtime
Initial Comment:
2.4.1 documentation has a list of standard encodings in
4.9.2. However, this list does not seem to match what
is returned by the runtime. Below is code to dump out
the encodings and aliases. Please tell me if anything
is incorrect.
In some cases, there are many more valid aliases than
listed in the documentation. See 'cp037' as an example.
I see that the identifiers are intended to be case
insensitive. I would prefer to see the documentation
provide the identifiers as they will appear in
encodings.aliases.aliases. The only alias containing
any upper case letters appears to be 'hp_roman8'.
$ cat encodingaliases.py
#!/usr/bin/env python
import sys
import encodings
def main():
enchash = {}
for enc in encodings.aliases.aliases.values():
enchash[enc] = []
for encalias in encodings.aliases.aliases.keys():
enchash[encodings.aliases.aliases[encalias]].append(encalias)
elist = enchash.keys()
elist.sort()
for enc in elist:
print enc, enchash[enc]
if __name__ == '__main__':
main()
sys.exit(0)
13:12 pwatson [
ruth.knightsbridge.com:/home/pwatson/src/python ] 366
$ ./encodingaliases.py
ascii ['iso_ir_6', 'ansi_x3_4_1968', 'ibm367',
'iso646_us', 'us', 'cp367', '646', 'us_ascii',
'csascii', 'ansi_x3.4_1986', 'iso_646.irv_1991',
'ansi_x3.4_1968']
base64_codec ['base_64', 'base64']
big5 ['csbig5', 'big5_tw']
big5hkscs ['hkscs', 'big5_hkscs']
bz2_codec ['bz2']
cp037 ['ebcdic_cp_wt', 'ebcdic_cp_us', 'ebcdic_cp_nl',
'037', 'ibm039', 'ibm037', 'csibm037', 'ebcdic_cp_ca']
cp1026 ['csibm1026', 'ibm1026', '1026']
cp1140 ['1140', 'ibm1140']
cp1250 ['1250', 'windows_1250']
cp1251 ['1251', 'windows_1251']
cp1252 ['windows_1252', '1252']
cp1253 ['1253', 'windows_1253']
cp1254 ['1254', 'windows_1254']
cp1255 ['1255', 'windows_1255']
cp1256 ['1256', 'windows_1256']
cp1257 ['1257', 'windows_1257']
cp1258 ['1258', 'windows_1258']
cp424 ['ebcdic_cp_he', 'ibm424', '424', 'csibm424']
cp437 ['ibm437', '437', 'cspc8codepage437']
cp500 ['csibm500', 'ibm500', '500', 'ebcdic_cp_ch',
'ebcdic_cp_be']
cp775 ['cspc775baltic', '775', 'ibm775']
cp850 ['ibm850', 'cspc850multilingual', '850']
cp852 ['ibm852', '852', 'cspcp852']
cp855 ['csibm855', 'ibm855', '855']
cp857 ['csibm857', 'ibm857', '857']
cp860 ['csibm860', 'ibm860', '860']
cp861 ['csibm861', 'cp_is', 'ibm861', '861']
cp862 ['cspc862latinhebrew', 'ibm862', '862']
cp863 ['csibm863', 'ibm863', '863']
cp864 ['csibm864', 'ibm864', '864']
cp865 ['csibm865', 'ibm865', '865']
cp866 ['csibm866', 'ibm866', '866']
cp869 ['csibm869', 'ibm869', '869', 'cp_gr']
cp932 ['mskanji', '932', 'ms932', 'ms_kanji']
cp949 ['uhc', 'ms949', '949']
cp950 ['ms950', '950']
euc_jis_2004 ['eucjis2004', 'jisx0213', 'euc_jis2004']
euc_jisx0213 ['eucjisx0213']
euc_jp ['eucjp', 'ujis', 'u_jis']
euc_kr ['ksc5601', 'korean', 'euckr', 'ksx1001',
'ks_c_5601', 'ks_c_5601_1987', 'ks_x_1001']
gb18030 ['gb18030_2000']
gb2312 ['chinese', 'euc_cn', 'csiso58gb231280',
'iso_ir_58', 'euccn', 'eucgb2312_cn', 'gb2312_1980',
'gb2312_80']
gbk ['cp936', 'ms936', '936']
hex_codec ['hex']
hp_roman8 ['csHPRoman8', 'r8', 'roman8']
hz ['hzgb', 'hz_gb_2312', 'hz_gb']
iso2022_jp ['iso2022jp', 'iso_2022_jp', 'csiso2022jp']
iso2022_jp_1 ['iso_2022_jp_1', 'iso2022jp_1']
iso2022_jp_2 ['iso_2022_jp_2', 'iso2022jp_2']
iso2022_jp_2004 ['iso_2022_jp_2004', 'iso2022jp_2004']
iso2022_jp_3 ['iso_2022_jp_3', 'iso2022jp_3']
iso2022_jp_ext ['iso2022jp_ext', 'iso_2022_jp_ext']
iso2022_kr ['iso_2022_kr', 'iso2022kr', 'csiso2022kr']
iso8859_10 ['csisolatin6', 'l6', 'iso_8859_10_1992',
'iso_ir_157', 'iso_8859_10', 'latin6']
iso8859_11 ['iso_8859_11', 'thai', 'iso_8859_11_2001']
iso8859_13 ['iso_8859_13']
iso8859_14 ['iso_celtic', 'iso_ir_199', 'l8',
'iso_8859_14_1998', 'iso_8859_14', 'latin8']
iso8859_15 ['iso_8859_15']
iso8859_16 ['iso_8859_16_2001', 'l10', 'iso_ir_226',
'latin10', 'iso_8859_16']
iso8859_2 ['l2', 'csisolatin2', 'iso_ir_101',
'iso_8859_2', 'iso_8859_2_1987', 'latin2']
iso8859_3 ['iso_8859_3_1988', 'l3', 'iso_ir_109',
'csisolatin3', 'iso_8859_3', 'latin3']
iso8859_4 ['csisolatin4', 'l4', 'iso_ir_110',
'iso_8859_4', 'iso_8859_4_1988', 'latin4']
iso8859_5 ['iso_8859_5_1988', 'iso_8859_5', 'cyrillic',
'csisolatincyrillic', 'iso_ir_144']
iso8859_6 ['iso_8859_6_1987', 'iso_ir_127',
'csisolatinarabic', 'asmo_708', 'iso_8859_6',
'ecma_114', 'arabic']
iso8859_7 ['ecma_118', 'greek8', 'i
[ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis'
Bugs item #1251921, was opened at 2005-08-04 16:11
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&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: Remind
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Fail codecs.lookup() on 'mbcs' and 'tactis'
Initial Comment:
$ python
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import codecs
>>> codecs.lookup('ascii')
(, , , )
>>> codecs.lookup('mbcs')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/encodings/__init__.py", line
96, in search_function
globals(), locals(), _import_tail)
File "/usr/lib/python2.4/encodings/mbcs.py", line 14,
in ?
class Codec(codecs.Codec):
File "/usr/lib/python2.4/encodings/mbcs.py", line 18,
in Codec
encode = codecs.mbcs_encode
AttributeError: 'module' object has no attribute
'mbcs_encode'
>>> codecs.lookup('tactis')
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: tactis
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-06 14:51
Message:
Logged In: YES
user_id=38388
Reopened: this is indeed a bug - the tactis codec is
referenced in the aliases table but was never added to the
encodings package.
Either the codec will have to be added, or the alias entry
removed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 13:56
Message:
Logged In: YES
user_id=21627
Yes, UTF-8 is a multi-byte character set, but no, UTF-8 and
mbcs are not synonyms. See
http://docs.python.org/lib/standard-encodings.html
for the documentation. encodings.aliases.aliases is no
registration - it is an alias databse. So if somebody refers
to "dbcs", this will be aliased to "mbcs". That does not
mean "mbcs" needs to be supported - it only means "dbcs" is
not supported on Linux, either.
tactis was never part of a Python release, so its lack is
not a bug.
Closing this report as invalid.
--
Comment By: liturgist (liturgist)
Date: 2005-08-04 17:00
Message:
Logged In: YES
user_id=197677
If 'mbcs' is Windows-only, then why does it appear in the
list of registered codecs in encodings.aliases.aliases on
the Linux platform? Shouldn't it not be registered on other
platforms?
--
Comment By: liturgist (liturgist)
Date: 2005-08-04 16:55
Message:
Logged In: YES
user_id=197677
UTF-8 is an MBCS encoding in that is is a "multiple byte
character set", right? :-) UTF-16 is an MSCS; multiple
short character set.
There appears to have been some discussion on 'tactis' and
'tactis260' earlier in bug 854511.
http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-04 16:38
Message:
Logged In: YES
user_id=38388
mbcs is only available on Windows.
I'm not sure what happened to the tactis codec - it's
possible that it never got checked in.
Do you have a reference for the tactis encoding ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1232947 ] non-admin install may fail (win xp pro)
Bugs item #1232947, was opened at 2005-07-05 20:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Vrijlandt (pvrijlandt) >Assigned to: Martin v. Löwis (loewis) Summary: non-admin install may fail (win xp pro) Initial Comment: concerns: python 2.4.1 msi When trying to do a non-admin install on Windows XP Pro, the installer probably tries to make shortcuts in a non-accessible directory. The status-window is displaying: creating shortcuts A messagebox appears and says the installer lacks priveliges on a certain directory: please try again as an administrator, (which i am obviously not). The cancel-option now leads to a rollback of the installation. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:58 Message: Logged In: YES user_id=21627 According to the log file, there was an error accessing \bw2\snelkop\2003\info\programma's\Python 2.4 How come your Menu folder is on a network drive? What is the ACL on that folder? -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:48 Message: Logged In: YES user_id=21627 Oops, missed the attachment. -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:47 Message: Logged In: YES user_id=21627 Closed because of lack of response. -- Comment By: Martin v. Löwis (loewis) Date: 2005-07-06 07:16 Message: Logged In: YES user_id=21627 It works fine for me... Can you please install with msiexec /i python-2.4.1.msi /l*v python.log and attach a zipped version of python.log? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1226969 ] segfault in os module
Bugs item #1226969, was opened at 2005-06-24 15:05
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: jacobo_es (jacobo_es)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in os module
Initial Comment:
python crashes when a bad parameters are passed to execl function
of the os module:
>>> import os
>>> os.execl("/bin/bash")
Segmentation Fault (core dumped)
No matter the platform (on ppc raises a bus error) and the version of
C compiler, always crashes, python versions used are 2.4.1 and
2.4c1.
Proved on MacOSX (ppc), and Knoppix, Red Hat Enterprise
and debian woody 3.0 (x86).
However, on 2.2.3 version not crashes.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 15:19
Message:
Logged In: YES
user_id=21627
There is nothing wrong with Python here. It is not Python
that crashes, but /bin/bash. Just try a different binary
(/usr/bin/id worked for me); use strace to see that it is
indeed the new process that crashes.
Closing as invalid.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-26 08:19
Message:
Logged In: YES
user_id=1188172
First, Python does not call the C execl functions, but
translates them to execv calls.
For execv called like Python does:
~/tmp> ./execv
zsh: 15395 segmentation fault ./execv
~/tmp> cat execv.c
#include
#include
int main() {
const char* args[1];
args[0] = NULL;
execv("/bin/bash", args);
return errno;
}
For execl on the C layer, my Linux doesn't want that:
~/tmp> gcc -o execl execl.c
execl.c: In function `main':
execl.c:4: error: too few arguments to function 'execl'
~/tmp> cat execv.c
#include
int main() {
execl("/bin/bash");
return 0;
}
--
Comment By: jacobo_es (jacobo_es)
Date: 2005-06-26 01:15
Message:
Logged In: YES
user_id=1302185
I tried this directly on the C layer, too, and not raises a
signal 11, segmentation fault, just the function execl()
isn't executed and the program flow goes, not raises a
sigsegv, and that's not happen in
the same way in python, that abort the python interpreter
and dump a core file.
-( tmp )- ./p
execl not executed.
-( tmp )- cat p.c
#include
int main() {
execl("/bin/bash");
fprintf(stderr, "execl not executed.\n");
exit(-1);
}
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-24 16:53
Message:
Logged In: YES
user_id=1188172
This behaviour was introduced with the fixing of bug
#952953, where someone complained that he couldn't call
execl with only one argument.
I tried this directly on the C layer on Linux, and it
segfaults too.
Are there OSes where this is legal?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241006 ] Distutils does not use logging
Bugs item #1241006, was opened at 2005-07-19 17:21
Message generated for change (Comment added) made by mewf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distutils does not use logging
Initial Comment:
distutils.log creates its own PEP 282-like logger
class, which is fine from the distutils point of view,
but not exactly brilliant if you want to intercept the
calls using the logging facilities that have been in
python since 2.3.
Recommended fix:
If, in fact, distutils.log has to be kept compatible
with 2.1 as is claimed in the source file then
something along the lines of:
try:
import logging
_global_log = logging.getLogger('distutils')
except ImportError:
#insert current Log class definition here
_global_log = Log()
Also, changing the values for DEBUG, INFO, WARN, ERROR and
FATAL to be the same as the ones in logging.py is
probably a good idea.
The distutils logger should have its own formatter that
prints out lines as the thing currently does, but this
formatter should be set within the code for setup()
rather than in the log module.
--
>Comment By: Giles Antonio Radford (mewf)
Date: 2005-08-06 16:46
Message:
Logged In: YES
user_id=859703
Yes, though I'm offline for most of this week, I'll try and
give it a go for next weekend.
Does it need to be kept compatible with python 2.1? Or is
2.3 and above OK?
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 12:45
Message:
Logged In: YES
user_id=21627
Can you provide a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241006 ] Distutils does not use logging
Bugs item #1241006, was opened at 2005-07-19 19:21
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distutils does not use logging
Initial Comment:
distutils.log creates its own PEP 282-like logger
class, which is fine from the distutils point of view,
but not exactly brilliant if you want to intercept the
calls using the logging facilities that have been in
python since 2.3.
Recommended fix:
If, in fact, distutils.log has to be kept compatible
with 2.1 as is claimed in the source file then
something along the lines of:
try:
import logging
_global_log = logging.getLogger('distutils')
except ImportError:
#insert current Log class definition here
_global_log = Log()
Also, changing the values for DEBUG, INFO, WARN, ERROR and
FATAL to be the same as the ones in logging.py is
probably a good idea.
The distutils logger should have its own formatter that
prints out lines as the thing currently does, but this
formatter should be set within the code for setup()
rather than in the log module.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 20:00
Message:
Logged In: YES
user_id=21627
It needs to stay backwards-compatible with 2.1, so you need
to fallback if logging is not available.
No need to hurry, though.
--
Comment By: Giles Antonio Radford (mewf)
Date: 2005-08-06 18:46
Message:
Logged In: YES
user_id=859703
Yes, though I'm offline for most of this week, I'll try and
give it a go for next weekend.
Does it need to be kept compatible with python 2.1? Or is
2.3 and above OK?
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 14:45
Message:
Logged In: YES
user_id=21627
Can you provide a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis'
Bugs item #1251921, was opened at 2005-08-04 09:11
Message generated for change (Comment added) made by liturgist
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&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: Remind
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Fail codecs.lookup() on 'mbcs' and 'tactis'
Initial Comment:
$ python
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import codecs
>>> codecs.lookup('ascii')
(, , , )
>>> codecs.lookup('mbcs')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/encodings/__init__.py", line
96, in search_function
globals(), locals(), _import_tail)
File "/usr/lib/python2.4/encodings/mbcs.py", line 14,
in ?
class Codec(codecs.Codec):
File "/usr/lib/python2.4/encodings/mbcs.py", line 18,
in Codec
encode = codecs.mbcs_encode
AttributeError: 'module' object has no attribute
'mbcs_encode'
>>> codecs.lookup('tactis')
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: tactis
--
>Comment By: liturgist (liturgist)
Date: 2005-08-06 14:04
Message:
Logged In: YES
user_id=197677
Where is bug 854511 regarding Thai encodings? The URL has
some discussion of this bug on TISI and ISO encodings.
http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-06 07:51
Message:
Logged In: YES
user_id=38388
Reopened: this is indeed a bug - the tactis codec is
referenced in the aliases table but was never added to the
encodings package.
Either the codec will have to be added, or the alias entry
removed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 06:56
Message:
Logged In: YES
user_id=21627
Yes, UTF-8 is a multi-byte character set, but no, UTF-8 and
mbcs are not synonyms. See
http://docs.python.org/lib/standard-encodings.html
for the documentation. encodings.aliases.aliases is no
registration - it is an alias databse. So if somebody refers
to "dbcs", this will be aliased to "mbcs". That does not
mean "mbcs" needs to be supported - it only means "dbcs" is
not supported on Linux, either.
tactis was never part of a Python release, so its lack is
not a bug.
Closing this report as invalid.
--
Comment By: liturgist (liturgist)
Date: 2005-08-04 10:00
Message:
Logged In: YES
user_id=197677
If 'mbcs' is Windows-only, then why does it appear in the
list of registered codecs in encodings.aliases.aliases on
the Linux platform? Shouldn't it not be registered on other
platforms?
--
Comment By: liturgist (liturgist)
Date: 2005-08-04 09:55
Message:
Logged In: YES
user_id=197677
UTF-8 is an MBCS encoding in that is is a "multiple byte
character set", right? :-) UTF-16 is an MSCS; multiple
short character set.
There appears to have been some discussion on 'tactis' and
'tactis260' earlier in bug 854511.
http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-04 09:38
Message:
Logged In: YES
user_id=38388
mbcs is only available on Windows.
I'm not sure what happened to the tactis codec - it's
possible that it never got checked in.
Do you have a reference for the tactis encoding ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis'
Bugs item #1251921, was opened at 2005-08-04 16:11
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&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: Remind
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Fail codecs.lookup() on 'mbcs' and 'tactis'
Initial Comment:
$ python
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import codecs
>>> codecs.lookup('ascii')
(, , , )
>>> codecs.lookup('mbcs')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/encodings/__init__.py", line
96, in search_function
globals(), locals(), _import_tail)
File "/usr/lib/python2.4/encodings/mbcs.py", line 14,
in ?
class Codec(codecs.Codec):
File "/usr/lib/python2.4/encodings/mbcs.py", line 18,
in Codec
encode = codecs.mbcs_encode
AttributeError: 'module' object has no attribute
'mbcs_encode'
>>> codecs.lookup('tactis')
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: tactis
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 21:09
Message:
Logged In: YES
user_id=21627
It's not a bug, it's a feature request, and it's at
http://python.org/sf/854511
I have rejected the request.
--
Comment By: liturgist (liturgist)
Date: 2005-08-06 21:04
Message:
Logged In: YES
user_id=197677
Where is bug 854511 regarding Thai encodings? The URL has
some discussion of this bug on TISI and ISO encodings.
http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-06 14:51
Message:
Logged In: YES
user_id=38388
Reopened: this is indeed a bug - the tactis codec is
referenced in the aliases table but was never added to the
encodings package.
Either the codec will have to be added, or the alias entry
removed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 13:56
Message:
Logged In: YES
user_id=21627
Yes, UTF-8 is a multi-byte character set, but no, UTF-8 and
mbcs are not synonyms. See
http://docs.python.org/lib/standard-encodings.html
for the documentation. encodings.aliases.aliases is no
registration - it is an alias databse. So if somebody refers
to "dbcs", this will be aliased to "mbcs". That does not
mean "mbcs" needs to be supported - it only means "dbcs" is
not supported on Linux, either.
tactis was never part of a Python release, so its lack is
not a bug.
Closing this report as invalid.
--
Comment By: liturgist (liturgist)
Date: 2005-08-04 17:00
Message:
Logged In: YES
user_id=197677
If 'mbcs' is Windows-only, then why does it appear in the
list of registered codecs in encodings.aliases.aliases on
the Linux platform? Shouldn't it not be registered on other
platforms?
--
Comment By: liturgist (liturgist)
Date: 2005-08-04 16:55
Message:
Logged In: YES
user_id=197677
UTF-8 is an MBCS encoding in that is is a "multiple byte
character set", right? :-) UTF-16 is an MSCS; multiple
short character set.
There appears to have been some discussion on 'tactis' and
'tactis260' earlier in bug 854511.
http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-04 16:38
Message:
Logged In: YES
user_id=38388
mbcs is only available on Windows.
I'm not sure what happened to the tactis codec - it's
possible that it never got checked in.
Do you have a reference for the tactis encoding ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1239948 ] distutils: MetroWerks support can go
Bugs item #1239948, was opened at 2005-07-17 23:44 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239948&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: Closed >Resolution: Later Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: distutils: MetroWerks support can go Initial Comment: I'm not sure how far back the current distutils (i.e. the one from the CVS trunk) is supposed to be backward compatible, but from 2.4 onwards Python does not support Mac OS 9 anymore, and therefore support for the MetroWerks C compiler can be ripped out. Theoretically there's an MW compiler on windows too, but nobody uses it and the mwerkscompiler object in distutils currently only support the Mac compiler. And actually only that in the exact way that MacPython used it. I'm basically asking for an opinion here: is it a good idea to rip mwerkscompiler out. Feel free to assign back to me to do the work. -- >Comment By: Jack Jansen (jackjansen) Date: 2005-08-06 23:22 Message: Logged In: YES user_id=45365 MacOS9 support is there up to 2.3. So then we should leave MertoWerks support in. -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:46 Message: Logged In: YES user_id=21627 distutils is meant to be compatible with Python 2.1. Don't know whether this means it still needs to support Metrowerks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239948&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
