[issue874900] threading module can deadlock after fork

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

If you remove the print() call from joining_func(), does it stop
hanging? It may be due to differences between the io library in py3k and
the builtin file objects in 2.x.
(looking at the date of the commit disabling the test, it is not related
to the thread-safety changes to BufferedWriter, though)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3132] implement PEP 3118 struct changes

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Let's retarget it to 3.1 then. It's a new feature, not a behaviour
change or a deprecation, so adding it to 3.0 isn't a necessity.

--
components: +Library (Lib)
nosy: +pitrou
priority: release blocker -> critical
versions: +Python 3.1 -Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2982] more tests for pyexpat

[Maciek Fijalkowski]

Maciek Fijalkowski <[EMAIL PROTECTED]> added the comment:

Next wave of tests - error handling. More specifically all errors that
might happen during parsing XML and reported by parser itself.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3586] pwd.getpwnam('nobody') produces incorrect results if sizeof(uid_t) < sizeof(long)

[Mark Dickinson]

New submission from Mark Dickinson <[EMAIL PROTECTED]>:

On a 64-bit OS X build of Python, built with:

./configure --with-universal-archs=64-bit --enable-universalsdk=/ 
MACOSX_DEPLOYMENT_TARGET=10.5 && 
make

I get the following result:

Python 2.6b2+ (trunk:65805M, Aug 18 2008, 10:59:08) 
[GCC 4.0.1 (Apple Inc. build 5484)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam('nobody')
pwd.struct_passwd(pw_name='nobody', pw_passwd='*', pw_uid=4294967294, 
pw_gid=4294967294, 
pw_gecos='Unprivileged User', pw_dir='/var/empty', pw_shell='/usr/bin/false')

Here the pw_uid and pw_gid should presumably be -2, not 4294967294.  I haven't 
had time to 
investigate properly, but the problem is almost certainly something to do with 
the fact that 
sizeof(uid_t) is 4 and sizeof(long) is 8 for this build.  (Though 
interestingly, the configure 
script detects sizeof(long) as 4, which may not be helping matters.)

This problem is causing test_httpservers to fail on 64-bit OS X.

System info: it's a MacBook Pro;  uname -a gives:
Darwin Macintosh-3.local 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun  9 19:30:53 
PDT 2008; root:xnu-
1228.5.20~1/RELEASE_I386 i386

--
components: Extension Modules
messages: 71318
nosy: marketdickinson
severity: normal
status: open
title: pwd.getpwnam('nobody') produces incorrect results if sizeof(uid_t) < 
sizeof(long)
versions: Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2982] more tests for pyexpat

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


--
nosy: +pitrou
priority:  -> normal
versions: +Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Are many people using OpenDNS? Is there a way to detect that OpenDNS is
being used and trigger a separate path in the test?
I say that because returning a 404 when the domain lookup has failed is
wrong. Perhaps the test should check for a 404 and still raise an
exception, but with an appropriate message indicating that it may be due
to a "featureful" DNS service.

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3586] pwd.getpwnam('nobody') produces incorrect results if sizeof(uid_t) < sizeof(long)

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

It turns out that uid_t (and gid_t) actually *is* an unsigned 32-bit 
integer type on OS X 10.5, so perhaps the pw_uid and pw_gid values are 
correct.  So to rephrase: one or both of the following facts might be 
considered bugs:

(1) On a single machine, the value of pwd.getpwnam('nobody') gives 
different results for 32-bit and 64-bit builds of Python (pw_uid is -2 on 
32-bit, 2**32-2 on 64-bit).

(2) On a 64-bit OS X build, pwd.getpwnam can produce uids and gids >= 
2**31, but os.setuid and friends don't accept values larger than 2**31-1.
There's an inconsistency between pwdmodule.c and posixmodule.c:  pwdmodule 
casts uids to C longs before returning them, while the posixmodule.c 
functions parse an input uid/gid using the "i" format in PyArg_Parse*.

It's the latter problem that's causing test_httpservers to fail on 64-bit 
OS X.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3585] pkg-config support

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

I cannot discuss about the feature itself, but the patch should
certainly use some macro ($(VERSION) ?) instead of the hardcoded "2.6".
Likewise, source files should not contain version number in their names,
or they cannot be merged between branches.

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2271] msi installs to the incorrect location (C drive)

[Andrew Dalke]

Andrew Dalke <[EMAIL PROTECTED]> added the comment:

Yes, that installed Python 2.6 into the correct location (C:\Python26 
instead of into the root directory).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3587] Bad parsing of compiling regex with re.MULTILINE

[Misha Seltzer]

New submission from Misha Seltzer <[EMAIL PROTECTED]>:

import re
regex = r"[\w]+"

# Normal behaviour:
>>> re.findall(regex, "hello world", re.M)
['hello', 'world']
>>> re.compile(regex).findall("hello world")
['hello', 'world']

# Bug behaviour:
>>> re.compile(regex).findall("hello world", re.M)
['rld']

--
components: Regular Expressions
messages: 71323
nosy: misha
severity: normal
status: open
title: Bad parsing of compiling regex with re.MULTILINE
type: behavior
versions: Python 2.4, Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3588] sysconfig variable LINKFORSHARED has wrong value for MacOS X framework build

[Konrad Hinsen]

New submission from Konrad Hinsen <[EMAIL PROTECTED]>:

On a MacOS X framework build, the LINKFORSHARED variable obtained from 
distutils.sysconfig.get_config_vars() has the value

  -u _PyMac_Error Python.framework/Versions/2.5/Python

The last item is incomplete, it needs to be prefixed with the path in 
which the Python framework is installed.

Looking at config/Makefile (from which Distutils takes the variables), I 
find

LINKFORSHARED=  -u _PyMac_Error 
$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)

and

PYTHONFRAMEWORKDIR= Python.framework

One fix would be to use PYTHONFRAMEWORKINSTALLDIR instead of PYTHONFRAMEWORKDIR 
in the definition of LINKFORSHARED, but I don't know 
if this could have undesirable effects on the build process.

--
components: Distutils
messages: 71324
nosy: khinsen
severity: normal
status: open
title: sysconfig variable LINKFORSHARED has wrong value for MacOS X framework 
build
type: behavior
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

numbers.Number change forward ported to Py3k in r65808

Docs updated for 2.6 and 3.0 in r65810 and r65811 respectively.

Which means I can finally close this one :)

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3587] Bad parsing of compiling regex with re.MULTILINE

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

The re.M flag is an attribute of the compiled pattern, and as such it
must be passed to compile(), not to findall(). 

These all work:

>>> re.compile(r"[a-z]+").findall("hello world")
['hello', 'world']
>>> re.compile(r"[a-z]+", re.M).findall("hello world")
['hello', 'world']
>>> re.compile(r"(?m)[a-z]+").findall("hello world")
['hello', 'world']

The second argument to the findall() method of compile objects is the
start position to match from (see
http://docs.python.org/lib/re-objects.html). This explains the behaviour
you are witnessing:

>>> re.M
8
>>> re.compile(r"[a-z]+").findall("hello world", 8)
['rld']

--
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3589] Misleading names for multiprocessing "convenience" functions

[Nick Coghlan]

New submission from Nick Coghlan <[EMAIL PROTECTED]>:

The package level imports from the new multiprocessing package exhibit
some very strange behaviour because they are actually functions
pretending to be classes:

Python 2.6b1+ (trunk:64945, Jul 14 2008, 20:00:46)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing as mp
>>> isinstance(mp.Lock(), mp.Lock)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes
and types
>>> mp.Lock.__name__
'Lock'
>>> mp.Lock.__module__
'multiprocessing'
>>> mp.Lock().__class__.__name__
'Lock'
>>> mp.Lock().__class__.__module__
'multiprocessing.synchronize'

The delayed import functions in multiprocessing.__init__ look like a
serious misfeature to me. I'd be inclined to replace them with "from
.synchronize import *" and "from .process import *" (leaving anything
which isn't covered by those two imports to be retrieved directly from
the relevant mp submodule)

--
assignee: jnoller
components: Library (Lib)
messages: 71327
nosy: jnoller, ncoghlan
priority: critical
severity: normal
status: open
title: Misleading names for multiprocessing "convenience" functions
versions: Python 2.6, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3589] Misleading names for multiprocessing "convenience" functions

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

Setting to deferred blocker, since this really needs to be dealt with
for RC1 (probably too close to b3 to get it discussed and dealt with for
that).

--
priority: critical -> deferred blocker

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3352] Deficiencies in multiprocessing/threading API

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

I created issue 3589 to cover the problem I mentioned above with the
very misleading names for the package level functions in multiprocessing.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3494] "[Errno 11] Resource temporarily unavailable" while using tracing facility/threads (in linux listdir with unicode path)

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

I do not reproduce the problem, but in your example, the trace function
is called only when the script has finished, i.e during interpreter
shutdown. Creating a thread from there is not recommended...

Can you provide the complete traceback of your error?

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3496] distutils fails with mingw binutils 2.18.50.20080109

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:


--
assignee:  -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3580] failures in test_os

[Raghuram Devarakonda]

Raghuram Devarakonda <[EMAIL PROTECTED]> added the comment:

> The other failure is trivial, I've fixed it in r65780.

#1709112 has been reported earlier in relation to pagefile.sys. Your
patch addresses at least part of the problem there. I wonder if that
issue can be closed.

--
nosy: +draghuram

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3580] failures in test_os

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

According to the aforementioned bug report, we should also add a test
for e.winerror == 5. Chances are that other cases will arise one day or
another...

Since the purpose of the test is, allegedly, to "Verify that an open
file can be stat'ed", it may be simpler to create and open a file
ourselves (test_support.TESTFN being an obvious candidate :-)), and
check that it can be stat'ed. Expecting to be able to access
C:\pagefile.sys sounds as "right" as doing the same with, say,
/etc/passwd under Linux.

(and, incidentally, creating the file ourselves means the test will stop
being Windows-specific)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

Hi,

Sorry to bump this, but you (Guido) said you wanted this closed by
Wednesday. Is this patch committable yet? (There are no more unresolved
issues that I am aware of).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3589] Misleading names for multiprocessing "convenience" functions

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

> The delayed import functions in multiprocessing.__init__ look like a
> serious misfeature to me. I'd be inclined to replace them with "from
> .synchronize import *" and "from .process import *"

+1
(or, even better, qualified than wildcard imports)

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3580] failures in test_os

[Raghuram Devarakonda]

Raghuram Devarakonda <[EMAIL PROTECTED]> added the comment:

On Mon, Aug 18, 2008 at 10:28 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Since the purpose of the test is, allegedly, to "Verify that an open
> file can be stat'ed", it may be simpler to create and open a file
> ourselves (test_support.TESTFN being an obvious candidate :-)), and

No. Any open file does not do. There has been a discussion on
python-dev some time back about replacing the use of pagefile.sys with
a temporarily created open file. But the problem that spawned this
test case does not occur with just any open file.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2384] [Py3k] line number is wrong after encoding declaration

[Jean-Michel Fauth]

Jean-Michel Fauth <[EMAIL PROTECTED]> added the comment:

Py3.0b2. This bug seems to be quite annoying. Especially when one works
with a main module importing modules which are importing modules and so
on, all modules having an encoding declaration. The Traceback (and the
user) is (are) a little bit lost.

-
# -*- coding: cp1252 -*-
# modb.py

def fb():
i = 1
j = 0
r =  i / j
---
# -*- coding: cp1252 -*-
# moda.py

import modb

def fa():
modb.fb()
---
# -*- coding: cp1252 -*-
# main.py

import moda

def main():
moda.fa()

if __name__ == '__main__':
main()
---

Running main.py leads to an

>c:\python30\pythonw -u "main.py"
(Traceback (most recent call last):
  File "main.py", line 11, in 

  File "main.py", line 8, in main

  File "C:\jm\jmpy3\moda.py", line 8, in fa

  File "C:\jm\jmpy3\modb.py", line 8, in fb

ZeroDivisionError: int division or modulo by zero
>Exit code: 1

--
nosy: +jmfauth

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3496] distutils fails with mingw binutils 2.18.50.20080109

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Amaury, if you are going to look at this you might want to see #2234.

--
nosy: +benjamin.peterson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3132] implement PEP 3118 struct changes

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Actually, this may be a requirement of #2394; PEP 3118 states that
memoryview.tolist would use the struct module to do the unpacking.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser hangs on byte streams

[Edward K Ream]

New submission from Edward K Ream <[EMAIL PROTECTED]>:

While porting Leo to Python 3.0, I found that passing any byte stream to
xml.sax.parser.parse will hang the parser.  My quick fix was to change:

while buffer != "":

to:

while buffer != "" and buffer != b"":

at line 123 of xmlreader.py

Here is the entire function:

def parse(self, source):
from . import saxutils
source = saxutils.prepare_input_source(source)

self.prepareParser(source)
file = source.getByteStream()
buffer = file.read(self._bufsize)
### while buffer != "":
while buffer != "" and buffer != b"": ### EKR
self.feed(buffer)
buffer = file.read(self._bufsize)
self.close()

For reference, here is the code in Leo that was hanging::

  parser = xml.sax.make_parser()
  parser.setFeature(xml.sax.handler.feature_external_ges,1)
  handler = saxContentHandler(c,inputFileName,silent,inClipboard)
  parser.setContentHandler(handler)
  parser.parse(theFile)

Looking at the test_expat_file function in test_sax.py, it appears that
the essential difference between the code that hangs and the successful
unit test is that that Leo opens the file in 'rb' mode. (code not shown)
It's doubtful that 'rb' mode is correct--from the unit test I deduce
that the default 'r' mode would be better.  Anyway, it would be nice if
parser.parse didn't hang on dubious streams.

HTH.

Edward

--
components: Library (Lib)
messages: 71339
nosy: edreamleo
severity: normal
status: open
title: sax.parser hangs on byte streams
type: behavior
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser hangs on byte streams

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

It should probably be changed to just while buffer != b"" since it
requests a byte stream.

--
nosy: +benjamin.peterson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser hangs on byte streams

[Edward K Ream]

Edward K Ream <[EMAIL PROTECTED]> added the comment:

On Mon, Aug 18, 2008 at 10:09 AM, Benjamin Peterson
<[EMAIL PROTECTED]>wrote:

>
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> It should probably be changed to just while buffer != b"" since it
> requests a byte stream.

That was my guess as well.  I added the extra test so as not to remove a
test that might, under some circumstance be important.

Just to be clear, I am at present totally confused about io streams :-)
Especially as used by the sax parsers.  In particular, opening a file in 'r'
mode, that is, passing a *non*-byte stream to parser.parse, works, while
opening a file in 'rb' mode, that is, passing a *byte* stream to
parser.parse, hangs.

Anyway, opening the file passed to parser.parse with 'r' mode looks like the
(only) way to go when using Python 3.0.  In Python 2.5, opening files passed
to parser.parse in 'rb' mode works.  I don't recall whether I had any reason
for 'rb' mode: it may have been an historical accident, or just a lucky
accident :-)

Edward

Edward K. Ream email: [EMAIL PROTECTED]
Leo: http://webpages.charter.net/edreamleo/front.html


Added file: http://bugs.python.org/file11145/unnamed

___
Python tracker <[EMAIL PROTECTED]>

___On Mon, Aug 18, 2008 at 10:09 AM, Benjamin Peterson [EMAIL 
PROTECTED]> wrote:

Benjamin Peterson [EMAIL 
PROTECTED]> added the comment:

It should probably be changed to just while buffer != b"" since it
requests a byte stream.That was my guess as well.  I 
added the extra test so as not to remove a test that might, under some 
circumstance be important.Just to be clear, I am at present totally 
confused about io streams :-)  Especially as used by the sax 
parsers.  In particular, opening a file in 'r' mode, that is, 
passing a *non*-byte stream to parser.parse, works, while opening a file in 
'rb' mode, that is, passing a *byte* stream to parser.parse, hangs.
Anyway, opening the file passed to parser.parse with 'r' mode looks 
like the (only) way to go when using Python 3.0.  In Python 2.5, opening 
files passed to parser.parse in 'rb' mode works.  I don't 
recall whether I had any reason for 'rb' mode: it may have been an 
historical accident, or just a lucky accident :-)
EdwardEdward
 K. Ream email: mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]Leo: http://webpages.charter.net/edreamleo/front.html";>http://webpages.charter.net/edreamleo/front.html


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

[issue3132] implement PEP 3118 struct changes

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

> Actually, this may be a requirement of #2394; PEP 3118 states that
> memoryview.tolist would use the struct module to do the unpacking.

:-(
However, we don't have any examples of the buffer API / memoryview
object working with something else than 1-dimensional contiguous char
arrays (e.g. bytearray). Therefore, I suggest that Python 3.0 provide
official support only for 1-dimensional contiguous char arrays. Then
tolist() will be easy to implement even without using the struct module
(just a list of integers, if I understand the functionality).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3578] 'dictionary changed size' error in test_multiprocessing

[Ismail Donmez]

Ismail Donmez <[EMAIL PROTECTED]> added the comment:

I don't know if this is reproducible in 2.6 but I can reproduce on py3k 
branch, and also thanks for creating the bug!

--
versions: +Python 3.0 -Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3444] add warnings for intra-package imports

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

I've been trying to do this for a little, but I can't actually figure
out how to implement the warnings. If anyone has any advice on this I'd
be very thankful! Anyway, you're right in that this doesn't need to
block betas.

--
priority: release blocker -> deferred blocker

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser considers XML as text rather than bytes

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

> Just to be clear, I am at present totally confused about io streams :-)

Python 3.0 distincts more clearly between unicode strings (called "str"
in 3.0) and bytes strings (called "bytes" in 3.0). The most important
point being that there is no more any implicit conversion between the
two: you must explicitly use .encode() or .decode().

Files opened in binary ("rb") mode returns byte strings, but files
opened in text ("r") mode return unicode strings, which means you can't
give a text file to 3.0 library expecting a binary file, or vice-versa.

What is more worrying is that XML, until decoded, should be considered a
byte stream, so sax.parser should accept binary files rather than text
files. I took a look at test_sax and indeed it considers XML as text
rather than bytes :-(

Bumping this as critical because it needs a decision very soon (ideally
before beta3).

--
nosy: +pitrou
priority:  -> critical
title: sax.parser hangs on byte streams -> sax.parser considers XML as text 
rather than bytes

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3578] 'dictionary changed size' error in test_multiprocessing

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Mmmh, the problem with the list(X.items()) idiom is that it's
thread-safe only if X.items() is implemented in C. Otherwise X can be
mutated if there is a thread-switch while executing bytecode in X.items().

In weakref.py (line 103), by replacing:
for key, wr in self.data.items():
with:
for key, wr in list(self.data.items()):

This particular error should disappear.

But this doesn't say why the dictionary is mutated at all. Does
multiprocessing (or at least that particular test) launch several
threads in a given process? Otherwise there may be something fishy going on.

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2827] IDLE 3.0a5 cannot handle UTF-8

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

I managed to get a proper traceback:

Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\afa\python\py3k\lib\tkinter\__init__.py", line 1405, in __call__
return self.func(*args)
  File "c:\afa\python\py3k\lib\idlelib\MultiCall.py", line 165, in handler
r = l[i](event)
  File "c:\afa\python\py3k\lib\idlelib\ScriptBinding.py", line 124, in
run_module_event
code = self.checksyntax(filename)
  File "c:\afa\python\py3k\lib\idlelib\ScriptBinding.py", line 86, in
checksyntax
source = f.read()
  File "C:\afa\python\py3k\lib\io.py", line 1692, in read
decoder.decode(self.buffer.read(), final=True))
  File "C:\afa\python\py3k\lib\io.py", line 1267, in decode
output = self.decoder.decode(input, final=final)
  File "C:\afa\python\py3k\lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position
34: character maps to 

This is because the file is opened in text mode, using the default
encoding (cp1252). It should instead open it in binary mode, and look
for a -*-coding-*- directive.
There is an attempt for this in linecache.py, but the logic there is wrong.

Is there already a function to properly open a python source file?
tokenize.detect_encoding could be used, but is there a way to open a
file in binary & universal mode?

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1342811] Tkinter.Menu.delete doesn't delete command of entry

[Robert Schuppenies]

Robert Schuppenies <[EMAIL PROTECTED]> added the comment:

You are right. How about the attached patch, do you see any problems
here? Tkinter seems to ignore any delete calls when either of the
indices is None, so the deletion of commands may be ignored as well. But
I couldn't find a description making this API behavior official.

And does anybody know about a test suite for the Tkinter library where
issues like these are tested?

Added file: http://bugs.python.org/file11146/tkinter_menu-error.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3352] Deficiencies in multiprocessing/threading API

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

I think I can get this done before the release now. For starters I
changed thread.get_ident() to a property in r65818.

--
assignee:  -> benjamin.peterson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3586] pwd.getpwnam('nobody') produces incorrect results if sizeof(uid_t) < sizeof(long)

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Issue 1747858 looks closely related.  I propose extending the simple fix 
used there, parsing all uids and gids as longs rather than ints.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3591] elementtree tests do not include bytes handling

[Antoine Pitrou]

New submission from Antoine Pitrou <[EMAIL PROTECTED]>:

In py3k, there should be explicit tests for byte string input (in
addition to unicode input) to elementtree's parser, including non-UTF8
encodings and non-ASCII chars.

--
components: Tests, XML
messages: 71351
nosy: effbot, pitrou
priority: normal
severity: normal
status: open
title: elementtree tests do not include bytes handling
type: behavior
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

On Mon, Aug 18, 2008 at 3:52 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Are many people using OpenDNS? Is there a way to detect that OpenDNS is
> being used and trigger a separate path in the test?
> I say that because returning a 404 when the domain lookup has failed is
> wrong. Perhaps the test should check for a 404 and still raise an
> exception, but with an appropriate message indicating that it may be due
> to a "featureful" DNS service.
>

That's also a possibility.

Out of curiosity, what HTTP response should be received?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Le lundi 18 août 2008 à 17:19 +, Brett Cannon a écrit :
> That's also a possibility.
> 
> Out of curiosity, what HTTP response should be received?

There shouldn't be an HTTP response at all. If DNS lookup fails,
connecting to the server simply fails.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2876] Write UserDict fixer for 2to3

[Nick Edds]

Nick Edds <[EMAIL PROTECTED]> added the comment:

What's the current status of this? If nobody is working on it, I would
be willing to give it a shot. Can somebody just confirm that I have a
correct understanding of the problem.
UserDict.UserDict needs a deprecation warning, UserDict.IterableUserDict
becomes collections.UserDict, and UserDict.Mixin becomes
collections.MutableMapping. Then for keys(), items(), and values(), I
want to replace something like d.keys() to list(d.keys()). 
One added question: based on what I gathered from PEP 3106, this last
part is only needed in a situation such as a = d.keys(), but not a
situation like for key in keys:, so because in the later case wrapping
the call to keys() in list() would presumably be suboptimal, is this
something I should try and avoid? I'm not sure exactly how it could be
done, but I have some idea of how it to do it.

--
nosy: +nedds

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2876] Write UserDict fixer for 2to3

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

On Mon, Aug 18, 2008 at 10:59 AM, Nick Edds <[EMAIL PROTECTED]> wrote:
>
> Nick Edds <[EMAIL PROTECTED]> added the comment:
>
> What's the current status of this?

I think it is waiting for someone to work on it.

> If nobody is working on it, I would
> be willing to give it a shot.

Great!

> Can somebody just confirm that I have a
> correct understanding of the problem.
> UserDict.UserDict needs a deprecation warning, UserDict.IterableUserDict
> becomes collections.UserDict, and UserDict.Mixin becomes
> collections.MutableMapping.

In theory, yes, but the superclasses have changed, so I don't know if
having a fixer is really the best option in this case since it is not
a simple renaming. Perhaps deprecation warnings stating that the
classes have been moved and given different superclasses would make
more sense?

> Then for keys(), items(), and values(), I
> want to replace something like d.keys() to list(d.keys()).

Sure, but how the heck are you going to get 2to3 to do this properly
just for UserDict instances? Doesn't the keys()/values()/items() fixer
already do this blindly anyway?

> One added question: based on what I gathered from PEP 3106, this last
> part is only needed in a situation such as a = d.keys(), but not a
> situation like for key in keys:, so because in the later case wrapping
> the call to keys() in list() would presumably be suboptimal, is this
> something I should try and avoid? I'm not sure exactly how it could be
> done, but I have some idea of how it to do it.
>

Yes, you are right that wrapping the call in a for loop is not needed
since code will never come across it. But as I said above, doesn't the
fixer for dicts already handle all of this?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Looking into this now.  Will make sure it's included in beta3.

--
assignee:  -> gvanrossum
priority:  -> release blocker

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3352] Deficiencies in multiprocessing/threading API

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Ok. I've done the threading API and patched up multiprocessing so it
actually works. Jesse, can you do multiprocessing?

Also, can we decide about is_alive as a property?

--
assignee: benjamin.peterson -> jnoller

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3352] Deficiencies in multiprocessing/threading API

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Oh, and by the way, I would start working on multiprocessing by
reverting r65828.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3352] Deficiencies in multiprocessing/threading API

[Jesse Noller]

Jesse Noller <[EMAIL PROTECTED]> added the comment:

On Mon, Aug 18, 2008 at 2:44 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> Ok. I've done the threading API and patched up multiprocessing so it
> actually works. Jesse, can you do multiprocessing?
>
> Also, can we decide about is_alive as a property?
>

Yup, I can do the MP part.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3352] Deficiencies in multiprocessing/threading API

[Jesse Noller]

Jesse Noller <[EMAIL PROTECTED]> added the comment:

On Mon, Aug 18, 2008 at 2:45 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> Oh, and by the way, I would start working on multiprocessing by
> reverting r65828.
>

Makes sense.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser considers XML as text rather than bytes

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

>From the discussion on the python-3000, it looks like it would be nice
if sax.parser handled both bytes and unicode streams.

Edward, does your simple fix make sax.parser work entirely well with
byte streams?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3494] "[Errno 11] Resource temporarily unavailable" while using tracing facility/threads (in linux listdir with unicode path)

[Fabio Zadrozny]

Fabio Zadrozny <[EMAIL PROTECTED]> added the comment:

I've pasted the output below... also, the trace function is called for
each function call after the settrace (not only in interpreter shutdown)
-- and the error happens in the listdir -- which is in the main thread,
so, it must happen before the interpreter shutdown.

Also, one thing: it works if you read an empty folder... And putting:
"print frame.f_code.co_filename, frame.f_lineno" in the 'func', it'll go
on and print
/usr/lib/python2.4/encodings/utf_8.py 15
/usr/lib/python2.4/encodings/utf_8.py 16
/usr/lib/python2.4/encodings/utf_8.py 16

For each file/dir available (so, it seems it's actually able to go on
and get all the contents, but before returning, that exception is thrown)

Output from running it:

-


/usr/bin/python
Traceback (most recent call last):
  File "/home/fabioz/test workspace with spaces/test
project/src/mod1/mod2/listdir_problem.py", line 23, in ?
print listdir(dir)
OSError: [Errno 11] Resource temporarily unavailable: '/home/fabioz/jython'

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3496] distutils fails with mingw binutils 2.18.50.20080109

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Yes, this problem is a duplicate of #2234, for which I had a very
similar fix.
Thanks!

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2234] cygwinccompiler.py fails for latest MinGW releases.

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Fixed by r65834, thanks to the patch provided in issue3496.
Will backport.

--
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2234] cygwinccompiler.py fails for latest MinGW releases.

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

committed r65835 in the release25-maint branch.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3578] 'dictionary changed size' error in test_multiprocessing

[Ismail Donmez]

Ismail Donmez <[EMAIL PROTECTED]> added the comment:

py3k branch gives another error now, when running test_multiprocessing 
in a tight loop:

test test_multiprocessing failed -- Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/test/test_multiprocessing.py", 
line 1163, in test_remote
queue = manager2.get_queue()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 641, in temp
authkey=self._authkey, exposed=exp
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 893, in AutoProxy
incref=incref)
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 702, in __init__
self._incref()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 749, in _incref
dispatch(conn, None, 'incref', (self._id,))
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 85, in dispatch
raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 

---
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 187, in handle_request
result = func(c, *args, **kwds)
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 403, in incref
self.id_to_refcount[ident] += 1
KeyError: '7389d0'

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3578] 'dictionary changed size' error in test_multiprocessing

[Jesse Noller]

Jesse Noller <[EMAIL PROTECTED]> added the comment:

Ismail, that's the incref bug in issue 3419

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3578] 'dictionary changed size' error in test_multiprocessing

[Ismail Donmez]

Ismail Donmez <[EMAIL PROTECTED]> added the comment:

Ah cool, we might be at the end of multiprocessing problems then I guess 
:-)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3109] test_multiprocessing seems fragile

[Jesse Noller]

Jesse Noller <[EMAIL PROTECTED]> added the comment:

the "socket.error: [Errno 111] Connection refused" is fixed/resolved with 
the fix for issue 3270

--
resolution:  -> duplicate
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3578] 'dictionary changed size' error in test_multiprocessing

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Le lundi 18 août 2008 à 19:42 +, Ismail Donmez a écrit :
> Ismail Donmez <[EMAIL PROTECTED]> added the comment:
> 
> Ah cool, we might be at the end of multiprocessing problems then I guess 
> :-)

Well, not really, it should be diagnosed why the dictionary mutates in
the first place. This dictionary is apparently processed in a child
process just after a fork() occurred, so logically there shouldn't be
several threads running.
Unless processing the dictionary itself can create some new threads?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1342811] Tkinter.Menu.delete doesn't delete command of entry

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

You could return if in that new if statement.

As you noted, the None argument is ignored there, that is because
_tkinter checks for a None parameter, and if it happens to be a None, it
then stops processing new arguments, so this is not directly related to
the delete command of the Menu widget.

Regarding a test suite.. it would be very nice to get one for Tkinter.
Some weeks ago I did some googling but found no attempts for my surprise.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1342811] Tkinter.Menu.delete doesn't delete command of entry

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

change this:

"You could return if in that new if statement."

to:

"You could return in that new if statement.", please.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser considers XML as text rather than bytes

[Edward K Ream]

Edward K Ream <[EMAIL PROTECTED]> added the comment:

On Mon, Aug 18, 2008 at 1:51 PM, Antoine Pitrou <[EMAIL PROTECTED]>wrote:

>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> From the discussion on the python-3000, it looks like it would be nice
> if sax.parser handled both bytes and unicode streams.
>

> Edward, does your simple fix make sax.parser work entirely well with
> byte streams?

No. The sax.parser seems to have other problems.  Here is what I *think* I
know ;-)

1. A smallish .leo file (an xml file) containing a single non-ascii (utf-8)
encoded character appears to have been read correctly with Python 3.0.

2. A larger .leo file fails as follows (it's possible that the duplicate
error messages are a Leo problem):

Traceback (most recent call last):
Traceback (most recent call last):

  File "C:\leo.repo\leo-30\leo\core\leoFileCommands.py", line 1283, in
parse_leo_file
parser.parse(theFile) # expat does not support parseString
  File "C:\leo.repo\leo-30\leo\core\leoFileCommands.py", line 1283, in
parse_leo_file
parser.parse(theFile) # expat does not support parseString

  File "c:\python30\lib\xml\sax\expatreader.py", line 107, in parse
xmlreader.IncrementalParser.parse(self, source)
  File "c:\python30\lib\xml\sax\expatreader.py", line 107, in parse
xmlreader.IncrementalParser.parse(self, source)

  File "c:\python30\lib\xml\sax\xmlreader.py", line 121, in parse
buffer = file.read(self._bufsize)
  File "c:\python30\lib\xml\sax\xmlreader.py", line 121, in parse
buffer = file.read(self._bufsize)

  File "C:\Python30\lib\io.py", line 1670, in read
eof = not self._read_chunk()
  File "C:\Python30\lib\io.py", line 1670, in read
eof = not self._read_chunk()

  File "C:\Python30\lib\io.py", line 1499, in _read_chunk
self._set_decoded_chars(self._decoder.decode(input_chunk, eof))
  File "C:\Python30\lib\io.py", line 1499, in _read_chunk
self._set_decoded_chars(self._decoder.decode(input_chunk, eof))

  File "C:\Python30\lib\io.py", line 1236, in decode
output = self.decoder.decode(input, final=final)
  File "C:\Python30\lib\io.py", line 1236, in decode
output = self.decoder.decode(input, final=final)

  File "C:\Python30\lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
  File "C:\Python30\lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]

UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 74:
character maps to 
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 74:
character maps to 

The same calls to sax read the file correctly on Python 2.5.

It would be nice to have a message pinpoint the line and character offset of
the problem.

My vote would be for the code to work on both kinds of input streams. This
would save the users considerable confusion if sax does the (tricky)
conversions automatically.

Imo, now would be the most convenient time to attempt this--there is a
certain freedom in having everything be partially broken :-)

Edward

Edward K. Ream email: [EMAIL PROTECTED]
Leo: http://webpages.charter.net/edreamleo/front.html


Added file: http://bugs.python.org/file11147/unnamed

___
Python tracker <[EMAIL PROTECTED]>

___On Mon, Aug 18, 2008 at 1:51 
PM, Antoine Pitrou [EMAIL PROTECTED]> wrote:

Antoine Pitrou [EMAIL PROTECTED]> 
added the comment:

From the discussion on the python-3000, it looks like it would be nice
if sax.parser handled both bytes and unicode 
streams. 
Edward, does your simple fix make sax.parser work entirely well with
byte streams?No. The sax.parser seems to have other 
problems.  Here is what I *think* I know ;-)1. A smallish .leo 
file (an xml file) containing a single non-ascii (utf-8) encoded character 
appears to have been read correctly with Python 3.0.
2. A larger .leo file fails as follows (it's possible that the 
duplicate error messages are a Leo problem):Traceback (most recent call 
last):Traceback (most recent call last):  File 
"C:\leo.repo\leo-30\leo\core\leoFileCommands.py", line 1283, in 
parse_leo_file
    parser.parse(theFile) # expat does not support 
parseString  File 
"C:\leo.repo\leo-30\leo\core\leoFileCommands.py", line 1283, in 
parse_leo_file    parser.parse(theFile) # expat does not 
support parseString
  File "c:\python30\lib\xml\sax\expatreader.py", line 107, 
in parse    xmlreader.IncrementalParser.parse(self, 
source)  File "c:\python30\lib\xml\sax\expatreader.py", line 
107, in parse
    xmlreader.IncrementalParser.parse(self, 
source)  File "c:\python30\lib\xml\sax\xmlreader.py", 
line 121, in parse    buffer = 
fil

[issue2234] cygwinccompiler.py fails for latest MinGW releases.

[Jason Tishler]

Jason Tishler <[EMAIL PROTECTED]> added the comment:

Thanks!

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser considers XML as text rather than bytes

[Edward K Ream]

Edward K Ream <[EMAIL PROTECTED]> added the comment:

On Mon, Aug 18, 2008 at 11:00 AM, Antoine Pitrou <[EMAIL PROTECTED]>wrote:

>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> > Just to be clear, I am at present totally confused about io streams :-)
>
> Python 3.0 distincts more clearly between unicode strings (called "str"
> in 3.0) and bytes strings (called "bytes" in 3.0). The most important
> point being that there is no more any implicit conversion between the
> two: you must explicitly use .encode() or .decode().
>
> Files opened in binary ("rb") mode returns byte strings, but files
> opened in text ("r") mode return unicode strings, which means you can't
> give a text file to 3.0 library expecting a binary file, or vice-versa.
>
> What is more worrying is that XML, until decoded, should be considered a
> byte stream, so sax.parser should accept binary files rather than text
> files. I took a look at test_sax and indeed it considers XML as text
> rather than bytes :-(

Thanks for these remarks.  They confirm what I suspected, but was unsure of,
namely that it seems strange to be passing something other than a byte
stream to parser.parse.

>
> Bumping this as critical because it needs a decision very soon (ideally
> before beta3).

Thanks for taking this seriously.

Edward

P.S.  I love the new unicode plans.  They are going to cause some pain at
first for everyone (Python team and developers), but in the long run they
are going to be a big plus for Python.

EKR

Edward K. Ream email: [EMAIL PROTECTED]
Leo: http://webpages.charter.net/edreamleo/front.html


Added file: http://bugs.python.org/file11148/unnamed

___
Python tracker <[EMAIL PROTECTED]>

___On Mon, Aug 18, 2008 at 11:00 
AM, Antoine Pitrou [EMAIL PROTECTED]> wrote:

Antoine Pitrou [EMAIL PROTECTED]> 
added the comment:

> Just to be clear, I am at present totally confused about io streams :-)

Python 3.0 distincts more clearly between unicode strings (called 
"str"
in 3.0) and bytes strings (called "bytes" in 3.0). The most 
important
point being that there is no more any implicit conversion between the
two: you must explicitly use .encode() or .decode().

Files opened in binary ("rb") mode returns byte strings, but files
opened in text ("r") mode return unicode strings, which means you 
can't
give a text file to 3.0 library expecting a binary file, or vice-versa.

What is more worrying is that XML, until decoded, should be considered a
byte stream, so sax.parser should accept binary files rather than text
files. I took a look at test_sax and indeed it considers XML as text
rather than bytes :-(Thanks for these remarks.  They 
confirm what I suspected, but was unsure of, namely that it seems strange to be 
passing something other than a byte stream to parser.parse.


Bumping this as critical because it needs a decision very soon (ideally
before beta3).Thanks for taking this 
seriously.EdwardP.S.  I love the new unicode plans.  
They are going to cause some pain at first for everyone (Python team and 
developers), but in the long run they are going to be a big plus for Python.
EKREdward
 K. Ream email: mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]Leo: http://webpages.charter.net/edreamleo/front.html";>http://webpages.charter.net/edreamleo/front.html


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

[issue3439] math.frexp and obtaining the bit size of a large integer

[Fredrik Johansson]

Fredrik Johansson <[EMAIL PROTECTED]> added the comment:

Wow, newbie error. Thanks for spotting!

In every case I can think of, I've wanted (0).numbits() to be 0. The
explanation in the docstring can probably be improved. What other
documentation is needed (where)?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3494] "[Errno 11] Resource temporarily unavailable" while using tracing facility/threads (in linux listdir with unicode path)

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

I could reproduce the problem, and it appears that it is the same as
#1608818, corrected by r65037:

on posix platforms, listdir() used to check for errno only at the end of
the list; the problem is that the trace function creates a thread, and
this sets errno (harmlessly) somewhere when playing with locks.

In the python codebase, every function that checks errno should set it
to zero before the system call.
The above fix could be backported.

As a workaround, I suggest to put a line like 
   int('0')
near the end of the trace funtion (at least after the creation of the
thread) because it has the nice side-effect to reset errno.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2876] Write UserDict fixer for 2to3

[Nick Edds]

Nick Edds <[EMAIL PROTECTED]> added the comment:

Ahh right. I totally forgot that there was already a fix_dict.py that
took care of that.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3592] Patch to add imp.get_codingspec()

[Brett Cannon]

New submission from Brett Cannon <[EMAIL PROTECTED]>:

Attached is a patch to add imp.get_codingspec(); a function that returns
the encoding of a source file.

The motivation is to remove the import of the re module in linecache to
speed up interpreter startup.

--
components: Library (Lib)
files: reviewed_get_encodingspec.diff
keywords: patch, patch
messages: 71379
nosy: brett.cannon, christian.heimes
priority: low
severity: normal
status: open
title: Patch to add imp.get_codingspec()
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file11149/reviewed_get_encodingspec.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3592] Patch to add imp.get_codingspec()

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

It should be noted the original patch by Christian had a check for bad
tokenizing. Turns out that if you have that in several tests fail,
including test_modulefinder. This might mean there is a deeper problem
in the parser.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser considers XML as text rather than bytes

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

> The same calls to sax read the file correctly on Python 2.5.

What are those calls exactly?
Why is "cp1252" used as an encoding? Is it what is specified in the XML
file? Or do you somehow feed stdin to the SAX parser? (if the latter,
you aren't testing bytes handling since stdin/stdout/stderr are text
streams in py3k)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser considers XML as text rather than bytes

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

I guess that the file is simply opened in text mode ("r"). This uses the
"preferred encoding", which is cp1252 on (western) Windows machines.

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3494] "[Errno 11] Resource temporarily unavailable" while using tracing facility/threads (in linux listdir with unicode path)

[Fabio Zadrozny]

Fabio Zadrozny <[EMAIL PROTECTED]> added the comment:

Thanks for looking into this... 

Unfortunately, I'm not sure I can use the workaround of the int('0'), as
this could fix the debugger, but if the code that's being debugged
spawned other threads (which is pretty common), it would be pointless,
but at least clients that really want this can get that fix and apply it
to their python versions...

And I think that setting the errno to 0 in the debugger every time would
make other things misbehave, as in each python call it'd clear it (or
not? I'm not really aware of the implications of doing so -- but if no
one used it, it wouldn't be there, right?)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3439] math.frexp and obtaining the bit size of a large integer

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

> In every case I can think of, I've wanted (0).numbits() to be 0.

Me too, in most cases, though I've encountered the occasional case where 
raising ValueError would be more appropriate and would catch some bugs 
that might otherwise pass silently.

So I agree that (0).numbits() should be 0, but I think there's enough 
potential ambiguity that there should be a sentence in the documentation  
making this explicit.  Two of the most obvious (wrong) formulas for 
numbits are: (1) numbits(n) = ceiling(log_2(n)), and (2) numbits(n) = 
len(bin(n))-2, but neither of these formulas gives the right result for 
0, or for negative numbers for that matter.

> The explanation in the docstring can probably be improved. What other 
documentation is needed (where)?

The docstring looked okay to me.  There should be more comprehensive 
ReST documentation in the Doc/ directory somewhere, probably in 
Doc/library/stdtypes.rst

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3593] subprocess + stdout redirection + wait + svn= hang

[Miki Tebeka]

New submission from Miki Tebeka <[EMAIL PROTECTED]>:

The attached script hangs on Ubuntu + Python 2.5.2.
When make the limit smaller (like 10) or not redirecting stdout, it works.

Running the svn command from shell took about 4sec, I gave up on the
script after a minute.

I tried it both with svn 1.4.6 and 1.5.1 - no change.

--
components: Library (Lib)
files: svnout.py
messages: 71385
nosy: tebeka
severity: normal
status: open
title: subprocess + stdout redirection + wait + svn= hang
versions: Python 2.6
Added file: http://bugs.python.org/file11150/svnout.py

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3494] "[Errno 11] Resource temporarily unavailable" while using tracing facility/threads (in linux listdir with unicode path)

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

> but if the code that's being debugged
> spawned other threads (which is pretty common), it would be pointless,

No, the problem specifically lies in the implementation of listdir().
This function is not supposed to commonly spawn threads... this can only
happen with a sys.settrace function (or a very special
Py_FileSystemDefaultEncoding)

> And I think that setting the errno to 0 in the debugger every time would
> make other things misbehave, as in each python call it'd clear it

I don't think so. errno is (should be) only used shortly after the C
system call which modified it. There is no room for the trace function
to run.
Remember that the python stack is often displayed on every debugging
step, and this modifies errno more than once (to get the source file
content)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Checked in patch 10 with minor style changes as r65838.

Thanks Matt for persevering!  Thanks everyone else for contributing;
this has been quite educational.

--
resolution:  -> accepted
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue815646] thread unsafe file objects cause crash

[Kevin Watters]

Kevin Watters <[EMAIL PROTECTED]> added the comment:

I know this is long closed, but no one on the nosy list happens to have
this fix backported to 2.5, do they? :) If not, I'll attach one here
eventually...

--
nosy: +kevinwatters

___
Python tracker <[EMAIL PROTECTED]>

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

[issue815646] thread unsafe file objects cause crash

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

> I know this is long closed, but no one on the nosy list happens to have
> this fix backported to 2.5, do they? :)

I think that at the time no one was sure the patch was 100% harmless. It
also subtly changes the behaviour of close() when called while another
IO operation is in progress in another thread, which is arguably a bug
fix but can still raise an exception it wouldn't have raised in 2.5.

So all in all I'm not sure this should be backported, although it would
probably be an improvement in most cases. I'll let someone else take the
decision.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser considers XML as text rather than bytes

[Edward K Ream]

Edward K Ream <[EMAIL PROTECTED]> added the comment:

On Mon, Aug 18, 2008 at 4:15 PM, Antoine Pitrou <[EMAIL PROTECTED]>wrote:

>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> > The same calls to sax read the file correctly on Python 2.5.
>
> What are those calls exactly?

  parser = xml.sax.make_parser()
  parser.setFeature(xml.sax.handler.feature_external_ges,1)
  handler = saxContentHandler(c,inputFileName,silent,inClipboard)
  parser.setContentHandler(handler)
  parser.parse(theFile)

As discussed in http://bugs.python.org/issue3590

theFile is a file opened with 'rb' attributes

Edward


Edward K. Ream email: [EMAIL PROTECTED]
Leo: http://webpages.charter.net/edreamleo/front.html


Added file: http://bugs.python.org/file11151/unnamed

___
Python tracker <[EMAIL PROTECTED]>

___On Mon, Aug 18, 2008 at 4:15 
PM, Antoine Pitrou [EMAIL PROTECTED]> wrote:

Antoine Pitrou [EMAIL PROTECTED]> 
added the comment:

> The same calls to sax read the file correctly on 
Python 2.5.

What are those calls exactly?  parser = 
xml.sax.make_parser()  
parser.setFeature(xml.sax.handler.feature_external_ges,1)  handler = 
saxContentHandler(c,inputFileName,silent,inClipboard)
  parser.setContentHandler(handler)  parser.parse(theFile)As 
discussed in http://bugs.python.org/issue3590";>http://bugs.python.org/issue3590theFile
 is a file opened with 'rb' attributes
EdwardEdward
 K. Ream email: mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]Leo: http://webpages.charter.net/edreamleo/front.html";>http://webpages.charter.net/edreamleo/front.html


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

[issue3590] sax.parser considers XML as text rather than bytes

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11145/unnamed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser considers XML as text rather than bytes

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11147/unnamed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser considers XML as text rather than bytes

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11148/unnamed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser considers XML as text rather than bytes

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11151/unnamed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3590] sax.parser considers XML as text rather than bytes

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Ok, then xml.sax looks rather broken.

(by the way, can you avoid sending HTML emails? each time you send one,
the bug tracker attaches a file names "unnamed". I've removed all 4 of
them now.)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2919] Merge profile/cProfile in 3.0

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

Sorry, I can't. I would love to get this done, but I am just too busy
this week (and next week doesn't look any better). Furthermore, the
amount of work that the profile/cProfile merge will require is quite
considerable. So, I don't expect someone else could get this done before
the beta.

--
keywords: +patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2919] Merge profile/cProfile in 3.0

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Let's retarget 3.1 then.

--
nosy: +benjamin.peterson
priority: release blocker -> critical
versions: +Python 3.1 -Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3385] cPickle to pickle conversion in py3k missing methods

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

Yeah, the old Pickler and Unpickler classes are available by design (to
allow testing both implementation). You could subclass _Pickler as a
temporary fix for this issue.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3558] Operator precedence misdocumented

[Terry J. Reedy]

Terry J. Reedy <[EMAIL PROTECTED]> added the comment:

I am reopening because my suggested fix was wrong. As pointed out by
Fredrik Lundh on PyDev the next day, quoting from the grammar,
attributes, subscriptions, slicing, and call have the *same* precedence.
 I thought I posted his comment and an correct fix, but it is not here,
so here it is again, with additional needed fixes revealed by another
post in c.l.p.  The problem is that the table has three (not just one)
groups of equal precedence entries on multiple lines.  And power has
mixed precedence.

Suggestions (low to high as in the table):

Comparisons section
"all comparison operations in Python have the same priority, which is
lower than that of any arithmetic, shifting or bitwise operation."

In the table, before the "in" line, add
"[Next 3 lines indicate same precedence]Comparisons"
Then indent both the operator and description entries on the next three
lines, and for the third, change "Comparisons" to "Order and equality
tests". Inclusion and identity tests are comparisons also.

Retitle section "Unary arithmetic operations" to "Unary arithmetic and
bitwise operations" and change the following sentence
"All unary arithmetic (and bitwise) operations have the same priority:"
to 
"All unary arithmetic and bitwise operations have the same priority:"
The parentheses could lead one to not understand that 'unary' applies to
bitwise as well as arithmetic.  (Which is to say, I was initially
confused ;-).

Then combine the corresponding lines in the table to make
+x, -x, ~x  Positive, negative,  bitwise not

Primaries section:
"Primaries represent the most tightly bound operations of the language.
Their syntax is:
primary ::=  atom | attributeref | subscription | slicing | call"

Fredrik quoted the following from the grammar
trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME

and this from the TEX version of the docs:
"  \hline
\lineii{\code{+\var{x}}, \code{-\var{x}}}{Positive, negative}
\lineii{\code{\~\var{x}}}{Bitwise not}
  \hline
\lineii{\code{**}}{Exponentiation}
  \hline
\lineii{\code{\var{x}.\var{attribute}}}{Attribute reference}
\lineii{\code{\var{x}[\var{index}]}}{Subscription}
\lineii{\code{\var{x}[\var{index}:\var{index}]}}{Slicing}
\lineii{\code{\var{f}(\var{arguments}...)}}{Function call}
  \hline
  ...
which indicates that the author intended "." and "[" to appear in the
same box, but got overruled by the Tex->HTML conversion tool. " 

The overruling happened at least back to the 2.4 docs.
 
So I suggest
"[Next 4 lines indicate same precedence]  Trailers" 
with indents as before.

An alternative to the added line and indent fix would be to remove the
lines between things of equal precedence.  The suggested text changes,
including the one to 'Comparisons' in the table, would still remain.

Since the last three entries in the table are all atoms, it is possible
that they also have the same precedence with respect to each other
(Fredrik did not quote any more of the TEX source), though it is a moot
point I think because of the required nesting.

Last issue (I hope): "The power operator binds more tightly than unary
operators on its left; it binds less tightly than unary operators on its
right."

To be exactly correct, 'arithmetic and binary' should modify 'unary'
since there is also unary logical operator not, and ** does *not* bind
less tightly that 'not' on its right.  An expression like "2 ** not 1"
has been parsed as "2 (** not) 1",  a syntax error, probably forever and
certainly in 2.2 before bools up to 3.0, and not as "2 ** (not 1)",
which is 1 even in 3.0.

Also, the table really needs two ** lines:
** [followed by +,-,~]Exponentiation
** [othewise] Exponentiation
before and after the unary +,-,~ line or lines, in that order.

I will review the patch if you post it.  I will otherwise try to take a
look when it comes out.

--
resolution: fixed -> 
status: closed -> open

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3585] pkg-config support

[Clinton Roy]

Clinton Roy <[EMAIL PROTECTED]> added the comment:

Thanks for the comments Amaury, this patch uses ${VERSION} throughout so
that it can be applied across branches.

cheers,

Added file: http://bugs.python.org/file11152/pkgconfig.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3594] PyTokenizer_FindEncoding() never succeeds

[Brett Cannon]

New submission from Brett Cannon <[EMAIL PROTECTED]>:

Turns out that PyTokenizer_FindEncoding() never properly succeeds
because the tok_state used by it does not have tok->filename set, which
is an error condition in the tokenizer. This error has been masked by
the one place the function is used, imp.find_module() because a NULL
return is never checked for an error, but instead just assumes the
default source encoding suffices.

--
components: Extension Modules
messages: 71397
nosy: brett.cannon, christian.heimes
priority: critical
severity: normal
status: open
title: PyTokenizer_FindEncoding() never succeeds
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3594] PyTokenizer_FindEncoding() never succeeds

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

I have not bothered to check if this exists in 2.6, but I don't see why
it would be any different.

--
type:  -> behavior

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3594] PyTokenizer_FindEncoding() never succeeds

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Turns out that the NULL return value can signal an error that manifests
itself as SyntaxError("encoding problem: with BOM") thanks to the lack
of tok->filename being set in Parser/tokenizer.c:fp_setreadl() which is
called by check_coding_spec() and assumes that since tok->encoding was
never set (because fp_setreadl() returned an error value) that it had
something to do with the BOM.

The only reason this was found is because my bootstrapping of importlib
into Py3K, at some point, triggers a PyErr_Occurred() which finally
notices the error.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3595] Windows base64 Decode

[Ahir Reddy]

New submission from Ahir Reddy <[EMAIL PROTECTED]>:

I'm new to this and not quite sure how to go about posting an issue, but
I will do the best I can. In Python 2.5.2, both from python.org and
active state, all methods of decoding in base64 under Windows produce
different output than base64 decoding under UNIX (I've tested it both on
OS X and Linux, which produce the same results). I ran into this while
writing a script that downloads email and parses mime attachments which
are base64 encoded by a similar upload script. UNIX systems are able to
download the attachments and decode the base64 back to the original
attachments correctly, which I've verified with md5sum hashes. The same
script under windows produces an incorrect file. At first I was not sure
what the issue was, and I eventually wrote the raw base64 attachment to
a file. I then used a windows command line tool to decode the file and
it produced the correct output (again checked by md5sum). This leads me
to believe that something is strange with base64 under Windows. I hope
my explanation has helped some. If need be I'll upload the script so
others can replicate my results.

Ahir

--
components: Library (Lib)
messages: 71400
nosy: ahirreddy
severity: normal
status: open
title: Windows base64 Decode
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3574] compile() cannot decode Latin-1 source encodings

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Can someone double-check this patch for me? I don't have much experience
with the parser so I want to make sure I am not doing anything wrong.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3574] compile() cannot decode Latin-1 source encodings

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

There is a potential dependency on issue3594 as it would change how
imp.find_module() acts and thus make test_imp no longer fail in the way
it has.

--
dependencies: +PyTokenizer_FindEncoding() never succeeds

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3574] compile() cannot decode Latin-1 source encodings

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

That line dates back to the PEP 263 implementation. Martin?

--
nosy: +benjamin.peterson, loewis

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3596] Provide a way to disable SSLv2 (or better yet, disable by default)

[Heikki Toivonen]

New submission from Heikki Toivonen <[EMAIL PROTECTED]>:

There should be a way to disable SSLv2 since it is insecure. It would be
even better if SSLv2 was disabled out of the box, but maybe there could
be a way to re-enable it.

I made the default to disable SSLv2 in M2Crypto, but those that want it
can explicitly request unsecure connection. You can take a look at
http://svn.osafoundation.org/m2crypto/trunk/M2Crypto/SSL/Context.py to
see how I did it.

Modern web browsers are also removing SSLv2 support from them, so it
should be really rare to actually need v2 anywhere.

--
components: Library (Lib)
messages: 71404
nosy: heikki
severity: normal
status: open
title: Provide a way to disable SSLv2 (or better yet, disable by default)
type: security
versions: Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate

[Heikki Toivonen]

Heikki Toivonen <[EMAIL PROTECTED]> added the comment:

I would definitely recommend providing as strict as possible hostname
verification in the stdlib, but provide application developers a way to
override that.

M2Crypto (and TLS Lite, from which I copied the approach to M2Crypto),
provide a default post connection checker. See
http://svn.osafoundation.org/m2crypto/trunk/M2Crypto/SSL/Connection.py
and the set_post_connection_check_callback() as well as
http://svn.osafoundation.org/m2crypto/trunk/M2Crypto/SSL/Checker.py.

--
nosy: +heikki

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3597] Allow application developers to select ciphers, and default to strong in ssl lib

[Heikki Toivonen]

New submission from Heikki Toivonen <[EMAIL PROTECTED]>:

The 2.6 documentation states selecting the most compatible SSLv23 mode
may mean low quality ciphers, which does not really help the application
developers. It would be better to provide a way to set the allowed
ciphers. Even better, IMO, would be if the ssl module would default to
the stronger ciphers. I use the following default in M2Crypto:
set_cipher_list('ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH').

--
components: Library (Lib)
messages: 71406
nosy: heikki
severity: normal
status: open
title: Allow application developers to select ciphers, and default to strong in 
ssl lib
type: security
versions: Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3594] PyTokenizer_FindEncoding() never succeeds

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Attached is a patch that fixes where the error occurs. By opening the
file by either file name or file descriptor, the problem goes away. Once
this patch is accepted then PyErr_Occurred() should be added to all uses
of PyTokenizer_FindEncoding().

--
keywords: +patch
Added file: http://bugs.python.org/file11153/fix_findencoding.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3598] multiprocessing.Pool windows/linux behaviour difference

[Mark Summerfield]

New submission from Mark Summerfield <[EMAIL PROTECTED]>:

When the attached program is run on Linux it runs "instantly" and
outputs one line, e.g.:

$ python3 mtest.py
100 files, 1702627142 bytes

(The number of bytes will vary depending on the system.)

When run on Windows XP there is no output at all; many processes seem to
be created but nothing seems to actually get done.

In both cases I'm using Py30b2.

--
components: Library (Lib)
files: mtest.py
messages: 71408
nosy: mark
severity: normal
status: open
title: multiprocessing.Pool windows/linux behaviour difference
versions: Python 3.0
Added file: http://bugs.python.org/file11154/mtest.py

___
Python tracker <[EMAIL PROTECTED]>

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