[issue7285] multiprocessing module, example code error
Senthil Kumaran orsent...@gmail.com added the comment: Fixed in r85347 and r85348. -- nosy: +orsenthil resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7285 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10008] Two links point to same place
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Yes, but http://docs.python.org/genindex-Z.html ZipFile (class in zipfile), [1] still has same issue, no? [1] (and [2], [3], if exist) should suggest alternatives, but it doesn't now. I'll attach the patch to detect this kind of duplication. I you say, probably this happens when same directive appears in rst file. For example, .. module:: zipfile .. class:: ZipFile .. class:: ZipFile(file, mode='r', compression=ZIP_STORED, allowZip64=False) Maybe I should have posted this issue to Sphinx tracker. -- Added file: http://bugs.python.org/file19181/search_pydoc.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10029] Equivalent to code for zip is wrong in Python 3
Daniel Stutzbach dan...@stutzbachenterprises.com added the comment: Daniel, we need to sync-up on the meaning of marking a report as accepted. Traditionally it denotes an approved patch, not a agreement that the bug is valid. Woops! Thanks for the correction. For what it's worth, a quick search of issues with Resolution: accepted and Stage: needs patch suggests that Éric Araujo has perhaps been using the same misinterpretation as I have. I'm not sure if I got the behavior from him, if he got it from me, or if we both arrived there independently. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10052] Python/dtoa.c:158: #error Failed to find an exact-width 32-bit integer type (FreeBSD 4.11 + gcc 2.95.4)
Akira Kitada akit...@gmail.com added the comment: Forgot to mention that there's no _MAX macro for exact-width integer types. $ egrep -r 'INT[0-9].*_MAX' /usr/include/ | wc -l 0 How about adding those macros when the system does not provide them? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10061] ** operator yielding wrong result for negative numbers
New submission from eswar s eswar...@yahoo.com: -5 ** 4 results as -625. It should be 625 -- components: None messages: 118311 nosy: eswar.s priority: normal severity: normal status: open title: ** operator yielding wrong result for negative numbers type: compile error versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10008] Two links point to same place
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Umm, I tried, but I couldn't post new issue with error. I believe Sphinx guys also look at this tracker. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10061] ** operator yielding wrong result for negative numbers
Senthil Kumaran orsent...@gmail.com added the comment: It's to do with operator precedence. ** takes higher precedence than negative. http://docs.python.org/reference/expressions.html#Summary (-5) ** 4 will give what you are looking for. -- nosy: +orsenthil resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10054] select extension does not build on platforms where uintptr_t is provided in inttypes.h
Changes by Ned Deily n...@acm.org: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10054 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10029] Equivalent to code for zip is wrong in Python 3
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Please pass the word along if you get a chance :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait
New submission from Akira Kitada akit...@gmail.com: Build fails on FreeBSD 4 due to the lack of sem_timedwait. gcc -pthread -Wl,--export-dynamic -o python Modules/python.o libpython3.2.a -lutil -lm libpython3.2.a(thread.o): In function `PyThread_acquire_lock_timed': /home/akitada/src/py3k/Python/thread_pthread.h:315: undefined reference to `sem_timedwait' gmake: *** [python] Error 1 -- components: Build messages: 118315 nosy: akitada priority: normal severity: normal status: open title: Python 3.2 does not build on systems which do not have sem_timedwait type: compile error versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait
Antoine Pitrou pit...@free.fr added the comment: What happens if you comment out # define USE_SEMAPHORES in Python/thread_pthread.h? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait
Akira Kitada akit...@gmail.com added the comment: It works fine with USE_SEMAPHORES commented out. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait
Antoine Pitrou pit...@free.fr added the comment: What about this patch? Index: Python/thread_pthread.h === --- Python/thread_pthread.h (révision 85348) +++ Python/thread_pthread.h (copie de travail) @@ -64,7 +64,8 @@ /* Whether or not to use semaphores directly rather than emulating them with * mutexes and condition variables: */ -#if defined(_POSIX_SEMAPHORES) !defined(HAVE_BROKEN_POSIX_SEMAPHORES) +#if (defined(_POSIX_SEMAPHORES) !defined(HAVE_BROKEN_POSIX_SEMAPHORES) \ + defined(HAVE_SEM_TIMEDWAIT)) # define USE_SEMAPHORES #else # undef USE_SEMAPHORES -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10054] select extension does not build on platforms where uintptr_t is provided in inttypes.h
Antoine Pitrou pit...@free.fr added the comment: 3.1 branch does not have this problem because that patch was not applied to release31-maint. Is this intentional? I don't remember, I suppose it feared it could be an incompatible change or perhaps cause build problems. Anyway, I committed your patch in 3.2 (r85349), 2.7 (r85350) and even 3.1 (r85351). Thank you! -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10054 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait
Akira Kitada akit...@gmail.com added the comment: The patch does fix the build error. Thank you! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait
Antoine Pitrou pit...@free.fr added the comment: Patch committed in r85352, thanks. -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9921] os.path.join('x','') behavior
Brian Brazil brian.bra...@gmail.com added the comment:
That doesn't cover the os.path.join('', 'x') case, and I'm not sure it makes
os.path.join('x//', 'y') clear - though that doesn't matter as much.
How about making (2) the result is simply path2 when path1 is empty or path2
is an absolute path?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9921
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] os.chflags() and os.lchflags() are not built when they should be be
Georg Brandl ge...@python.org added the comment: This can be solved after 3.2a3. -- assignee: - ronaldoussoren nosy: +georg.brandl, ronaldoussoren priority: release blocker - deferred blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8746 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8611] Python3 doesn't support locale different than utf8 and an non-ASCII path (POSIX)
Georg Brandl ge...@python.org added the comment: Deferring once again. -- priority: release blocker - deferred blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10052] Python/dtoa.c:158: #error Failed to find an exact-width 32-bit integer type (FreeBSD 4.11 + gcc 2.95.4)
Stefan Krah stefan-use...@bytereef.org added the comment: FreeBSD 5.0 has stdint.h, which includes machine/_stdint.h. In the latter file the *_MAX constants are defined. It looks like FreeBSD has had the correct setup for more than 7 years: http://svn.freebsd.org/viewvc/base/release/5.0.0/sys/i386/include/ I would be moderately against making changes in Python for dated systems. Could you perhaps just copy the files from 5.0? -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9437] can't build extensions with non-default ldflags (e.g. -m32)
Antoine Pitrou pit...@free.fr added the comment: Committed to 3.x in r85353. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9437 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10063] file:// scheme will stop accessing via ftp protocol
New submission from Senthil Kumaran orsent...@gmail.com: file:// scheme should not be allowed to access a file on remote machines. RFC 1738, says that host, if present should be the FQDN of the machine, but relaxing on that I thinking that localhost and its variants should okay as long as it is the local machine. What is going to break in 3.2 is file:// trying to access resources on remote machine via FTP, which it is currently trying to do. Attached is patch to accomplish this.(NEWS and Docs will be added). This would introduce a regression, so this may not be backported. -- assignee: orsenthil components: Library (Lib) files: file_scheme.diff keywords: patch messages: 118327 nosy: orsenthil priority: normal severity: normal stage: patch review status: open title: file:// scheme will stop accessing via ftp protocol type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file19182/file_scheme.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777412] Python's strftime dislikes years before 1900
kiorky kio...@cryptelium.net added the comment: We must not have the same point of view about new features and bugfixes... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1777412 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9437] can't build extensions with non-default ldflags (e.g. -m32)
Antoine Pitrou pit...@free.fr added the comment: Backported to 2.7 in r85358. -- resolution: - fixed stage: needs patch - committed/rejected status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9437 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10052] Python/dtoa.c:158: #error Failed to find an exact-width 32-bit integer type (FreeBSD 4.11 + gcc 2.95.4)
Akira Kitada akit...@gmail.com added the comment: I understand FreeBSD 4.x is old platform (4.11, the last 4.x series, is released 5 years ago) but, in my opinion, as long as it does not make Python code cluttered, supporting old platforms is not that bad idea. Anyway, I would like to leave the decision to the core developers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777412] Python's strftime dislikes years before 1900
Martin v. Löwis mar...@v.loewis.de added the comment: kiorky: see my msg55157. Python behaves correctly as it stands - raising the exception is fully intentional. It's not a bug that it gets raised; dates before 1900 are just not supported. Adding support for them is a new feature. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1777412 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9189] Improve CFLAGS handling
Stefan Krah stefan-use...@bytereef.org added the comment: r85358 fixes the failures in test_sysconfig. The duplicate LDFLAGS are still present, but if it is generally accepted that make-LDFLAGS should be appended to configure-LDFLAGS, then I don't see any way around that. As for me, this could be closed again. Did Antoine's patch fix any of the other issues mentioned here? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10059] add the method `index` to collections.deque
Simon Liedtke liedtke.si...@googlemail.com added the comment: I see that adding this method to a deque is useless. A list is better for this kind of operation. I just wrote it for fun and realized that it was implemented rather slow. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10059 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10064] link to page with documentation bugs
New submission from anatoly techtonik techto...@gmail.com: Link to bugtracker on http://docs.python.org/dev/bugs.html leads to main roundup page. It make more sense to redirect to a page that lists only documentation bugs. Extra points: - sort the landing page that Easy, then issues with Patches come first - provide a link to Documentation HOWTO from an issue page -- assignee: d...@python components: Documentation messages: 118334 nosy: d...@python, techtonik priority: normal severity: normal status: open title: link to page with documentation bugs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10063] file:// scheme will stop accessing via ftp protocol
R. David Murray rdmur...@bitdance.com added the comment: Does it also need a deprecation cycle? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
STINNER Victor victor.stin...@haypocalc.com added the comment: We run into problems because we have two inconsistent encodings, ... What? No. We have problems because we don't use the same encoding to decode and to encode the same data type. It's not a problem to use a different encoding for each data type (stdout, filenames, environment variables, ...). -- About the 3rd encoding: it will be just the locale encoding. Use the locale encoding to encode/decode command line arguments and environment variables is complelty compatible with Python 3.1, because Python 3.1 initializes the filesystem encoding with the locale encoding. Use the locale encoding helps the interoperability because other programs use the same encoding. Mac OS X is a special case. Filesystem encoding is utf-8 on this OS, whereas the locale encoding depends on LANG variable. If I understood MvL proposition correctly, we should not rely on the locale on Mac OS X. So the 3rd encoding and the filesystem encodings should be hardcoded to utf-8? -- The third encoding is no more controlable by a special environment variable, only by classic locale environment variables (LC_ALL, LC_CTYPE, LANG). Is it a problem? I remember a comment from MAL saying that it may be a problem for CGI for the environment variables because some (all?) variables are not encoded with the locale encoding (but the HTML encoding?). I don't know if Python should workaround CGI specific issues. In Python 3.2, we have now os.environb: it's now possible to use a different encoding for each variable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: Am 10.10.2010 17:51, schrieb STINNER Victor: STINNER Victor victor.stin...@haypocalc.com added the comment: We run into problems because we have two inconsistent encodings, ... What? No. We have problems because we don't use the same encoding to decode and to encode the same data type. It's not a problem to use a different encoding for each data type (stdout, filenames, environment variables, ...). This is exactly the very problem that we face. In particular, the question is what encoding to use if something is *both* a filename and an environment variable value, or both a filename and a command line argument. Mac OS X is a special case. Filesystem encoding is utf-8 on this OS, whereas the locale encoding depends on LANG variable. If I understood MvL proposition correctly, we should not rely on the locale on Mac OS X. Not rely on is perhaps a bit harsh. It's not clear (to me) under what conditions the locale's encoding will be more correct than just assuming UTF-8 - there may actually be use cases for it. However, with the surrogate escapes, we could just always decode using UTF-8, and leave any mojibake problems that may arise from this from this to the application. I do think that these problems will be rare, since a) many OSX installations use UTF-8, anyway, and b) those that don't likely experience the proper round-tripping of the escape mechanism. So the 3rd encoding and the filesystem encodings should be hardcoded to utf-8? That's an option to consider, yes - I'd like an OSX expert to comment. The third encoding is no more controlable by a special environment variable, only by classic locale environment variables (LC_ALL, LC_CTYPE, LANG). Is it a problem? I remember a comment from MAL saying that it may be a problem for CGI for the environment variables because some (all?) variables are not encoded with the locale encoding (but the HTML encoding?). I don't know if Python should workaround CGI specific issues. In Python 3.2, we have now os.environb: it's now possible to use a different encoding for each variable. I think these problems are sufficiently resolved now: either by PEP , PEP 444, PEP 383, or os.environb. I think you misunderstood MAL's comment, though: the environment variables are not encoded in *any* specific encoding. Instead, they are copied literally from the HTTP request, using whatever bytes the browser originally put in there - which may or may not have followed a particular encoding. HTTP is silent on this most of the time, and HTML is out of scope. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7980] time.strptime not thread safe
MunSic JEONG rus...@gmail.com added the comment:
Do you have a patch to fix the issue?
no, I don't. I just wanted to move stage from unittest needed to needs
patch :)
After reading issue8098, now I realized that this is broad issue as belopolsky
said in msg110095.
For new reader of this issue after me, I would like to share my understanding.
Patch like below can solve this ticket. (changing ImportModuleNoBlock call to
ImportNoBlock)
static PyObject *
time_strptime(PyObject *self, PyObject *args)
{
-PyObject *strptime_module = PyImport_ImportModuleNoBlock(_strptime);
+PyObject *strptime_module = PyImport_ImportModule(_strptime);
But the function PyImport_ImportModuleNoBlock() was introduced and used in
modules such as the time module to supposedly avoid deadlocks when using
threads.
So we could not apply that patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7980
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
STINNER Victor victor.stin...@haypocalc.com added the comment: What? No. We have problems because we don't use the same encoding to decode and to encode the same data type. It's not a problem to use a different encoding for each data type (stdout, filenames, environment variables, ...). This is exactly the very problem that we face. In particular, the question is what encoding to use if something is *both* a filename and an environment variable value, or both a filename and a command line argument. The question is: what is the best default encoding for a specific data type? There is no perfect answer (well, except maybe using byte strings :-)). Each solution has its own use cases and disadvantages. If an application knows exactly the encoding of a data, and it is not the default encoding, it can still redecode the data. Using os.environb, it's a little bit better: the application just has to decode (don't have to encode and to know which encoding was used to decode initially the data). For sys.argv, I still want to create sys.argvb (bytes version) ;-) For the command line arguments and environment variables, we don't have a lot of choices: locale or filesystem encodings. So Antoine and Martin: which encoding do you prefer? We should maybe try to find some use cases Here is a dummy script bla.py: --- import sys print(sys.argv) try: open(sys.argv[1]).close() except Exception as err: print(open error: %s % err) else: print(open ok) --- Locale encoding = FS encoding = utf-8: $ ./python bla.py xxxé.txt ['bla.py', 'xxxé.txt'] open ok Locale encoding = utf8, FS encoding = ascii: $ PYTHONFSENCODING=ascii ./python bla.py xxxé.txt ['bla.py', 'xxxé.txt'] open error: 'ascii' codec can't encode character '\xe9' ... The filename is displayed correctly, but we are unable to open the file if PYTHONFSENCODING is used :-/ Should the filename be displayed differently if PYTHONFSENCODING is used? I think these problems are sufficiently resolved now: either by PEP , PEP 444, PEP 383, or os.environb. Ok, cool :-) I think you misunderstood MAL's comment, though: the environment variables are not encoded in *any* specific encoding. Instead, they are copied literally from the HTTP request, using whatever bytes the browser originally put in there - which may or may not have followed a particular encoding. HTTP is silent on this most of the time, and HTML is out of scope. Ah yes, thanks for you explaination. I was unable to find its comment. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: For the command line arguments and environment variables, we don't have a lot of choices: locale or filesystem encodings. So Antoine and Martin: which encoding do you prefer? I still propose to drop the fsname encoding. Then this question goes away. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Antoine Pitrou pit...@free.fr added the comment: Le dimanche 10 octobre 2010 à 18:23 +, Martin v. Löwis a écrit : Martin v. Löwis mar...@v.loewis.de added the comment: For the command line arguments and environment variables, we don't have a lot of choices: locale or filesystem encodings. So Antoine and Martin: which encoding do you prefer? I still propose to drop the fsname encoding. Then this question goes away. I don't know what you mean by dropping, since OS X by construction needs a filesystem encoding (utf-8) different from the locale encoding; and Windows hardwires the decoding/encoding of bytes filenames using mbcs regardless of the current codepage, IIRC. So do you just mean the filesystem encoding should be hidden from the user? What would be the benefit? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10061] ** operator yielding wrong result for negative numbers
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Python's order of operations runs the exponentation before the unary minus. This convention makes the unary minus behave more like the subtraction operator so that: -x**n == 0 - x**n. This convention is somewhat common but there are exceptions such as MS Excel where the unary minus binds first. See http://en.wikipedia.org/wiki/Order_of_operations#Examples -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10065] future_builtins' docstring lacks some functions
New submission from Andreas Stührk andy-pyt...@hammerhartes.de: Title says all, attached is a patch against release27-maint that adds them. -- assignee: d...@python components: Documentation files: future_builtins_docstring.patch keywords: patch messages: 118343 nosy: Trundle, d...@python priority: normal severity: normal status: open title: future_builtins' docstring lacks some functions versions: Python 2.7 Added file: http://bugs.python.org/file19183/future_builtins_docstring.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10065 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: I don't know what you mean by dropping, since OS X by construction needs a filesystem encoding (utf-8) different from the locale encoding; See above. I propose to stop using the locale encoding for command line arguments and environment variables on OSX, and use UTF-8 instead. and Windows hardwires the decoding/encoding of bytes filenames using mbcs regardless of the current codepage, IIRC. I wish byte-oriented file names could be dropped on Windows. But that is probably too incompatible. So do you just mean the filesystem encoding should be hidden from the user? What would be the benefit? That the very issue that this bug report (re-read the title) is about would go away. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10008] Two links point to same place
Terry J. Reedy tjre...@udel.edu added the comment: When I initially wrote I have no idea what ', [1]' is supposed to mean. , you should have believed that and explained ;-). I now understand that most index entries have one link, which we might call the [0] link. When the entry should have more than one link, the index entry text is followed by '[1]' and, if needed, '[2]', '[3]', and so on. These place-holder labels should each have different links, or should not be there at all. So ZipFile (class in zipfile and [1] are two separate texts that should have two different links, but the two links are the same, and that, I agree, is wrong. Another example with duplicate links: tracer() (in module turtle), [1] 3.1.2 and 3.2a2 indexes have Zipfile error but not tracer error (because '[1]' is not present). Doc people: the attached patch is a diagnostic patch rather than a fixup patch. I do not know whether the problem is in .rst sources or Sphinx. -- assignee: d...@python - keywords: +patch nosy: +georg.brandl stage: - needs patch type: - behavior versions: +Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9948] findCaller is slow and loses case information on Windows
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Partial fix checked into py3k and release27-maint branches (for losing filename case information) - r85361. Regarding performance changes - awaiting feedback from Armin re. my performance measurements showing only marginal differences. -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4106] multiprocessing occasionally spits out exception during shutdown
Changes by Matthew Woodcraft matt...@woodcraft.me.uk: -- nosy: +mattheww ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4106 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
