[issue5395] array.fromfile not checking I/O errors

[Jan Hosang]

Jan Hosang  added the comment:

1&2) I removed the try/except around the import. I have no clue if os 
might be unavailable. Maybe leave out handling that until we see that 
breaking.

I added the try/except because I saw that in other tests in the same 
file when importing gc.

3) Done.
4) The EOFError exceptions are tested in test_tofromfile.

> I tried to apply both the patches on the trunk but the tests don't
> pass. With the latest patch I get an EOFError instead of IOError in
> the assertRaises.
That is the also behaviour before the patch, so the ferror(fp) does not 
fire. Either the test is inappropriate or your system doesn't regard 
reading a closed filehandle an error. I'm not able to investigate this 
as it works fine on my os x 10.6. What system did you test it on?

Reliable ways of producing IOErrors are harder to find than I thought. 
Deleting the file between to reads makes it just look truncated. Another 
method I tried was crashing a process which holds the other end of a 
pipe, but that's messy and complicated.

--
Added file: http://bugs.python.org/file15046/array_ioerror.patch

___
Python tracker 

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

[issue7024] webbrowser : Could not open ftp server using webbrowser.open()

[Harshad Modi]

Harshad Modi  added the comment:

Hi, Antoine Pitrou!

It is missing key for ftp in url-handlers...
how can I add key for ftp?

Thanks

--

___
Python tracker 

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

[issue7042] test_signal fails on os x 10.6

[Jan Hosang]

Jan Hosang  added the comment:

I updated the checkout of the 26 branch, and the test runs fine now.

I have no clue about virtual time as well. If this is about passing time, 
there should be better ways (than those which break if your computer gets 
faster).

--
status: pending -> open

___
Python tracker 

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

[issue7038] test_curses fails on os x 10.6

[Jan Hosang]

Jan Hosang  added the comment:

I am not able to reproduce my own report :)

I'm sure I installed the 2.6.3 release, opened Terminal.app, checked 
`which python` and ran `python -m test.regrtest -uall`. I remember that I 
saw a crash report when I came back and some failed tests, so I ran the 
tests again (in a different tab) in verbose mode to post reports. (Maybe 
that makes sense to you.)

However, if I repeat what I did, the test does not fail anymore. So maybe 
just close it? :)

--

___
Python tracker 

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

[issue7063] Memory errors in array.array

[Jan Hosang]

New submission from Jan Hosang :

While I was backporting the new buffer API to 2.7 I noticed some issues 
in array_ass_slice() in Modules/arraymodule.c in the python 3k branch.

1) Manual memory reallocation had been replaced by calls to 
array_resize. But I think when PyMem_RESIZE is called the pointer to the 
memory might change. So this now happens in array_resize, and the
array->ob_item pointer changes but not it's local copy (item) in 
array_ass_slice().

2) The function moves too much memory if the array size is increased: 
(Py_SIZE(a)-d-ihigh) items should be moved, because Py_SIZE(a) was 
already modified by array_resize, but the function moves (Py_SIZE(a)-
ihigh) items.

While 1) might go unnoticed, 2) definitely broke slice tests in a 
"segmentation fault"-way (in debug mode forbidden bits show the error). 
I tried to write a test, but I don't know how to trigger 
array_ass_slice() with a write access, as it is not in array_as_sequence 
anymore (like in 2.7). How is slicing handled now?

--
components: Library (Lib), Tests
messages: 93581
nosy: chuck
severity: normal
status: open
title: Memory errors in array.array
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

[issue7042] test_signal fails on os x 10.6

[Mark Dickinson]

Mark Dickinson  added the comment:

> If this is about passing time, there should be better ways (than
> those which break if your computer gets faster).

Agreed.  The challenge is to find ways that don't add too much in the
way of extra complexity, fragility, or dependencies to the unit test.

How about replacing the xrange(1) loop with something like this,
which allows 30 seconds of real time and then fails with a timeout 
message:

start_time = time.time()
while time.time() - start_time < 5.0:

if signal.getitimer(self.itimer) == (0.0, 0.0):
break
else:
self.fail('timeout waiting for virtual timer signal')

--
assignee:  -> mark.dickinson

___
Python tracker 

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

[issue7042] test_signal fails on os x 10.6

[Mark Dickinson]

Mark Dickinson  added the comment:

Oops.  That 5.0 should have been 30.0, of course.

--

___
Python tracker 

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

[issue7063] Memory errors in array.array

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

The array type also defines tp_as_mapping->mp_ass_subscript, which has
priority in PyObject_SetItem().
A way to call array_ass_slice() is to use PySequence_SetItem(), but this
is hard to trigger from python code (it should be possible with ctypes).

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue5127] UnicodeEncodeError - I can't even see license

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Adam Olsen wrote:
> 
> Adam Olsen  added the comment:
> 
> Surrogates aren't optional features of UTF-16, we really need to get
> this fixed.  That includes .isalpha().

We use UCS2 on narrow Python builds, not UTF-16.

> We might keep the old public API for compatibility, but it should be
> clearly marked as broken for non-BMP scalar values.

That has always been the case. UCS2 doesn't support surrogates.

However, we have been slowly moving into the direction of making
the UCS2 storage appear like UTF-16 to the Python programmer.

This process is not yet complete and will likely never complete
since it must still be possible to create things line lone
surrogates for processing purposes, so care has to be taken
when using non-BMP code points on narrow builds.

> I don't see a problem with changing 2.x.  The existing behaviour is
> broken for non-BMP scalar values, so surely nobody can claim dependence
> on it.

No, but changing the APIs from 16-bit integers to 32-bit integers
does require a recompile of all code using it. Otherwise you
end up with segfaults.

Also, the Unicode type database itself uses Py_UNICODE, so
case mapping would fail for non-BMP code points.

So if we want to support accessing non-BMP type information
on narrow builds, we'd need to change the complete
Unicode type database API to work with UCS4 code points and then
provide a backwards compatible C API using Py_UNICODE. Due
to the UCS2/UCS4 API renaming done in unicodeobject.h, this
would amount to exposing both the UCS2 and the UCS4 variants
of the APIs on narrow builds.

With such an approach we'd not break the binary API and
still get the full UCS4 range of code points in the type
database. The change would be possible in Python 2.x and
3.x (which now both use the same strategy w/r to change
management).

Would someone be willing to work on this ?

--

___
Python tracker 

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

[issue7024] webbrowser : Could not open ftp server using webbrowser.open()

[Senthil Kumaran]

Senthil Kumaran  added the comment:

This bug is bit a tricky case.

Harshad: You might try the "work-around" suggested by Antoine. But that
is just a work-around. not a fix. Add an entry to gconf-editor like any
other. ( google).

The actual bug seems to be with gnome-open which is unable to handle ftp
urls.

$ gnome-open http://www.google.com
02:44 PM:senthil@:~/python/trunk/Lib
$ gnome-open ftp://ftp.freebsd.org
Error showing url: The specified location is not mounted

Google for (gnome-open + bug + ftp) you will be given the list of bugs.

In my case, I think the user-installed firefox has taken the control of
the ftp mimetype and in your case, gnome-open is the default and it is
failing with ftp.

As per suggestion just work-around it with ftp handlers and it should
do. May check with ubuntuforums for suggestions too.

There is a no problem with the webbrowser.py and I am closing this bug
as Invalid.

--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue5127] UnicodeEncodeError - I can't even see license

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

> No, but changing the APIs from 16-bit integers to 32-bit integers
> does require a recompile of all code using it.

Is it acceptable between 3.1 and 3.2 for example? ISTM that other
changes already require recompilation of extension modules.

> Also, the Unicode type database itself uses Py_UNICODE, so
> case mapping would fail for non-BMP code points.

Where, please? in unicodedata.c, getuchar and _getrecord_ex use Py_UCS4.

--

___
Python tracker 

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

[issue5127] UnicodeEncodeError - I can't even see license

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc  added the comment:
> 
>> No, but changing the APIs from 16-bit integers to 32-bit integers
>> does require a recompile of all code using it.
> 
> Is it acceptable between 3.1 and 3.2 for example? ISTM that other
> changes already require recompilation of extension modules.

With the proposed approach, we'll keep binary compatibility, so
this is not much of an issue.

Note: Changes to the binary interface can be done in minor releases,
but we should make sure that it's not possible to load an extension
compiled with 3.1 in 3.2 to prevent segfaults and buffer overruns.

>> Also, the Unicode type database itself uses Py_UNICODE, so
>> case mapping would fail for non-BMP code points.
> 
> Where, please? in unicodedata.c, getuchar and _getrecord_ex use Py_UCS4.

The change affects the Unicode type database which is implemented
in unicodectype.c, not the Unicode database, which already uses UCS4.

--

___
Python tracker 

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

[issue5127] UnicodeEncodeError - I can't even see license

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

> we should make sure that it's not possible to load an extension
> compiled with 3.1 in 3.2 to prevent segfaults and buffer overruns.

This is the case with this patch: today all these functions
(_PyUnicode_IsAlpha, _PyUnicode_ToLowercase) are actually #defines to
_PyUnicodeUCS2_* or _PyUnicodeUCS4_*.
The patch removes the #defines: 3.1 modules that call
_PyUnicodeUCS4_IsAlpha wouldn't load into a 3.2 interpreter.

> The change affects the Unicode type database which is implemented
> in unicodectype.c, not the Unicode database, which already uses UCS4.

Are you referring to the _PyUnicode_TypeRecord structure?
The first three fields only contains values up to 65535, so they could
use "unsigned short" even for UCS4 builds.
All the other uses are precisely changed by the patch...

--

___
Python tracker 

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

[issue5127] UnicodeEncodeError - I can't even see license

[Ezio Melotti]

Ezio Melotti  added the comment:

>> We might keep the old public API for compatibility, but it should be
>> clearly marked as broken for non-BMP scalar values.

> That has always been the case. UCS2 doesn't support surrogates.

> However, we have been slowly moving into the direction of making
> the UCS2 storage appear like UTF-16 to the Python programmer.

UCS2 died long ago, is there any reason why we keep using an UCS2 that
"appears" like UTF-16 instead of real UTF-16?

> This process is not yet complete and will likely never complete
> since it must still be possible to create things line lone
> surrogates for processing purposes, so care has to be taken
> when using non-BMP code points on narrow builds.

I don't exactly know all the details of the current implementation, but
-- from what I understand reading this (correct me if I'm wrong) -- it
seems that the implementation is half-UCS2 to allow things like the
processing of lone surrogates and half-UTF16 (or UTF-16-compatible) to
work with surrogate pairs and hence with chars outside the BMP.

What are the use cases for processing the lone surrogates? Wouldn't be
better to use UTF-16 and disallow them (since they are illegal) and
possibly provide some other way to deal with them (if it's really needed)?

--

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Ned Deily]

New submission from Ned Deily :

Due to a change in distutils released with Python 2.6.3, packages that 
use setuptools (version 0.6c9, as of this writing), or the easy_install 
command, to build C extension modules fail with a cryptic message ending 
with:
... .egg/setuptools/command/build_ext.py", line 85, in get_ext_filename 
ext = self.ext_map[fullname] KeyError: 

Among the packages known to be affected include lxml, zope-interface, 
jinja2, and, hence, packages dependent on these packages (e.g. sphinx, 
twisted, etc.).

The issue is described in greater detail in the Distribute project 
tracker:
http://bitbucket.org/tarek/distribute/issue/41/keyerror-_speedups

The solution there was to modify Distribute, a fork of setuptools, to 
accommodate the change in distutils.

An issue has been opened on the setuptools tracker for this problem:
http://bugs.python.org/setuptools/issue85

A discussion on the distutils-sig mailing list starts here:
http://mail.python.org/pipermail/distutils-sig/2009-October/013534.html

The distutils change forces affected users to either:
(1) migrate from setuptools to Distribute, which can generally done by
simply running:
  easy_install distribute
(2) avoid upgrading to 2.6.3 until a fix for setuptools is released
(or patch setuptools themselves)
(3) patch or downgrade distutils to restore the previous behavior

The primary purpose of this issue is to serve as a placeholder for users 
searching the Python issue tracker for this failure symptom.

--
assignee: tarek
components: Distutils
messages: 93591
nosy: barry, ned.deily, tarek
severity: normal
status: open
title: Python 2.6.3 / setuptools 0.6c9: extension module builds fail with 
KeyError
versions: Python 2.6

___
Python tracker 

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

[issue7042] test_signal fails on os x 10.6

[Jan Hosang]

Jan Hosang  added the comment:

I think a timing out while loop explains much better what is happening. I 
mean we are trying to keep the cpu busy for 0.9 seconds (if I understand 
the definition of virtual time correctly) and not do 1 increments 
(which might be done faster than 0.9 seconds).

--

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Tarek Ziadé]

Tarek Ziadé  added the comment:

> (3) patch or downgrade distutils to restore the previous behavior

This is not really an option since distutils code was modified to fix
some bugs, with no API change and no backward compat break. 

Users affected with this problems have to ask the Setuptools maintainer
to change the monkey-patches done on distutils and release a new
version, or have to use Distribute that fixes the problem and provide a
setuptools-compatible distribution.

As far as Distutils is concerned, its development and bug fixes will not
be frozen to make sure a 1 year old release of a tool that does
monkey-patches still work. It's up to this project to adapt its patches.

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

[issue5127] UnicodeEncodeError - I can't even see license

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc  added the comment:
> 
>> we should make sure that it's not possible to load an extension
>> compiled with 3.1 in 3.2 to prevent segfaults and buffer overruns.
> 
> This is the case with this patch: today all these functions
> (_PyUnicode_IsAlpha, _PyUnicode_ToLowercase) are actually #defines to
> _PyUnicodeUCS2_* or _PyUnicodeUCS4_*.
> The patch removes the #defines: 3.1 modules that call
> _PyUnicodeUCS4_IsAlpha wouldn't load into a 3.2 interpreter.

True, but we can do better. For narrow builds, the API currently
exposes the UCS2 APIs. We'd need to expose the UCS4 APIs *in addition*
to those APIs and have the UCS2 APIs redirect to the UCS4 ones.

For wide builds, we don't need to change anything.

>> The change affects the Unicode type database which is implemented
>> in unicodectype.c, not the Unicode database, which already uses UCS4.
> 
> Are you referring to the _PyUnicode_TypeRecord structure?
> The first three fields only contains values up to 65535, so they could
> use "unsigned short" even for UCS4 builds.

I haven't checked, but it's certainly possible to have a code point
use a non-BMP lower/upper/title case mapping, so this should be
made possible as well, if we're going to make changes to the type
database.

--

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[steve steiner]

Changes by steve steiner :


--
nosy: +ssteiner

___
Python tracker 

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

[issue5127] UnicodeEncodeError - I can't even see license

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

This is off-topic for the tracker item, but I'll reply anyway:

Ezio Melotti wrote:
> 
> Ezio Melotti  added the comment:
> 
>>> We might keep the old public API for compatibility, but it should be
>>> clearly marked as broken for non-BMP scalar values.
> 
>> That has always been the case. UCS2 doesn't support surrogates.
> 
>> However, we have been slowly moving into the direction of making
>> the UCS2 storage appear like UTF-16 to the Python programmer.
> 
> UCS2 died long ago, is there any reason why we keep using an UCS2 that
> "appears" like UTF-16 instead of real UTF-16?

UCS2 is how we store Unicode in Python for narrow builds internally.
It's a storage format, not an encoding.

However, on narrow builds such as the Windows builds, you will sometimes
want to create Unicode strings that use non-BMP code points. Since
both UCS2 and UCS4 can represent the UTF-16 encoding, it's handy to
expose a bit of automatic conversion at the Python level to make
things easier for the programmer.

>> This process is not yet complete and will likely never complete
>> since it must still be possible to create things line lone
>> surrogates for processing purposes, so care has to be taken
>> when using non-BMP code points on narrow builds.
> 
> I don't exactly know all the details of the current implementation, but
> -- from what I understand reading this (correct me if I'm wrong) -- it
> seems that the implementation is half-UCS2 to allow things like the
> processing of lone surrogates and half-UTF16 (or UTF-16-compatible) to
> work with surrogate pairs and hence with chars outside the BMP.
> 
> What are the use cases for processing the lone surrogates? Wouldn't be
> better to use UTF-16 and disallow them (since they are illegal) and
> possibly provide some other way to deal with them (if it's really needed)?

No, because Python is meant to be used for working on all Unicode
code points. Lone surrogates are not allowed in transfer encodings
such as UTF-16 or UTF-8, but they are valid Unicode code points and
you need to be able to work with them, since you may want to construct
surrogate pairs by hand or get lone surrogates as a result of slicing a
Unicode string.

--

___
Python tracker 

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

[issue5127] UnicodeEncodeError - I can't even see license

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

> We'd need to expose the UCS4 APIs *in addition*
> to those APIs and have the UCS2 APIs redirect to the UCS4 ones.

Why have two names for the same function? it's Python 3, after all.
Or is this "no recompile" feature so important (as long as changes are
clearly shown to the user)? It does not work on Windows, FWIW.

> I haven't checked, but it's certainly possible to have a code point
> use a non-BMP lower/upper/title case mapping, so this should be
> made possible as well, if we're going to make changes to the type
> database.

OK, here is a new patch.  Even if this does not happen with unicodedata
up to 5.1, the table has only 175 entries so memory usage is not
dramatically increased.
Py_UNICODE is no more used at all in unicodectype.c.

--
Added file: http://bugs.python.org/file15047/unicodectype_ucs4-2.patch

___
Python tracker 

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

[issue1571184] Generate numeric/space/linebreak from Unicode database.

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Marc-Andre, could you comment on this patch?
The comments above were made by inspecting the generated code, comparing
with the previous version.
IMO the only drawback is the increased memory usage.

--

___
Python tracker 

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

[issue1571184] Generate numeric/space/linebreak from Unicode database.

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


Added file: http://bugs.python.org/file15048/unicodectype_ucs4-2.patch

___
Python tracker 

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

[issue1571184] Generate numeric/space/linebreak from Unicode database.

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


Removed file: http://bugs.python.org/file15048/unicodectype_ucs4-2.patch

___
Python tracker 

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

[issue7063] Memory errors in array.array

[Jan Hosang]

Jan Hosang  added the comment:

The mp_ass_subscript function looks fine in contrast to array_ass_slice(). 
So if array_ass_slice() is not accessible from the outside and is only 
called with NULL as replacement parameter from the inside, I won't be able 
to cause trouble with those two issues.

Still I think it's bad to keep buggy code around, even it is not used. 
Maybe array_ass_slice() should be changed to what it's used for: 
array_del_slice()?

--

___
Python tracker 

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

[issue1571184] Generate numeric/space/linebreak from Unicode database.

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc  added the comment:
> 
> Marc-Andre, could you comment on this patch?
> The comments above were made by inspecting the generated code, comparing
> with the previous version.
> IMO the only drawback is the increased memory usage.

I haven't tried applying the patch, but from reading it, it looks
good.

--

___
Python tracker 

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

[issue7065] bytes.maketrans segfaults

[egreen]

New submission from egreen :

The new maketrans static method in Python 3.1 segfaults when using byte
values > 127.

Reproduce: bytes.maketrans(bytes(range(256)), b'X' * 256)

Cause: _Py_bytes_maketrans in Objects/bytes_methods.c uses signed int as
array index.

Fix attached. Also adds test.

--
components: Interpreter Core
files: maketrans_segfault.patch
keywords: patch
messages: 93599
nosy: egreen
severity: normal
status: open
title: bytes.maketrans segfaults
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15049/maketrans_segfault.patch

___
Python tracker 

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

[issue7060] test_multiprocessing dictionary changed size errors and hang

[Jesse Noller]

Jesse Noller  added the comment:

Adding gps - I haven't had a chance to grok the changes, and me getting to 
a fix is going to take a few.

--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue7065] bytes.maketrans segfaults

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Good catch!
Shouldn't the "i" variable be a "Py_ssize_t"?

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue7065] bytes.maketrans segfaults

[egreen]

egreen  added the comment:

Yes, it should indeed be a Py_ssize_t.

New patch.

--
Added file: http://bugs.python.org/file15050/bytes_maketrans_2.patch

___
Python tracker 

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

[issue5127] UnicodeEncodeError - I can't even see license

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc  added the comment:
> 
>> We'd need to expose the UCS4 APIs *in addition*
>> to those APIs and have the UCS2 APIs redirect to the UCS4 ones.
> 
> Why have two names for the same function? it's Python 3, after all.

It's not the same function... the UCS2 version would take a
Py_UNICODE parameter, the UCS4 version a Py_UCS4 parameter.

I don't understand the comment about Python 3.x. FWIW, we're no
longer in the backwards incompatible changes are allowed mode
for 3.x.

> Or is this "no recompile" feature so important (as long as changes are
> clearly shown to the user)? It does not work on Windows, FWIW.

There are generally two options for API changes within a
major release branch:

 1. the changes are API backwards compatible and only the Python API
version is changed

 2. the changes are not API backwards compatible; in such a case,
Python has to reject imports of old module (as it always
does on Windows), so the Python API version has to be changed
*and* the import mechanism must reject the import

The second option was used when transitioning from 2.4 to 2.5 due
to the Py_ssize_t changes.

We could do the same for 2.7/3.2, but if it's just needed for this
one change, then I'd rather stick to implementing the first option.

>> I haven't checked, but it's certainly possible to have a code point
>> use a non-BMP lower/upper/title case mapping, so this should be
>> made possible as well, if we're going to make changes to the type
>> database.
> 
> OK, here is a new patch.  Even if this does not happen with unicodedata
> up to 5.1, the table has only 175 entries so memory usage is not
> dramatically increased.
> Py_UNICODE is no more used at all in unicodectype.c.

Sorry, but this doesn't work: the functions have to return Py_UNICODE
and raise an exception if the return value doesn't fit.

Otherwise, you'd get completely wrong values in code downcasting
the return value to Py_UNICODE on narrow builds.

Another good reason to use two sets of APIs. The new set could
indeed return Py_UCS4 values.

--

___
Python tracker 

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

[issue7060] test_multiprocessing dictionary changed size errors and hang

[Jesse Noller]

Jesse Noller  added the comment:

It's passing for me on trunk/py3k at least on OS/X - I'm going to need to 
dredge up a linuxvm

--

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Guido van Rossum]

Guido van Rossum  added the comment:

Before we start pointing fingers or throwing mud, was this bug fix which 
apparently breaking setuptools introduced knowing that this would break 
setuptools users?

I'm surprised that nobody at all tried to use the release candidate with 
any of the listed packages.

Given the number of packages that use setuptools and have been widely 
distributed, I expect that even if a fixed version of setuptools was 
released tomorrow, the damage would already be done, and most people 
would just have to avoid 2.6.3.

How hard would it be to release a 2.6.4 which differs from 2.6.3 only by 
not breaking existing setuptools distros?

--
nosy: +gvanrossum

___
Python tracker 

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

[issue7058] Add some test execution environment protection to regrtest

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Apart from the comments I made on IRC, I think it would be nice to have
this patch in 2.6 and 3.1 as well. While not technically a bug fix, it
is innocuous for users and certainly helps finding problems.

--
nosy: +pitrou
versions: +Python 2.6, Python 3.1

___
Python tracker 

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

[issue7058] Add some test execution environment protection to regrtest

[R. David Murray]

R. David Murray  added the comment:

Updated patch based on Antoine's feedback on IRC.  Removes a mislaid
'not quiet' and restores argv using argv[:] = saved_argv.

I agree about putting it into 2.6/3.1.  We could also claim that it is
fixing a bug in the running of the tests :)  I suspect it might make the
buildbots more stable, for example.

--
Added file: http://bugs.python.org/file15051/regrtest_guards.patch

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Tarek Ziadé]

Tarek Ziadé  added the comment:

> Before we start pointing fingers or throwing mud, was this bug 
> fix which apparently breaking setuptools introduced knowing that 
> this would break setuptools users?
>
> I'm surprised that nobody at all tried to use the release candidate 
> with any of the listed packages.

The final release of 2.6.3 was done very shortly after the rc, so 
the community didn't have enough time to test their package with 
the rc.

What should have been done to avoid this (what what was suggested) is to
have a special buildbot for this that would run distutils commands over
a list of packages from the community.

I have a buidbot myself that does this, but it was discontinued lately 
because of a lack of CPU/Bandwidth.

> How hard would it be to release a 2.6.4 which differs from 2.6.3 
> only by not breaking existing setuptools distros?

I could work on this by making a special internal case in Distutils to
avoid calling the patched API that leads to the setuptools bug. This is
not hard and can be done quickly if required.

--
resolution: rejected -> 
status: closed -> open

___
Python tracker 

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

[issue7057] tkinter doc: more 3.x updates

[Terry J. Reedy]

Terry J. Reedy  added the comment:

A somewhat separate issue is the lack of even a mention of the existence
of the Canvas widget, which would merit a separate subsection if
documented. I think it should at least be mentioned with a reference to
the online reference materials listed before.

Indeed, the tkinter reference should somewhere have a complete list of
widgets, just like the ttk section does

24.2.2. Ttk Widgets¶

Ttk comes with 17 widgets, eleven of which already existed in tkinter:
Button, Checkbutton, Entry, Frame, Label, LabelFrame, Menubutton,
PanedWindow, Radiobutton, Scale and Scrollbar. The other six are new:
Combobox, Notebook, Progressbar, Separator, Sizegrip and Treeview. And
all them are subclasses of Widget.

--

___
Python tracker 

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

[issue5127] UnicodeEncodeError - I can't even see license

[Adam Olsen]

Adam Olsen  added the comment:

On Mon, Oct 5, 2009 at 03:03, Marc-Andre Lemburg  wrote:
> We use UCS2 on narrow Python builds, not UTF-16.
>
>> We might keep the old public API for compatibility, but it should be
>> clearly marked as broken for non-BMP scalar values.
>
> That has always been the case. UCS2 doesn't support surrogates.
>
> However, we have been slowly moving into the direction of making
> the UCS2 storage appear like UTF-16 to the Python programmer.
>
> This process is not yet complete and will likely never complete
> since it must still be possible to create things line lone
> surrogates for processing purposes, so care has to be taken
> when using non-BMP code points on narrow builds.

Balderdash.  We expose UTF-16 code units, not UCS-2.  Guido has made
this quite clear.

UTF-16 was designed as an easy transition from UCS-2.  Indeed, if your
code only does searches or joins existing strings then it will Just
Work; declare it UTF-16 and you are done.  We have a lot more work to
do than that (as in this bug report), and we can't reasonably prevent
the user from splitting surrogate pairs via poor code, but a 95%
solution doesn't mean we suddenly revert all the way back to UCS-2.

If the intent really was to use UCS-2 then a correctly functioning
UTF-16 codec would join a surrogate pair into a single scalar value,
then raise an error because it's outside the range representable in
UCS-2.  That's not very helpful though; obviously, it's much better to
use UTF-16 internally.

"The alternative (no matter what the configure flag is called) is
UTF-16, not UCS-2 though: there is support for surrogate pairs in
various places, including the \U escape and the UTF-8 codec."
http://mail.python.org/pipermail/python-dev/2008-July/080892.html

"If you find places where the Python core or standard library is doing
Unicode processing that would break when surrogates are present you
should file a bug. However this does not mean that every bit of code
that slices a string at an arbitrary point (and hence risks slicing in
the middle of a surrogate) is incorrect -- it all depends on what is
done next with the slice."
http://mail.python.org/pipermail/python-dev/2008-July/080900.html

--

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Tarek Ziadé]

Tarek Ziadé  added the comment:

Done in r75256

--

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Guido van Rossum]

Guido van Rossum  added the comment:

Thanks for the quick action Tarek!!!

--

___
Python tracker 

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

[issue7022] Doc update for io module

[Pascal Chambon]

Pascal Chambon  added the comment:

Thanks a lot B-)

--

___
Python tracker 

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

[issue5127] UnicodeEncodeError - I can't even see license

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Adam Olsen wrote:
> 
> Adam Olsen  added the comment:
> 
> On Mon, Oct 5, 2009 at 03:03, Marc-Andre Lemburg  
> wrote:
>> We use UCS2 on narrow Python builds, not UTF-16.
>>
>>> We might keep the old public API for compatibility, but it should be
>>> clearly marked as broken for non-BMP scalar values.
>>
>> That has always been the case. UCS2 doesn't support surrogates.
>>
>> However, we have been slowly moving into the direction of making
>> the UCS2 storage appear like UTF-16 to the Python programmer.
>>
>> This process is not yet complete and will likely never complete
>> since it must still be possible to create things line lone
>> surrogates for processing purposes, so care has to be taken
>> when using non-BMP code points on narrow builds.
> 
> Balderdash.  We expose UTF-16 code units, not UCS-2.  Guido has made
> this quite clear.
> 
> UTF-16 was designed as an easy transition from UCS-2.  Indeed, if your
> code only does searches or joins existing strings then it will Just
> Work; declare it UTF-16 and you are done.  We have a lot more work to
> do than that (as in this bug report), and we can't reasonably prevent
> the user from splitting surrogate pairs via poor code, but a 95%
> solution doesn't mean we suddenly revert all the way back to UCS-2.
> 
> If the intent really was to use UCS-2 then a correctly functioning
> UTF-16 codec would join a surrogate pair into a single scalar value,
> then raise an error because it's outside the range representable in
> UCS-2.  That's not very helpful though; obviously, it's much better to
> use UTF-16 internally.
> 
> "The alternative (no matter what the configure flag is called) is
> UTF-16, not UCS-2 though: there is support for surrogate pairs in
> various places, including the \U escape and the UTF-8 codec."
> http://mail.python.org/pipermail/python-dev/2008-July/080892.html
> 
> "If you find places where the Python core or standard library is doing
> Unicode processing that would break when surrogates are present you
> should file a bug. However this does not mean that every bit of code
> that slices a string at an arbitrary point (and hence risks slicing in
> the middle of a surrogate) is incorrect -- it all depends on what is
> done next with the slice."
> http://mail.python.org/pipermail/python-dev/2008-July/080900.html

All this is just nitpicking, really. UCS2 is a character set,
UTF-16 an encoding.

It so happens that when the Unicode consortium realized
that 16 bit would not be enough to represent all scripts of the
world, they added the concept of surrogates and reserved a few
ranges of code points in UCS2 to represent these extra code
points which are not part of UCS2, but the extensions UCS4.

The conversion of these surrogate pairs to UCS4 code point
values is what you find defined in UTF-16.

If we were to implement Unicode using UTF-16 as storage format,
we would not be able to store single lone surrogates, since these
are not allowed in UTF-16. Ditto for unassigned ordinals, invalid
code points, etc.

PEP 100 really says it all:

http://www.python.org/dev/peps/pep-0100/

"""
This [internal] format will hold UTF-16 encodings of the corresponding
Unicode ordinals.  The Python Unicode implementation will address
these values as if they were UCS-2 values. UCS-2 and UTF-16 are
the same for all currently defined Unicode character points.
...
Future implementations can extend the 16 bit restriction to the
full set of all UTF-16 addressable characters (around 1M
characters).
"""

Note that I wrote the PEP and worked on the implementation at a time
when Unicode 2.x was still in use wide-spread use (mostly on Windows)
and 3.0 was just being release:

http://www.unicode.org/history/publicationdates.html

But all that is off-topic for this ticket, so please let's just
stop such discussions.

--

___
Python tracker 

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

[issue7065] bytes.maketrans segfaults

[Brett Cannon]

Changes by Brett Cannon :


--
priority:  -> release blocker
type:  -> crash

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Phillip J. Eby]

Phillip J. Eby  added the comment:

I appreciate the change being made.  The specific code in setuptools is
relying on an erroneous reading of get_ext_filename()'s docstring (which
as of 2.3 at least, implied to me at least that it is always called with
an extension's full dotted name), and so I will fix it in setuptools as
well.

I would like to point out, however, that subclassing is not
"monkeypatching".  The distutils explicitly documents the ability to
extend and subclass commands, and this particular subclassing was based
on code provided by another distutils user, who'd extended build_ext to
support building dynamic libraries.

It is likely that that user, and anyone else who extended the build_ext
command in a similar way (e.g. numpy's and Twisted's distutils
extensions), could be affected by the change.

So, this was neither a matter of monkeypatching, nor special treatment
for setuptools.  Setuptools is far from the first or last distutils
extension ever written, and build_ext tends to get extended more than
most other commands.  It's important to remember subclassing use cases
when modifying distutils commands; subclasses inherently rely on a
stricter interface than a class's public API.

--
nosy: +pje

___
Python tracker 

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

[issue5127] UnicodeEncodeError - I can't even see license

[Adam Olsen]

Adam Olsen  added the comment:

On Mon, Oct 5, 2009 at 12:10, Marc-Andre Lemburg  wrote:
> All this is just nitpicking, really. UCS2 is a character set,
> UTF-16 an encoding.

UCS is a character set, for most purposes synonymous with the Unicode
character set.  UCS-2 and UTF-16 are both encodings of that character
set.  However, UCS-2 can only represent the BMP, while UTF-16 can
represent the full range.

> If we were to implement Unicode using UTF-16 as storage format,
> we would not be able to store single lone surrogates, since these
> are not allowed in UTF-16. Ditto for unassigned ordinals, invalid
> code points, etc.

No.  Internal usage may become temporarily ill-formed, but this is a
compromise, and acceptable so long as we never export them to other
systems.

Not that I wouldn't *prefer* a system that wouldn't store lone
surrogates, but.. pragmatics prevail.

> Note that I wrote the PEP and worked on the implementation at a time
> when Unicode 2.x was still in use wide-spread use (mostly on Windows)
> and 3.0 was just being release:
>
>        http://www.unicode.org/history/publicationdates.html

I think you hit the nail on the head there.  10 years ago, unicode
meant something different than it does today.  That's reflected in PEP
100 and in the code.  Now it's time to move on, switch to the modern
terminology, modern usage, and modern specs.

> But all that is off-topic for this ticket, so please let's just
> stop such discussions.

It needs to be discussed somewhere.  It's a distraction from fixing
the bug, but at least it's more private here.  Would you prefer email?

--

___
Python tracker 

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

[issue7052] "from logging import *" causes an error under Ubuntu Karmic

[Sridhar Ratnakumar]

Changes by Sridhar Ratnakumar :


--
nosy: +srid

___
Python tracker 

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

[issue7066] archive_util.make_archive doesn't restore the cwd if an error is raised

[Ezio Melotti]

New submission from Ezio Melotti :

archive_util.make_archive() changes the value of the cwd, but if an
error is raised in "filename = func(base_name, base_dir, **kwargs)", the
cwd is not restored. This may happen if zlib is not available and causes
other ~60 tests to fail while running regrtest.py.

This trivial fix solve the problem here:

-filename = func(base_name, base_dir, **kwargs)
-if root_dir is not None:
-log.debug("changing back to '%s'", save_cwd)
-os.chdir(save_cwd)
+try:
+filename = func(base_name, base_dir, **kwargs)
+finally:
+if root_dir is not None:
+log.debug("changing back to '%s'", save_cwd)
+os.chdir(save_cwd)

The new test_make_archive_owner_group() test added in r75192 also needs
a @unittest.skipUnless(zlib, "Requires zlib"), otherwise dist_distutils
fails.
Since half of this test doesn't require zlib (i.e. when 'tar' is used)
it might be a good idea to split the test in two, in order to test the
'tar' archives even if 'zlib' is not available.

(Thanks to R. David Murray - he spot the right place where the cwd is
changed and not restored.)

--
assignee: tarek
components: Distutils
messages: 93618
nosy: ezio.melotti, r.david.murray, tarek
priority: normal
severity: normal
status: open
title: archive_util.make_archive doesn't restore the cwd if an error is raised
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue7057] tkinter doc: more 3.x updates

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This "The authors strongly suggest getting a copy of the Tk man pages. "
should be followed by a mention that they are available at the active
state site, in particular, at http://www.tcl.tk/man/tcl8.5/

--

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Tarek Ziadé]

Changes by Tarek Ziadé :


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

___
Python tracker 

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

[issue7066] archive_util.make_archive doesn't restore the cwd if an error is raised

[Tarek Ziadé]

Changes by Tarek Ziadé :


--
resolution:  -> accepted

___
Python tracker 

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

[issue7067] Suggest better documentation of 2 versus 3 on 3.1.1 site.

[Steven R. Loomis]

New submission from Steven R. Loomis :

It would be nice if http://www.python.org/download/releases/3.1.1/ had 
the '3 vs 2' explanation made more prominent, just as it was in the 3.0. 
Maybe I've been living under a rock, but I didn't realize that 3 was 
such a change.  Maybe the words 'backwards-incompatible' could be a link 
to  http://docs.python.org/dev/3.0/whatsnew/3.0.html  which explained 
things quite nicely.  You could also add something on the home page, 
with a link to that same page under the title "3 versus 2?"  

Please consider the scenario where someone "needs python installed" to 
run an existing program, and they go to http://www.python.org - wanting 
to download the latest version would be the logical thing to do.  You 
could use this opportunity to suggest running the 2to3 converter and so 
upgrading their existing program.  Again, the 3.1.1 release page doesn't 
have the link to 2to3, but 3.0 does.

Thank you for your consideration.

--
assignee: georg.brandl
components: Documentation
messages: 93620
nosy: georg.brandl, srl
severity: normal
status: open
title: Suggest better documentation of 2 versus 3 on 3.1.1 site.
type: feature request
versions: Python 3.1

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Sridhar Ratnakumar]

Changes by Sridhar Ratnakumar :


--
nosy: +srid

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Can this go into 2.6.4?

--
assignee:  -> barry
nosy: +rhettinger

___
Python tracker 

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

[issue7066] archive_util.make_archive doesn't restore the cwd if an error is raised

[Tarek Ziadé]

Tarek Ziadé  added the comment:

I see two distinct points (besides test_make_archive_owner_group):

1- having a try..finally when changing the current working dir (I'll do
this thanks for the patch)

2- dealing with calls made on archive_util.make_archive() when zlib is
not available. What error do you get ? CompressionError I guess ?

--

___
Python tracker 

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

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

[Raymond Hettinger]

Raymond Hettinger  added the comment:

2.6.4?

--
assignee:  -> barry
nosy: +rhettinger

___
Python tracker 

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

[issue7066] archive_util.make_archive doesn't restore the cwd if an error is raised

[Ezio Melotti]

Ezio Melotti  added the comment:

==
ERROR: test_make_archive_owner_group
(distutils.tests.test_archive_util.ArchiveUtilTestCase)
--
Traceback (most recent call last):
  File "/home/wolf/dev/trunk/Lib/distutils/tests/test_archive_util.py",
line 224, in test_make_archive_owner_group
group=group)
  File "/home/wolf/dev/trunk/Lib/distutils/archive_util.py", line 237,
in make_archive
filename = func(base_name, base_dir, **kwargs)
  File "/home/wolf/dev/trunk/Lib/distutils/archive_util.py", line 163,
in make_zipfile
compression=zipfile.ZIP_DEFLATED)
  File "/home/wolf/dev/trunk/Lib/zipfile.py", line 675, in __init__
"Compression requires the (missing) zlib module"
RuntimeError: Compression requires the (missing) zlib module

--

___
Python tracker 

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

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

>From http://bugs.python.org/msg93606 .. it seems that 2.6.4 may happen 
very soon.

--

___
Python tracker 

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

[issue5395] array.fromfile not checking I/O errors

[Eduardo Aguiar]

Eduardo Aguiar  added the comment:

Maybe you could create a file without read permission (000) and try
to read from it.

--

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Ned Deily]

Ned Deily  added the comment:

UPDATE for users: With the change to distutils now added in r75256 and a 
2.6.4 release in the works, option (3) in the original message should now 
read:

(3) patch distutils to restore the previous behavior or
install Python 2.6.4 which is expected to be released within a
few weeks

--

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

> a 2.6.4 release in the works

Is this going to have a rc1 as usual? Have we decided on the dates both 
for rc1 and final?

--

___
Python tracker 

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

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

yes.  rc1 on 6 oct 2009 and final on 18 oct 2009 (tentative)

--

___
Python tracker 

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

[issue7068] 2.6.3 does not use specified compiler

[Shun-ichi Goto]

New submission from Shun-ichi Goto :

I installed python 2.6.3 on windows from .msi installer and get problem
to build ext modules with MinGW compiler.

It seems that Python 2.6.3 does not use compiler specified by user
via --compiler=xxx or setup.cfg on building ext module. Thus, MSVC
compiler is always used or show unreasonable error message
"error: Unable to find vcvarsall.bat" although specifying
--compiler=mingw32.

I found the change of r72594 cause this issue.

  [projects] Diff of
/python/branches/release26-maint/Lib/distutils/command/build_ext.py
 
http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/command/build_ext.py?view=diff&r1=72593&r2=72594

And following patch get the behaviour like before, but I don't 
see why this change is introduced (merged from trunk).

{{{
diff -r 5874f642b473 distutils/command/build_ext.py
--- a/distutils/command/build_ext.pyTue Oct 06 10:39:34 2009 +0900
+++ b/distutils/command/build_ext.pyTue Oct 06 10:43:14 2009 +0900
@@ -303,7 +303,7 @@
 
 # Setup the CCompiler object that we'll use to do all the
 # compiling and linking
-self.compiler = new_compiler(compiler=None,
+self.compiler = new_compiler(compiler=self.compiler,
  verbose=self.verbose,
  dry_run=self.dry_run,
  force=self.force)

}}}

Is there any changes the way to specifying compiler?

--
assignee: tarek
components: Distutils
messages: 93630
nosy: gotoh, tarek
severity: normal
status: open
title: 2.6.3 does not use specified compiler
versions: Python 2.6

___
Python tracker 

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

[issue7069] inspect.isabstract to return boolean values only

[Gabriel Genellina]

New submission from Gabriel Genellina :

Currently, inspect.isabstract() may return an integer like 1048576 
instead of True, or 0 instead of False.

Although technically correct, no other isXXX function behaves that way; 
also, isgeneratorfunction() uses a similar code construct but casts the 
result into a boolean.

The attached patch makes inspect.isabstract() return a boolean value 
always.

--
components: Library (Lib)
files: inspect.diff
keywords: patch
messages: 93631
nosy: gagenellina
severity: normal
status: open
title: inspect.isabstract to return boolean values only
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15052/inspect.diff

___
Python tracker 

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

[issue5395] array.fromfile not checking I/O errors

[Jan Hosang]

Jan Hosang  added the comment:

> Maybe you could create a file without read permission (000) and try
> to read from it.

I just checked. If I don't have read permissions, I am not able to open 
the file. When I open a file and change permissions afterwards, I can read 
the complete file alright. (Checked with a 4mb file, I hope that's beyond 
buffering.) So I guess permissions are only checked when you open the 
file.

--

___
Python tracker 

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

[issue7069] inspect.isabstract to return boolean values only

[Jan Hosang]

Jan Hosang  added the comment:

The patch works, as this is what is implicitly happening anyway if you use 
the function. There seem to be no tests for this function, so there is 
nothing to break. I guess this is the right time to get some tests. 

Gabriel, would you like to write tests for this function?

--
nosy: +chuck

___
Python tracker 

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