[ python-Bugs-1220113 ] subprocess call() helper should close stdin if PIPE
Bugs item #1220113, was opened at 2005-06-14 07:04
Message generated for change (Comment added) made by astrand
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess call() helper should close stdin if PIPE
Initial Comment:
The following code snippet should die instead of hang.
>>> from subprocess import call, PIPE
>>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE,
stdin=PIPE)
It makes no sense not to close stdin if it is PIPE
because the stream cannot be accessed.
The use case for this is ensuring a subprocess that
detects if it is connected to a terminal or not runs in
'batch' mode, and that it will die instead of hang if
it unexpectidly attempts to read from stdin.
Workaround is to use Popen instead.
--
>Comment By: Peter Åstrand (astrand)
Date: 2005-06-22 10:45
Message:
Logged In: YES
user_id=344921
>Wanting to pass a closed file handle is common.
This is not my experience.
>It is needed when calling a program that behaves
differently if its stdin
>is a terminal or not.
Such programs are quite uncommon, and usually, it's a bad
idea to make such checks anyway.
>Or when you simply would prefer the subprocess to die if it
attempts to >read from its stdin rather than block
For this case, I would say that it's more common to pass
/dev/null than a closed file descriptor. It's uncommon with
shell scripts that does "someprogram <&4711". It's much more
common with "someprogram Using Popen instead of call is s simpler workaround than
>creating and closing a file descriptor and passing it in.
How would you use Popen in this case?
>Perhaps what is needed is a new constant, subprocess.CLOSED
>which creates a new file descriptor and closes it? This
>would be useful for Popen too, allowing call() to remain a
>think and trivially documented wrapper?
It's not very hard to get an unused FD:
closed_fd = os.open("/dev/null", os.O_RDONLY);
os.close(closed_fd)
I'm a bit reluctant to add a new constant when you can solve
the problem anyway with one line of code.
Also, we'll need to think about the platform portability a
bit. Currently, I think that if we should add anything at
all, it should be a constant like subprocess.NULL, which
would be basically like open("/dev/null"), but also
portable to Windows.
--
Comment By: Stuart Bishop (zenzen)
Date: 2005-06-22 08:12
Message:
Logged In: YES
user_id=46639
I can't think of any uses cases for wanting to create an
inaccessible pipe and give it to the child.
Wanting to pass a closed file handle is common. It is needed
when calling a program that behaves differently if its stdin
is a terminal or not. Or when you simply would prefer the
subprocess to die if it attempts to read from its stdin
rather than block.
Using Popen instead of call is s simpler workaround than
creating and closing a file descriptor and passing it in.
Perhaps what is needed is a new constant, subprocess.CLOSED
which creates a new file descriptor and closes it? This
would be useful for Popen too, allowing call() to remain a
think and trivially documented wrapper?
--
Comment By: Peter Åstrand (astrand)
Date: 2005-06-21 18:08
Message:
Logged In: YES
user_id=344921
>It makes no sense not to close stdin if it is PIPE
>because the stream cannot be accessed
True, but what if you actually *want* to create an
inaccessible pipe, and give it to the child?
Currently, the call() wrapper is *very* short and simple. I
think this is very good. For example, it allows us to
document it in two sentences. You get what you ask for: If
you use call() with strange arguments, you'll get a somewhat
strange behavíour. I see no point in introducing lots of
sanity checks in the wrapper functions.
>The use case for this is ensuring a subprocess that
>detects if it is connected to a terminal or not runs in
>batch' mode, and that it will die instead of hang if
>it unexpectidly attempts to read from stdin
I'm not sure I understand what you want, but if you want to
have stdin connected to a closed file descriptor, just pass one:
>>> from subprocess import call, PIPE
>>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE,
stdin=4711)
(Of course, you should verify that 4711 is unused.)
If you don't agree with me, post to python-dev for discussion.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=122
[ python-Bugs-1225059 ] Line endings problem with Python 2.4.1 cause imports to fail
Bugs item #1225059, was opened at 2005-06-21 20:56 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&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: Parser/Compiler Group: Python 2.4 Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) >Assigned to: Walter Dörwald (doerwalter) Summary: Line endings problem with Python 2.4.1 cause imports to fail Initial Comment: Hi, Here is my Python version string : ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 I'm having troubles with a series of source code files that were working perfectly under Python 2.4.0 and earlier releases. I have enclosed one of those source files which should be independent of the rest, so that you can test it by yourself. Now, here is my problem : Test 1 --- C:\projets\development\python\tcc>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win3 Type "help", "copyright", "credits" or "license" for more information. >>> import util Traceback (most recent call last): File "", line 1, in ? File "util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : this is the problem, the Python interpreter fails to parse the file. Note that is is a DOS-style file, with \r\n as lines separator, instead of simply \n. If I convert the file to a UNIX-style, \n separated lines format, then everything is OK. Test 2 --- C:\projets\development\python\tcc>python -i util.py C:\projets\development\python\tcc>python -i util.py >>> ^Z --- interpretation : launching the script instead of importing it is OK. It seems that the way scripts are loaded for direct launching is different than the way they are loaded for import. Test 3 --- C:\projets\development\python\tcc>python -m util File "C:\projets\development\python\tcc\util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : using another way to import the module and launch it yield the same buggy behaviour. Once again, if I convert line termination from DOS to UNIX, everything is OK. I've seen a few bugs related to rstrip() and readline() having a new behaviour, maybe this problem is related ? This is quite an annoying bug, because some perfectly valid code just stop working. The workaround is to convert everything to UNIX format, which is a bit tiresome given that my code is distributed on a bunch of computers... -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-06-22 12:56 Message: Logged In: YES user_id=89016 This is indead a duplicate of bug #1175396 and related ones. Your problem should be fixed in the current CVS version. Can you retry with the current CVS version? As a possible workaround you might want to change the encoding from cp-1252 to iso-8859-1. Does this fix anything for you? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1225059 ] Line endings problem with Python 2.4.1 cause imports to fail
Bugs item #1225059, was opened at 2005-06-21 20:56 Message generated for change (Comment added) made by nlehuen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Duplicate Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Walter Dörwald (doerwalter) Summary: Line endings problem with Python 2.4.1 cause imports to fail Initial Comment: Hi, Here is my Python version string : ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 I'm having troubles with a series of source code files that were working perfectly under Python 2.4.0 and earlier releases. I have enclosed one of those source files which should be independent of the rest, so that you can test it by yourself. Now, here is my problem : Test 1 --- C:\projets\development\python\tcc>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win3 Type "help", "copyright", "credits" or "license" for more information. >>> import util Traceback (most recent call last): File "", line 1, in ? File "util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : this is the problem, the Python interpreter fails to parse the file. Note that is is a DOS-style file, with \r\n as lines separator, instead of simply \n. If I convert the file to a UNIX-style, \n separated lines format, then everything is OK. Test 2 --- C:\projets\development\python\tcc>python -i util.py C:\projets\development\python\tcc>python -i util.py >>> ^Z --- interpretation : launching the script instead of importing it is OK. It seems that the way scripts are loaded for direct launching is different than the way they are loaded for import. Test 3 --- C:\projets\development\python\tcc>python -m util File "C:\projets\development\python\tcc\util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : using another way to import the module and launch it yield the same buggy behaviour. Once again, if I convert line termination from DOS to UNIX, everything is OK. I've seen a few bugs related to rstrip() and readline() having a new behaviour, maybe this problem is related ? This is quite an annoying bug, because some perfectly valid code just stop working. The workaround is to convert everything to UNIX format, which is a bit tiresome given that my code is distributed on a bunch of computers... -- >Comment By: Nicolas Lehuen (nlehuen) Date: 2005-06-22 14:14 Message: Logged In: YES user_id=61056 I have not enough time to test the CVS version right now, but if I change the encoding header from : # -*- coding: CP1252 -*- to : # -*- coding: iso-8859-1 -*- then everything is OK. So I guess this is really a duplicate of others bugs related to the CP1252 encoder ? Thanks for your reply ! -- Comment By: Walter Dörwald (doerwalter) Date: 2005-06-22 12:56 Message: Logged In: YES user_id=89016 This is indead a duplicate of bug #1175396 and related ones. Your problem should be fixed in the current CVS version. Can you retry with the current CVS version? As a possible workaround you might want to change the encoding from cp-1252 to iso-8859-1. Does this fix anything for you? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1225059 ] Line endings problem with Python 2.4.1 cause imports to fail
Bugs item #1225059, was opened at 2005-06-21 20:56 Message generated for change (Comment added) made by nlehuen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Duplicate Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Walter Dörwald (doerwalter) Summary: Line endings problem with Python 2.4.1 cause imports to fail Initial Comment: Hi, Here is my Python version string : ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 I'm having troubles with a series of source code files that were working perfectly under Python 2.4.0 and earlier releases. I have enclosed one of those source files which should be independent of the rest, so that you can test it by yourself. Now, here is my problem : Test 1 --- C:\projets\development\python\tcc>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win3 Type "help", "copyright", "credits" or "license" for more information. >>> import util Traceback (most recent call last): File "", line 1, in ? File "util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : this is the problem, the Python interpreter fails to parse the file. Note that is is a DOS-style file, with \r\n as lines separator, instead of simply \n. If I convert the file to a UNIX-style, \n separated lines format, then everything is OK. Test 2 --- C:\projets\development\python\tcc>python -i util.py C:\projets\development\python\tcc>python -i util.py >>> ^Z --- interpretation : launching the script instead of importing it is OK. It seems that the way scripts are loaded for direct launching is different than the way they are loaded for import. Test 3 --- C:\projets\development\python\tcc>python -m util File "C:\projets\development\python\tcc\util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : using another way to import the module and launch it yield the same buggy behaviour. Once again, if I convert line termination from DOS to UNIX, everything is OK. I've seen a few bugs related to rstrip() and readline() having a new behaviour, maybe this problem is related ? This is quite an annoying bug, because some perfectly valid code just stop working. The workaround is to convert everything to UNIX format, which is a bit tiresome given that my code is distributed on a bunch of computers... -- >Comment By: Nicolas Lehuen (nlehuen) Date: 2005-06-22 14:22 Message: Logged In: YES user_id=61056 Turns out testing the CVS version was not so lengthy... So yes, this is fixed in the current CVS version ! Regards, Nicolas -- Comment By: Nicolas Lehuen (nlehuen) Date: 2005-06-22 14:14 Message: Logged In: YES user_id=61056 I have not enough time to test the CVS version right now, but if I change the encoding header from : # -*- coding: CP1252 -*- to : # -*- coding: iso-8859-1 -*- then everything is OK. So I guess this is really a duplicate of others bugs related to the CP1252 encoder ? Thanks for your reply ! -- Comment By: Walter Dörwald (doerwalter) Date: 2005-06-22 12:56 Message: Logged In: YES user_id=89016 This is indead a duplicate of bug #1175396 and related ones. Your problem should be fixed in the current CVS version. Can you retry with the current CVS version? As a possible workaround you might want to change the encoding from cp-1252 to iso-8859-1. Does this fix anything for you? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1225059 ] Line endings problem with Python 2.4.1 cause imports to fail
Bugs item #1225059, was opened at 2005-06-21 20:56 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&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: Parser/Compiler Group: Python 2.4 >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Walter Dörwald (doerwalter) Summary: Line endings problem with Python 2.4.1 cause imports to fail Initial Comment: Hi, Here is my Python version string : ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 I'm having troubles with a series of source code files that were working perfectly under Python 2.4.0 and earlier releases. I have enclosed one of those source files which should be independent of the rest, so that you can test it by yourself. Now, here is my problem : Test 1 --- C:\projets\development\python\tcc>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win3 Type "help", "copyright", "credits" or "license" for more information. >>> import util Traceback (most recent call last): File "", line 1, in ? File "util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : this is the problem, the Python interpreter fails to parse the file. Note that is is a DOS-style file, with \r\n as lines separator, instead of simply \n. If I convert the file to a UNIX-style, \n separated lines format, then everything is OK. Test 2 --- C:\projets\development\python\tcc>python -i util.py C:\projets\development\python\tcc>python -i util.py >>> ^Z --- interpretation : launching the script instead of importing it is OK. It seems that the way scripts are loaded for direct launching is different than the way they are loaded for import. Test 3 --- C:\projets\development\python\tcc>python -m util File "C:\projets\development\python\tcc\util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : using another way to import the module and launch it yield the same buggy behaviour. Once again, if I convert line termination from DOS to UNIX, everything is OK. I've seen a few bugs related to rstrip() and readline() having a new behaviour, maybe this problem is related ? This is quite an annoying bug, because some perfectly valid code just stop working. The workaround is to convert everything to UNIX format, which is a bit tiresome given that my code is distributed on a bunch of computers... -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-06-22 14:22 Message: Logged In: YES user_id=89016 Closing the report. Thanks for the quick followup. -- Comment By: Nicolas Lehuen (nlehuen) Date: 2005-06-22 14:22 Message: Logged In: YES user_id=61056 Turns out testing the CVS version was not so lengthy... So yes, this is fixed in the current CVS version ! Regards, Nicolas -- Comment By: Nicolas Lehuen (nlehuen) Date: 2005-06-22 14:14 Message: Logged In: YES user_id=61056 I have not enough time to test the CVS version right now, but if I change the encoding header from : # -*- coding: CP1252 -*- to : # -*- coding: iso-8859-1 -*- then everything is OK. So I guess this is really a duplicate of others bugs related to the CP1252 encoder ? Thanks for your reply ! -- Comment By: Walter Dörwald (doerwalter) Date: 2005-06-22 12:56 Message: Logged In: YES user_id=89016 This is indead a duplicate of bug #1175396 and related ones. Your problem should be fixed in the current CVS version. Can you retry with the current CVS version? As a possible workaround you might want to change the encoding from cp-1252 to iso-8859-1. Does this fix anything for you? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1225584 ] crash in gcmodule.c on python reinitialization
Bugs item #1225584, was opened at 2005-06-22 16:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash in gcmodule.c on python reinitialization
Initial Comment:
i have a c++ windows application with embedded python
interpreter.
this code crashs:
Py_Initialize();
PyRun_SimpleString("import gc");
Py_Finalize();
Py_Initialize();
PyRun_SimpleString("import gc");// <--- BOOM
the problem seems to be the global var "garbage" in
gcmodule.c
the var isn't cleared in the reinitialization and
becomes an invalid pointer.
setting it to NULL in Py_Finalize fixes the crash.
i use python version 2.3.4 but a short look at the
2.4.1 source indicates that the problem is still there.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1225584 ] crash in gcmodule.c on python reinitialization
Bugs item #1225584, was opened at 2005-06-22 15:43
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash in gcmodule.c on python reinitialization
Initial Comment:
i have a c++ windows application with embedded python
interpreter.
this code crashs:
Py_Initialize();
PyRun_SimpleString("import gc");
Py_Finalize();
Py_Initialize();
PyRun_SimpleString("import gc");// <--- BOOM
the problem seems to be the global var "garbage" in
gcmodule.c
the var isn't cleared in the reinitialization and
becomes an invalid pointer.
setting it to NULL in Py_Finalize fixes the crash.
i use python version 2.3.4 but a short look at the
2.4.1 source indicates that the problem is still there.
--
>Comment By: Michael Hudson (mwh)
Date: 2005-06-22 16:59
Message:
Logged In: YES
user_id=6656
Bizarrely, I think this got fixed in CVS HEAD just a few days ago. Are you
in a position to check that?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1225705 ] os.environ documentation should mention unsetenv
Bugs item #1225705, was opened at 2005-06-22 11:09 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=1225705&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brian Wellington (bwelling) Assigned to: Nobody/Anonymous (nobody) Summary: os.environ documentation should mention unsetenv Initial Comment: The (current) documentation for os.environ says: --- If the platform supports the putenv() function, this mapping may be used to modify the environment as well as query the environment. putenv() will be called automatically when the mapping is modified. --- Some platforms (Solaris 8 and 9, at least) have putenv() but not unsetenv(), which means that setting environment variables by assigning values in os.environ works, but unsetting them by deleting from os.environ doesn't. This is confusing, and should at least be documented (if for no other reason than no one else should waste several hours figuring this out). This was tested with Python 2.4.1 and earlier versions. I'd suggest documenting os.unsetenv() in 6.1.1 (Process Parameters) of the manual, and modifying the above text to say something like: --- If the platform supports the putenv() and unsetenv() functions, this mapping may be used to modify the environment as well as query the environment. putenv() will be called automatically when an entry in the mapping is added or changed, and unsetenv() will be called automatically when an entry is deleted. --- -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225705&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224347 ] int/long unification and hex()
Bugs item #1224347, was opened at 2005-06-20 15:22
Message generated for change (Comment added) made by tjreedy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224347&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: int/long unification and hex()
Initial Comment:
There seems to be a bit of an inconsistancy with
int/long unification while using hex(). Specifically;
>>> hex(int(987259835))
'0x3ad863bb'
>>> hex(long(987259835))
'0x3AD863BBL'
I understand that longs will have the trailing 'L'
until Py3k, but I believe the capitalization should be
consistant. If consistancy is desired, I believe that
lowercase should be the standard, being that
string.encode('hex') also produces lowercase.
If the cases are supposed to be different, or making
the change would produce known backwards
incompatibility for some set of modules, feel free to
close this bug report.
--
>Comment By: Terry J. Reedy (tjreedy)
Date: 2005-06-22 14:10
Message:
Logged In: YES
user_id=593130
The trailing L is perhaps easier to see as not a digit if other
letters are lowercase: 0x3ad863bbL, versus above.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224347&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
