[issue10029] "Equivalent to" code for zip is wrong in Python 3

Raymond Hettinger added the comment: Please pass the word along if you get a chance :-) -- ___ Python tracker ___ ___ Python-bugs-lis

[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait

New submission from Akira Kitada : 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/threa

[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait

Antoine Pitrou added the comment: What happens if you comment out "# define USE_SEMAPHORES" in Python/thread_pthread.h? -- nosy: +pitrou ___ Python tracker ___ ___

[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait

Akira Kitada added the comment: It works fine with USE_SEMAPHORES commented out. -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait

Antoine Pitrou 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

[issue10054] select extension does not build on platforms where uintptr_t is provided in inttypes.h

Antoine Pitrou 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

[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait

Akira Kitada added the comment: The patch does fix the build error. Thank you! -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue10062] Python 3.2 does not build on systems which do not have sem_timedwait

Antoine Pitrou added the comment: Patch committed in r85352, thanks. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue9921] os.path.join('x','') behavior

Brian Brazil 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? -- ___

[issue8746] os.chflags() and os.lchflags() are not built when they should be be

Georg Brandl added the comment: This can be solved after 3.2a3. -- assignee: -> ronaldoussoren nosy: +georg.brandl, ronaldoussoren priority: release blocker -> deferred blocker ___ Python tracker _

[issue8611] Python3 doesn't support locale different than utf8 and an non-ASCII path (POSIX)

Georg Brandl added the comment: Deferring once again. -- priority: release blocker -> deferred blocker ___ Python tracker ___ ___ Pyth

[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 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

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Antoine Pitrou added the comment: Committed to 3.x in r85353. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10063] file:// scheme will stop accessing via ftp protocol

New submission from Senthil Kumaran : 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 machin

[issue1777412] Python's strftime dislikes years before 1900

kiorky added the comment: We must not have the same point of view about new features and bugfixes... -- ___ Python tracker ___ ___

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Antoine Pitrou added the comment: Backported to 2.7 in r85358. -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> pending ___ Python tracker ___ __

[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 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

[issue1777412] Python's strftime dislikes years before 1900

Martin v. Löwis 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. -- _

[issue9189] Improve CFLAGS handling

Stefan Krah 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 Antoin

[issue10059] add the method `index` to collections.deque

Simon Liedtke 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

[issue10064] link to page with documentation bugs

New submission from anatoly techtonik : 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 - pro

[issue10063] file:// scheme will stop accessing via ftp protocol

R. David Murray added the comment: Does it also need a deprecation cycle? -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

STINNER Victor 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, f

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Martin v. Löwis added the comment: Am 10.10.2010 17:51, schrieb STINNER Victor: > > STINNER Victor 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 t

[issue7980] time.strptime not thread safe

MunSic JEONG 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 m

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

STINNER Victor 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

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Martin v. Löwis 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. -

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Antoine Pitrou added the comment: Le dimanche 10 octobre 2010 à 18:23 +, Martin v. Löwis a écrit : > Martin v. Löwis 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 M

[issue10061] ** operator yielding wrong result for negative numbers

Raymond Hettinger 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

[issue10065] future_builtins' docstring lacks some functions

New submission from Andreas Stührk : 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

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Martin v. Löwis 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, a

[issue10008] Two links point to same place

Terry J. Reedy 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

[issue9948] findCaller is slow and loses case information on Windows

Vinay Sajip 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 -

[issue4106] multiprocessing occasionally spits out exception during shutdown

Changes by Matthew Woodcraft : -- nosy: +mattheww ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue10063] file:// scheme will stop accessing via ftp protocol

Senthil Kumaran added the comment: On Sun, Oct 10, 2010 at 03:49:42PM +, R. David Murray wrote: > Does it also need a deprecation cycle? I think, adding a deprecation cycle might just delay this change. So, I would prefer if we make it in the 3.2 itself. - This is not a user-facing API cha