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

[Senthil Kumaran]

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 change and I did not see any
  references where people relied upon this behavior. (No bugs / usage
  cases)
- It is actually a bug, because one may not be sure if the ftp service
  is running the machine in the first place and user may not intend
  that ftp service be used for accessing local resources.

We had python-dev discussion on this sometime back when fixing another
bug and conclusion was that we raise a ValueError when file:// scheme
was used in non-local url. Instead of ValueError, I think the generic
URLError is okay too.

--

___
Python tracker 

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

[Matthew Woodcraft]

Changes by Matthew Woodcraft :


--
nosy: +mattheww

___
Python tracker 

___
___
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 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 -> pending

___
Python tracker 

___
___
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]

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

___
___
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]

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

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

[Andreas Stührk]

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

___
___
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]

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 Excel 
where the unary minus binds first.  See 
http://en.wikipedia.org/wiki/Order_of_operations#Examples

--
nosy: +rhettinger

___
Python tracker 

___
___
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]

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

___
___
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]

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.

--

___
Python tracker 

___
___
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]

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

___
___
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]

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

___
___
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]

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

___
___
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]

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

___
___
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]

R. David Murray  added the comment:

Does it also need a deprecation cycle?

--
nosy: +r.david.murray

___
Python tracker 

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

[anatoly techtonik]

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

___
___
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]

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

___
Python tracker 

___
___
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 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 Antoine's patch fix any
of the other issues mentioned here?

--

___
Python tracker 

___
___
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]

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.

--

___
Python tracker 

___
___
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]

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 core developers.

--

___
Python tracker 

___
___
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]

Antoine Pitrou  added the comment:

Backported to 2.7 in r85358.

--
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending

___
Python tracker 

___
___
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]

kiorky  added the comment:

We must not have the same point of view about new features and bugfixes...

--

___
Python tracker 

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

[Senthil Kumaran]

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

___
___
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]

Antoine Pitrou  added the comment:

Committed to 3.x in r85353.

--

___
Python tracker 

___
___
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 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 moderately against making changes in Python for dated systems.
Could you perhaps just copy the files from 5.0?

--
nosy: +skrah

___
Python tracker 

___
___
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]

Georg Brandl  added the comment:

Deferring once again.

--
priority: release blocker -> deferred blocker

___
Python tracker 

___
___
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]

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 

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

--

___
Python tracker 

___
___
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]

Antoine Pitrou  added the comment:

Patch committed in r85352, thanks.

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
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]

Akira Kitada  added the comment:

The patch does fix the build error.
Thank you!

--

___
Python tracker 

___
___
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]

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.2 (r85349), 2.7 (r85350) and even 3.1 
(r85351). Thank you!

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
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]

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

___
___
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]

Akira Kitada  added the comment:

It works fine with USE_SEMAPHORES commented out.

--

___
Python tracker 

___
___
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]

Antoine Pitrou  added the comment:

What happens if you comment out "#  define USE_SEMAPHORES" in 
Python/thread_pthread.h?

--
nosy: +pitrou

___
Python tracker 

___
___
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]

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

___
___
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]

Raymond Hettinger  added the comment:

Please pass the word along if you get a chance :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com