[issue6206] Correct a trivial typo introduced by r73238.

[Georg Brandl]

Georg Brandl  added the comment:

Fixed in r73252.

--
nosy: +georg.brandl
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

[issue6206] Correct a trivial typo introduced by r73238.

[Vikram U Shenoy]

Changes by Vikram U Shenoy :


--
type:  -> compile error

___
Python tracker 

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

[issue6218] Make io.BytesIO and io.StringIO picklable.

[Alexandre Vassalotti]

New submission from Alexandre Vassalotti :

Here is a patch to add pickling support to io.BytesIO and io.StringIO.
Although they are non-trivial, the additions were made with a fair
amount of care (and love!) and thus I believe they could be included in
3.1. 

Furthermore, the improved test-suite uncovered a number of bugs in the
implementation of io.StringIO. So the patch also fixes:

  * fixes a memory-leak in stringio_dealloc; 
  * disallows bytes-like object from being used as the newline
argument of StringIO;
  * and changes the exception raised by StringIO.__init__ to a
TypeError when initial_value is not a str.

--
components: IO, Library (Lib)
files: pickle_support_for_memoryio.diff
keywords: patch, patch
messages: 88987
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Make io.BytesIO and io.StringIO picklable.
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14202/pickle_support_for_memoryio.diff

___
Python tracker 

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

[issue6217] Add _io._TextIOWrapper.errors

[Philip Jenvey]

New submission from Philip Jenvey :

_pyio.TextIOWrapper provides the encoding and associated errors values, 
but _io._TextIOWrapper only provides encoding. Patch adds errors and has 
it show up in repr in both places, against py3k

--
components: IO
files: textiowrapper-errors.diff
keywords: patch
messages: 88986
nosy: pitrou, pjenvey
severity: normal
status: open
title: Add _io._TextIOWrapper.errors
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14201/textiowrapper-errors.diff

___
Python tracker 

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

[issue6196] tarfile.extractall(readaccess=True)

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

[Lars] Sure, there is some functionality in extractall() that addresses
issues with inappropriate permissions, but without this functionality the
archive would not even *extract* cleanly. That is very different from
your problem.

Fair enough.

'tis time to creating a pypi package out of my high-level wrapper:

  http://gist.github.com/124597

--

___
Python tracker 

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

[issue6195] Serious regression in doctest in Py3.1rc1

[R. David Murray]

R. David Murray  added the comment:

The fix is not in fact correct.  Without the fix, source code is found
that is skipped with the fix in place.  This may mean that the fix for
issue4050 is also in error.

The object found by inspect.getfile when it isn't an a .so is of the form:

   

So I think we need some way to determine whether or not what is returned
by getfile is binary data or not.

--
resolution: accepted -> 
stage: patch review -> needs patch

___
Python tracker 

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

[issue1943] improved allocation of PyUnicode objects

[Terry J. Reedy]

Terry J. Reedy  added the comment:

In the interest of possibly improving the imminent 3.1 release,
I opened #6216
Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?

I wonder if it is possible to make it generically easier to subclass
PyVarObjects (but my C knowledge to getting too faded to have any ideas).

--
nosy: +tjreedy

___
Python tracker 

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

[issue6216] Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Marc-Andre Lemburg's message is from #1943

--

___
Python tracker 

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

[issue6216] Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?

[Terry J. Reedy]

New submission from Terry J. Reedy :

>From msg88801
'''
for 3.1: raising the KEEPALIVE_SIZE_LIMIT to 32 as explained and
motivated here:

msg64215

That's a simple non-disruptive change which makes a lot of sense
due to the advances in CPU designs in the last 9 years. I determined
the original value of 9 using benchmarks and similar statistics in
1999/2000.

It's probably also a good time to remove the warning, now that the
implementation has proven itself for so many years...

/* Limit for the Unicode object free list stay alive optimization.

   The implementation will keep allocated Unicode memory intact for
   all objects on the free list having a size less than this
   limit. This reduces malloc() overhead for small Unicode objects.

   At worst this will result in PyUnicode_MAXFREELIST *
   (sizeof(PyUnicodeObject) + KEEPALIVE_SIZE_LIMIT +
   malloc()-overhead) bytes of unused garbage.

   Setting the limit to 0 effectively turns the feature off.

   Note: This is an experimental feature ! If you get core dumps when
   using Unicode objects, turn this feature off.

*/

#define KEEPALIVE_SIZE_LIMIT   9
'''
If this is as non-controversial as it seems, perhaps someone could
change 9 to 32 and remove "Note: This is an experimental feature..." in
time for rc2.

--
components: Interpreter Core
messages: 88981
nosy: tjreedy
severity: normal
status: open
title: Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
type: resource usage
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

[issue6198] test_float fails on Windows

[Eric Smith]

Eric Smith  added the comment:

> [Mark]
>> Out of interest, what does '%#.0f' % 1.5 produce on
>> Python 2.7/Windows?  I'd expect to get '2.' both for
>> round-half-to-even and round-half-away-from-zero.
>> Does Windows round this down to '1.' instead?
> 
> [Eric]
>> Windows in trunk gives '2.'.
> 
[Mark]
> Thanks.  I was mainly wondering why you'd commented out the
> line "%#.0f 1.5 -> 2." in the formatfloat_testcases.txt
> file.

Over-zealous commenting out on my part. I'm away from my Windows box,
but I'll correct this next week and check it back in with that line
re-enabled.

Thanks for catching that.

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

___
Python tracker 

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

[issue2768] os.fstat and other os.f* methods should use PyObject_AsFileDescriptor

[Neil Muller]

Neil Muller  added the comment:

Similar patch for the python 3 branch.

--
Added file: http://bugs.python.org/file14200/posixmodule_comb_py3k.patch

___
Python tracker 

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

[issue6202] Obsolete default file encoding "mac-roman" on OS X, not influenced by locale env variables

[Ned Deily]

Ned Deily  added the comment:

A very quick test of the patch on trunk for 10.4 and 10.5 looks good, 
though it should be re-tested once the unrelated current breakage of 
test__locale is fixed.

--

___
Python tracker 

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

[issue1633605] logging module / wrong bytecode?

[venkat manian]

Changes by venkat manian :


--
nosy: +annacoder

___
Python tracker 

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

Re: [issue3959] Add Google's ipaddr.py to the stdlib

[Raymond Hettinger]

My hope is that now that a library has been selected, it can be improved 
before Python 2.7 and 3.1 ship.


That is fairly unlikely. The 3.1 release candidate has been produced,
so the only options possible at this point are to either go ahead with
what is in the code, or withdraw the library from 3.1 if it can be
demonstrated to have severe flaws.


I concur with Martin here.  The only choices are to
keep it as-is or cleanly rip it out of the release.


Raymond

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

[issue2768] os.fstat and other os.f* methods should use PyObject_AsFileDescriptor

[Neil Muller]

Neil Muller  added the comment:

Updated combined patch for python trunk added (indentation issues
hopefully also fixed).

--
Added file: http://bugs.python.org/file14199/posixmodule_comb.patch

___
Python tracker 

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

[issue6215] Backport the IO lib to trunk

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Please note that test_io leaks references because of #2521. Otherwise
it's fine.

--
nosy: +alexandre.vassalotti, amaury.forgeotdarc, benjamin.peterson

___
Python tracker 

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

[issue6212] piped input

[Georg Brandl]

Georg Brandl  added the comment:

This is a bug in Windows Python can do nothing about, see
http://support.microsoft.com/kb/321788.

--
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue6215] Backport the IO lib to trunk

[Antoine Pitrou]

New submission from Antoine Pitrou :

The new IO lib has undergone deep changes in py3k which have never been
backported to trunk. This patch brings trunk up to date, including tests.

--
components: IO
files: iobackport.patch
keywords: patch
messages: 88974
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Backport the IO lib to trunk
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14198/iobackport.patch

___
Python tracker 

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

[issue6214] test__locale broken on trunk

[Antoine Pitrou]

New submission from Antoine Pitrou :

==
ERROR: test_lc_numeric_localeconv (test.test__locale._LocaleTests)
--
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test__locale.py", line
88, in test_lc_numeric_localeconv
"thousands_sep"):
ValueError: too many values to unpack

--
assignee: ocean-city
components: Tests
messages: 88973
nosy: ocean-city, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test__locale broken on trunk
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue6213] Incremental encoder incompatibility between 2.x and py3k

[Antoine Pitrou]

New submission from Antoine Pitrou :

The behaviour of several incremental encoders is inconsistent between
2.x and py3k.

In 2.x:
>>> enc = codecs.getincrementalencoder('utf-16')()
>>> enc.getstate()
0
>>> enc.setstate(0)
>>> enc.encode(u'abc')
'\xff\xfea\x00b\x00c\x00'

In py3k:
>>> enc = codecs.getincrementalencoder('utf-16')()
>>> enc.getstate()
2
>>> enc.setstate(0)
>>> enc.encode('abc')
b'a\x00b\x00c\x00'

--
messages: 88972
nosy: pitrou
priority: normal
severity: normal
status: open
title: Incremental encoder incompatibility between 2.x and py3k
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

[issue6198] test_float fails on Windows

[Mark Dickinson]

Mark Dickinson  added the comment:

[Mark]
> Out of interest, what does '%#.0f' % 1.5 produce on
> Python 2.7/Windows?  I'd expect to get '2.' both for
> round-half-to-even and round-half-away-from-zero.
> Does Windows round this down to '1.' instead?

[Eric]
> Windows in trunk gives '2.'.

Thanks.  I was mainly wondering why you'd commented out the
line "%#.0f 1.5 -> 2." in the formatfloat_testcases.txt
file.

[Eric, about zero formatting on Windows]
> So this isn't a problem we caused with the short repr work, it's 
> pre-existing. I don't think it's worth working around, but that's me.

I agree it doesn't seem worth working around.  Let's wait until
somebody complains. :-)

--

___
Python tracker 

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

[issue6212] piped input

[Robert T McQuaid]

New submission from Robert T McQuaid :

#
#  Python 3.0.1 can read piped input when invoked with a
#  program name as the argument of the interpreter, but not
#  when invoked implicitly by the file extension.  On
#  Windows xp the first command below runs successfully, the
#  second ends with a diagnostic:  'NoneType' object has no
#  attribute 'isatty'
#
#
#  dir | e:\python30\python test17.py
#  dir | test17.py
#
#

import sys
if sys.stdin.isatty(): pass

--
components: IO
messages: 88970
nosy: rtmq
severity: normal
status: open
title: piped input
type: behavior
versions: Python 3.0

___
Python tracker 

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

[issue6211] [Tutorial] Section 4.7.2 has a wrong description of an example

[Michael Markert]

New submission from Michael Markert :

[Tutorial] Section 4.7.2 has a piece of example code which gives three
possibilities to call that function, but the description states that
there are only two possibilities.

Attached patch changes that and gives the third possibility of calling.

--
assignee: georg.brandl
components: Documentation
files: controlflow.patch
keywords: patch
messages: 88969
nosy: cofi, georg.brandl
severity: normal
status: open
title: [Tutorial] Section 4.7.2 has a wrong description of an example
versions: Python 3.1
Added file: http://bugs.python.org/file14197/controlflow.patch

___
Python tracker 

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

[issue6136] Make logging configuration files easier to use

[Geoffrey Bache]

Geoffrey Bache  added the comment:

Who said anything about not supporting users who want the hierarchy? I'm
talking about making "qualname" optional, not removing it
entirely! I even supplied the entirety of the code (all 4 lines of it)
to be clear what I meant a few comments ago.

The files have gone from about 5kb to about 15kb. Of course diskspace is
not a problem in itself, but these files need to be read and edited by
non-coders and they're a lot scarier (and harder to tweak) than the old
ones were. Basically they're full of abstract technical concepts
("qualname", "handler") and bits of python code to be eval'ed. 

Yes, I can write my own format. But I can't see anything about my case
which is unusual and I'm sure there must be a demand for something
simpler, which is why I bothered to report this issue at all. 

It's not particularly hard to find people out there raising this if you
google a bit. But I shall raise this on comp.lang.python as you suggest.

--
status: pending -> open

___
Python tracker 

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

[issue6196] tarfile.extractall(readaccess=True)

[Lars Gustäbel]

Lars Gustäbel  added the comment:

Sure, tarfile contains numerous work-arounds for quirky and buggy
archives. Otherwise, it would not be usable in real-life.

But we should not mix up different issues here. tarfile reads and
extracts your generator_tools.tar just fine. Formally, the data is okay.
It's the stored information that is useless and that you are not happy
with. But as we both agree it is rather simple to fix this information
in advance:

import tarfile
tar = tarfile.open("generator_tools-0.3.5.tar.gz")
for t in tar:
if t.isdir():
t.mode = 0755
else:
t.mode = 0644
tar.extractall()
tar.close()

Sure, there is some functionality in extractall() that addresses issues
with inappropriate permissions, but without this functionality the
archive would not even *extract* cleanly. That is very different from
your problem.

In my opinion, the code above illustrates quite well, that tarfile was
designed to be high-level and flexible at the same time. Make use of
that. I honestly think that extractall() can do well without a
readaccess argument.

--

___
Python tracker 

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

[issue6210] Exception Chaining missing method for suppressing context

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
versions: +Python 3.2 -Python 3.0

___
Python tracker 

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

[issue6209] compilation error in std. lib. module shutil (Python 3.1rc1, platform Win32)

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r73250.

--
nosy: +benjamin.peterson
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

[issue6210] Exception Chaining missing method for suppressing context

[Patrick W.]

New submission from Patrick W. :

I'm currently writing a library that executes predefined http requests
to a specified server. In case there is for example a HTTP Error, I want
to raise a user-defined exception that contains additional information
about when the error actually occured (so that the user of that library
gets information what happened without having to look at the actual
library code).
The in Python 3 introduced "feature" of chained exceptions (PEP 3134) is
something which is a bit annoying in that particular situation. While it
is probably good in a lot situation to know where an exception comes
from (especially when they are chained), it makes reading the actual
exception for the library user harder.
Let me show you an example:

def doXY ():
  # ...
  try:
page = urlopen( someRequest )
  except urllib.error.URLError as e:
raise MyError( 'while doing XY', e )
  # ...

MyError is an exception class, that uses the second parameter to get
additional information (for HTTPErrors the status code for example) and
compiles a detailed error message.
Before Python 3, this was a good way to prevent users from having to dig
into the code when they encounter an exception. Now however, you get
some error message like this:

-
Traceback (most recent call last):
  File "..", line ., in doXY
page = urlopen( someRequest )
  File "..\lib\urllib\request.py", line 122,
in urlopen
return _opener.open(url, data, timeout)
  File "..\lib\urllib\request.py", line 364,
in open
response = meth(req, response)
  File "..\lib\urllib\request.py", line 476,
in http_response
'http', request, response, code, msg, hdrs)
  File "..\lib\urllib\request.py", line 402,
in error
return self._call_chain(*args)
  File "..\lib\urllib\request.py", line 336,
in _call_chain
result = func(*args)
  File "..\lib\urllib\request.py", line 484,
in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 401: Unauthorized

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "..", line ., in 
doXY()
  File "..", line ., in doXY
raise MyError( 'while doing XY', e )
MyError: 'HTTP Error 401 while doing XY (Unauthorized)'
-

While the error message of MyError would be completely sufficient for
the user to know (and to fix by simply giving correct data) he is
flooded with a lot of information about the previously raised exception
instead with far too many unneccessary information.

So what I basically would like to have is some mechanism to prevent
Python from printing out all previous exception. As there is already the
'raise NewException from PreviousException' syntax, something like
'raise NewException from None' would be great, with explicitely stating
None to clear the buffer of previous exceptions.


Thanks you for any comments on this issue.
Patrick W.

--
components: Interpreter Core
messages: 88965
nosy: poke
severity: normal
status: open
title: Exception Chaining missing method for suppressing context
type: feature request
versions: Python 3.0

___
Python tracker 

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

[issue6209] compilation error in std. lib. module shutil (Python 3.1rc1, platform Win32)

[dpodbori]

New submission from dpodbori :

In Python 3.1rc1 (observed under Win32) standard library function 
shutil.copyfile(src, dst) has an unreferenced local variable "st" that 
causes the following exception in the calling code:

D:\> c:\Python31\python.exe copyDrivers.py
Traceback (most recent call last):
  File "copyDrivers.py", line 20, in 
shutil.copy( file1, file2)
  File "c:\Python31\lib\shutil.py", line 101, in copy
copyfile(src, dst)
  File "c:\Python31\lib\shutil.py", line 62, in copyfile
if stat.S_ISFIFO(st.st_mode):
UnboundLocalError: local variable 'st' referenced before assignment

--
components: Library (Lib)
messages: 88964
nosy: dpodbori
severity: normal
status: open
title: compilation error in std. lib. module shutil (Python 3.1rc1, platform 
Win32)
type: compile error
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

[issue6136] Make logging configuration files easier to use

[Vinay Sajip]

Vinay Sajip  added the comment:

"As for (b), do you not think a large number of users will not bother
with the hierarchical aspect of the logging framework? I'd say you need
to be pretty advanced/large scale before that becomes interesting."

I disagree with this. The hierarchical set up is one of the key points
of the approach. Casual users may not use it, but there are a lot of
users who do - and not only on advanced or large-scale systems. Users wh
o don't need hierarchies don't have to use them, but the system has to
support those who find them useful. 

"I don't really understand why accepting such a patch would be a
problem, as it's a simple change that wouldn't break backwards
compatibility. It's surely got to be better than exiting with a python
stack, which is what happens today."

Any software might result in an exception if you don't interface to it
in the expected and documented way. And, in my previous comment, I
merely set some conditions which a patch would have to meet. Also, as it
is definitely the case that many users use the hierarchical feature,
even if you don't, I expect that the qualname setting will stay.

"(To give an idea of the bloat-factor, since migrating to the logging
framework a typical configuration file for my system is now roughly 3
times the size it used to be for the same functionality)"

How big is that in KB? Disk space is pretty cheap these days. If it is a
big problem for you, you can always try using your existing
configuration format, reading it yourself and using the programmatic API
to configure logging yourself. It should be a small bit of up-front work
which can then be used on all your future projects.

--
status: open -> pending

___
Python tracker 

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

[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0

[R. David Murray]

R. David Murray  added the comment:

Can you provide a test case that clearly demonstrates the problem
(preferably a unit test, but anything easily reproducible will do)?  I'm
not sure what to do with the code attached to the case.

--
nosy: +r.david.murray
priority:  -> high
stage:  -> test needed

___
Python tracker 

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

[issue6208] path separator output ignores shell's path separator: / instead of \

[R. David Murray]

R. David Murray  added the comment:

I'm not sure I understand the quesiton.  The cygwin path separator is
forward slash, isn't it?  Beyond that, I'm not clear on what behavior
you think is incorrect.  What "outputs"?

--
components: +Installation -IO
nosy: +r.david.murray
priority:  -> normal
type:  -> behavior

___
Python tracker 

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

[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0

[Timothy Farrell]

Timothy Farrell  added the comment:

I'm working on a web framework for Python 3.  Naturally this is a
blocker for me.  I was kinda expecting this to be addressed in 3.1 but
now that rc1 is out and I don't see anything about it, I'm wondering
about the status of this bug.  Can we get a status update?

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

[issue6136] Make logging configuration files easier to use

[Geoffrey Bache]

Geoffrey Bache  added the comment:

OK, I hadn't seen the "delay" parameter until now. I guess this is new
in Python 2.6? Good that there is already a way to avoid lots of empty
files, though it'll be a while before I can assume Python 2.6
unfortunately... that probably renders point (a) moot.

As for (b), do you not think a large number of users will not bother
with the hierarchical aspect of the logging framework? I'd say you need
to be pretty advanced/large scale before that becomes interesting.

I don't really understand why accepting such a patch would be a problem,
as it's a simple change that wouldn't break backwards compatibility.
It's surely got to be better than exiting with a python stack, which is
what happens today.

(To give an idea of the bloat-factor, since migrating to the logging
framework a typical configuration file for my system is now roughly 3
times the size it used to be for the same functionality)

--
status: pending -> open

___
Python tracker 

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

[issue6208] path separator output ignores shell's path separator: / instead of \

[ThurnerRupert]

Changes by ThurnerRupert :


--
components: +IO, Windows

___
Python tracker 

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

[issue6208] path separator output ignores shell's path separator: / instead of \

[ThurnerRupert]

New submission from ThurnerRupert :

when installing python for windows and running it from a msys or cygwin
shell, python does not notice that the path separator is backslash "/"
instead of forward slash "\".

can this be configured somehow, so the outputs are done like the current
shell accepts it? like checking in
http://docs.python.org/library/os.path.html what the parent process accepts?

--
messages: 88958
nosy: ThurnerRupert
severity: normal
status: open
title: path separator output ignores shell's path separator: / instead of \
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

[issue6202] Obsolete default file encoding "mac-roman" on OS X, not influenced by locale env variables

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Here's a patch. (for the trunk as it is also afflicted) It simply
removes the specific mac cases and uses posix detection.

--
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file14196/fix_mac_encoding.patch

___
Python tracker 

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

[issue6196] tarfile.extractall(readaccess=True)

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

[Lars] (...) We talk about a very small number of cases here and the
generator_tools-0.3.5.tar.gz is really broken beyond repair. It is the
only thing that should be fixed here IMO ;-)

Sure, that is what the pyopenssl folks did - fix their tarball. However,
it is reasonable expect certain tarballs to be 'broken beyond repair'
when you are running tarfile.extracall over a huge number of tarballs
such as the ones in PyPI.

Indeed, the tarfile module already has several fixes for such 'broken'
cases, Viz:

[quote]'If ignore_zeros is False, treat an empty block as the end of the
archive. If it is True, skip empty (and invalid) blocks and try to get
as many members as possible. This is only useful for reading
concatenated or **damaged** archives.'[endquote] [emphasis added]

[quote]'(...)Directory information like owner, modification time and
permissions are set after all members have been extracted. This is done
to work around two problems: A directory’s modification time is reset
each time a file is created in it. And, if a directory’s **permissions
do not allow writing**, extracting files to it will fail'[endquote]
[emphasis added]

[Lars] I agree with David here. It is easy to manipulate the tarfile in
advance, as you have shown yourself. The performance argument does not
convince me either.

Ok. Can you comment on this argument?

[quote]'(...)the very reason to write a program to extract tarball
(instead of doing it manually) is to automate it .. which automation is
*more effective and simple* if ``extractall`` had a flag such as
readaccess=True'[endquote] (emphasis added)

[quote]'I just think it is not simple (as in, keeping the code off from
such hacks that are tangential to the problem being solved) and
effective (as in, not having to deal with potential unintended side
effects like bugs in the post-fix chmoding or in the pre-fix tarinfo
mode modifications).'[endquote]

--

___
Python tracker 

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

[issue798520] os.popen with invalid mode differs on Windows and POSIX

[anatoly techtonik]

anatoly techtonik  added the comment:

I can confirm this but, but os.popen() is deprecated in 2.6 hence there
is no point in fixing generated exception even though in a language that
claims to be cross-platform exceptions should be unified.

I would add os.popen to keywords list for future reference and close
this bug as "won't fix". There are many other bugs about os.popen on
windows platform and people would be interested to know exactly why
subprocess should be used.

--
nosy: +techtonik

___
Python tracker 

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

[issue1578269] Add os.link() and os.symlink() and os.path.islink() support for Windows

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I've now completed all of the aforementioned tasks.

1) Kernel32 does not need to be freed.  It is not freed by other calls
after which this additional code was modeled.  Additionally, the MSDN
indicates that it should only be freed by the module that loaded the
handle (which is not this one).

2) Functions that could be made inline have been made inline.

3) The todo, detection of whether a symlink target is a directory, has
been implemented.

4) A unit test with three tests has been added.  This test has not been
integrated into the larger test suite, but must be run explicitly (for
now).  The unit test passes with no failures on Windows Vista as written.

Some issues still remain.

A) In general, there is a implementation mismatch between Posix and
Windows symlinks.  In particular, Windows maintains that a symlink is
either for a directory or for a file, regardless of the existence of the
target.  Posix instead treats all symlinks like (special) files but
determines the directory status based on the target.  This mismatch
causes more specific problems.

B) Existing unit tests in test_os.py are going to fail (and maybe
others).  In particular, they will fail because they attempt to remove
symlinks to directories using os.remove.  Windows expects the use of
os.rmdir for directory-like symlinks (that is, symlinks who's original
destination was a directory or who's target_is_directory was set to true
at the time it was created).  The unit test included with the patch
illustrates some of these nuances.

C) Because lstat hides the directory status of a symlink (i.e. clears
S_IFLNK), it is not always possible to determine whether a symlink
should be removed using os.remove or os.rmdir.  Specifically, if the
symlink has no target or a directory symlink references a file, the user
will only know to call os.rmdir when os.remove fails with a WindowsError.

I see these issues break down into two categories:

I) How to remove a symlink?
  (a) Should os.remove be rewritten to handle directory symlinks on
Windows?  This method would provide the best compatibility with existing
code.
  (b) Or, do we require python authors to manually determine which
method to call to remove a symlink?  This approach is less intrusive,
but really doesn't provide an effective solution, as it's only partly
compatible with Posix implementations.

II) How to detect a directory symlink?  In either case of (I), there
needs to be an implementation to detect directoryness of a symlink.
  (a) Create a new function in posixmodule that exposes the directory
bit of a symlink, perhaps "is_symlink_directory", which always returns
false except on Windows.
  (b) Change win_lstat to leave the S_IFDIR bit in tact and modify
S_ISLNK to ignore that bit.  Then is_symlink_directory becomes
S_ISDIR(lstat_mode) and S_ISLNK(lstat_mode).

Alternately, maybe trying to fit the Windows APIs into Posix
compatibility is the wrong approach.  Maybe instead there should be a
Python abstraction layer for symlink handling.  I think we're close with
the existing approach, but I'm somewhat worried that we will continue to
find edge cases that break because of the differences in assumptions
about the two implementations.

I think this is getting very close.  I appreciate all the help and support.

--
Added file: http://bugs.python.org/file14195/windows symlink draft 5.patch

___
Python tracker 

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

[issue1943] improved allocation of PyUnicode objects

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Note that in Python 2.x you don't have such issues because
> there, most tools for text processing will happily work on
> any sort of buffer, so you don't need a string sub-type
> in order to implement e.g. references into another string
> (the buffer type will allow you to do this easily).

The new buffer API has a provision for type flags, although none of them
had a chance to be implemented by the original author before he ran
away...
There could be a type flag for unicode characters and then its support
could be implemented in the memoryview object.

--

___
Python tracker 

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

[issue6207] Simple For-Loops

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This is not a place for such discussion. Please post on comp.lang.python.

--
nosy: +pitrou
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

[issue1943] improved allocation of PyUnicode objects

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Guido van Rossum wrote:
> I think it's fine to wait for 3.2. Maybe add something to the docs
> about not subclassing unicode in C.

We should have a wider discussion about this on python-dev.

I'll publish the unicoderef extension and then we can see
whether users want this or not.

Antoine's patch makes such extensions impossible (provided you
don't want to copy over the complete unicodeobject.c
implementation in order to change the memory allocation
scheme).

Note that in Python 2.x you don't have such issues because
there, most tools for text processing will happily work on
any sort of buffer, so you don't need a string sub-type
in order to implement e.g. references into another string
(the buffer type will allow you to do this easily).

--

___
Python tracker 

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

[issue6207] Simple For-Loops

[Gabriel Koritzky]

New submission from Gabriel Koritzky :

I don't know if something like this has been said before, so if it did
just ignore this.

I have noticed that very few programming languages use simple for loops.
Python itself doesn't have a really simple one. So here's my suggestion:

for ( value ):
# Repeats the code that follows 'value' times if value is an integer. If
it's a string or a list, repeats the code once per character or instance
on 'value'.

for ( iniINC , finalEXC ):
# Repeats the code that follows 'finalEXC - iniINC' times if they're
integers.

for ( variable , iniINC , finalEXC ):
# Assigns iniINC to variable and raises it by one until it reaches
finalEXC (not executing when it does).

#example1
for 70:
doNothing()

#example2
a = 10
for a:
doNothing()

#example3
a = 5
for ( a , 10 ):
doNothing()

#example4
i = 0
for ( i , 10 , 20 ):
doNothing()

--
messages: 88950
nosy: gabrielkfl
severity: normal
status: open
title: Simple For-Loops

___
Python tracker 

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

[issue6206] Correct a trivial typo introduced by r73238.

[Vikram U Shenoy]

New submission from Vikram U Shenoy :

Attached is a patch which should fix the 'too many values to unpack'
error introduced by commit r73238.

--
components: Tests
files: test__locale_typo_jun_5_2009.patch
keywords: patch
messages: 88949
nosy: vshenoy
severity: normal
status: open
title: Correct a trivial typo introduced by r73238.
versions: Python 2.7
Added file: http://bugs.python.org/file14194/test__locale_typo_jun_5_2009.patch

___
Python tracker 

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

[issue5727] doctest pdb readline broken

[Wolfgang Schnerring]

Wolfgang Schnerring  added the comment:

I've tracked down the reason by diffing pdb.py and cmd.py between 2.4
and 2.5:
It turns out that pdb.Pdb in 2.5 changes the way it handles input
depending on whether an explicit output was provided, more precisely, it
disables readline in that case. I don't understand what's going on here,
but there is a simple, non-intrusive fix on the doctest side, see the
attached patch.

Unfortunately, I can't imagine how to write a test to check this behaviour.

--
keywords: +patch
Added file: http://bugs.python.org/file14193/doctest-readline.patch

___
Python tracker 

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

[issue6199] test_unittest fails on Windows

[Michael Foord]

Michael Foord  added the comment:

Thanks - I should have tested on Windows first. Tests now pass on
Windows and Mac OS X. Committed revision 73247.

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

___
Python tracker 

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

[issue1943] improved allocation of PyUnicode objects

[Guido van Rossum]

Guido van Rossum  added the comment:

On Fri, Jun 5, 2009 at 4:06 AM, Marc-Andre Lemburg
 wrote:
>
> Marc-Andre Lemburg  added the comment:
>
> Antoine Pitrou wrote:
>> Antoine Pitrou  added the comment:
>>
>> Raymond suggested the patch be committed in 3.1, so as to minimize
>> disruption between 3.1 and 3.2. Benjamin, what do you think?
>
> Has Guido pronounced on this already ?

I don't want it added to 3.1 unless we start the beta cycle afresh.
It's too subtle for submitting after rc1. Talk to Benjamin if you
disagree.

I think it's fine to wait for 3.2. Maybe add something to the docs
about not subclassing unicode in C.

--

___
Python tracker 

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

[issue6205] sdist doesn't include data_files

[James]

New submission from James :

Hi, I have shown the output from my terminal below, since it will be
easier to follow for explaining the bug.

ja...@computer:~/testsetup$ ls
helloworld2.py  image1.jpg  setup.py
ja...@computer:~/testsetup$ cat setup.py 
#!/usr/bin/python
import distutils.core   #from distutils.core import setup, Extension
import os

# build a list of modules required for setup function below
py_modules = []

py_modules.append('helloworld2')

distutils.core.setup(
name='helloworld2',
description='distutils test',
version='0.1',
author='James',
author_email='purplei...@gmail.com',
py_modules=py_modules,
# data_files: install directory, 
data_files=[('share/helloworld2', ['image1.jpg'])]
)

ja...@computer:~/testsetup$ ./setup.py sdist
running sdist
warning: sdist: manifest template 'MANIFEST.in' does not exist (using
default file list)
warning: sdist: standard file not found: should have one of README,
README.txt
writing manifest file 'MANIFEST'
creating helloworld2-0.1
making hard links in helloworld2-0.1...
hard linking helloworld2.py -> helloworld2-0.1
hard linking setup.py -> helloworld2-0.1
creating dist
tar -cf dist/helloworld2-0.1.tar helloworld2-0.1
gzip -f9 dist/helloworld2-0.1.tar
removing 'helloworld2-0.1' (and everything under it)
ja...@computer:~/testsetup$ 

as you will notice, the image1.jpg file does not get included in the
source distribution, and if i want to backup the entire dir/code of
everything to send to someone else.
perhaps this is a peculiarity of distutils. i realize i could write my
own manifest.in but then i have to specify *everything* and this isn't
automatic anymore.
this is definitely an issue since a user who downloads the sdist file
and runs an install will see:

error: can't copy 'image1.jpg': doesn't exist or not a regular file

this occurs because it obviously didn't get included in the sdist. the
same thing happens when sdist is run with --no-prune

i thought that perhaps i was using the wrong target so i tried a bdist
(tar.gz). in this case the image1.jpg file gets included, however
unpacking the directory doesn't give me a structure similar to the one
my code is originally maintained in.
so how do i use distutils to share *everything*, (eg: everything
specified in the setup.py directory) with my friends on the tubes?

if you want, i'll write a patch.

_J

--
assignee: tarek
components: Distutils
messages: 88945
nosy: purpleidea, tarek
severity: normal
status: open
title: sdist doesn't include data_files
type: behavior
versions: Python 2.5

___
Python tracker 

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

[issue6198] test_float fails on Windows

[Eric Smith]

Eric Smith  added the comment:

Mark Dickinson wrote:
> Out of interest, what does '%#.0f' % 1.5 produce on
> Python 2.7/Windows?  I'd expect to get '2.' both for
> round-half-to-even and round-half-away-from-zero.
> Does Windows round this down to '1.' instead?

Windows in trunk gives '2.'.

> I'm surprised by the %#.ng results for 0;  this looks
> like questionable behaviour (producing n+1 digits when
> only n significant digits were requested).  Is the MS
> implementation of printf directly responsible for this,
> or is the CPython code somehow adding the extra 0?
> If this is just the way that Windows behaves for formatting
> of zeros, then I suppose we could add code to work around
> this, but it's not clear that it's really worth it.

This is from a C program on Windows, using printf:
%#.0g: 0.0
%#.1g: 0.0
%#.2g: 0.00
%#.3g: 0.000

Same program on Linux:
%#.0g: 0.
%#.1g: 0.
%#.2g: 0.0
%#.3g: 0.00

In 2.6 on Windows:
 >>> '%#.1g' % 0.0
'0.0'
 >>> '%#.2g' % 0.0
'0.00'

In 2.6 on Linux:
 >>> '%#.1g' % 0.0
'0.'
 >>> '%#.2g' % 0.0
'0.0'

So this isn't a problem we caused with the short repr work, it's 
pre-existing. I don't think it's worth working around, but that's me. 
%-formatting should just die.

> I suspect that we're in for some complaints when
> Windows users discover that Python 3.1 string formatting
> does round-half-to-even rather than the round-half-up
> they're used to in Python 2.x.

But at least in 3.1 it will now be consistent cross-platform. Can't have 
it both ways!

--

___
Python tracker 

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

[issue6198] test_float fails on Windows

[Tim Peters]

Tim Peters  added the comment:

> Out of interest, what does '%#.0f' % 1.5 produce on
> Python 2.7/Windows?

Microsoft's float->string routines have always done "add a half and
chop" rounding.  So, yes, 1.5 rounds to 2 there.

> ...
> I suspect that we're in for some complaints when
> Windows users discover that Python 3.1 string
> formatting does round-half-to-even rather than
> the round-half-up they're used to in Python 2.x.

Historically, overall we've had more gripes from non-Windows users
complaining that, e.g., 2.5 does /not/ round up to 3 -- you can't win
here, so don't worry about it.  X-platform consistency is incompatible
with platform-specific behavior, and most users will agree consistency
is overwhelmingly more important.  Of course that won't deter them from
complaining ;-)

--
nosy: +tim_one

___
Python tracker 

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

[issue6198] test_float fails on Windows

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks, Eric.  All those changes look good to me.

Out of interest, what does '%#.0f' % 1.5 produce on
Python 2.7/Windows?  I'd expect to get '2.' both for
round-half-to-even and round-half-away-from-zero.
Does Windows round this down to '1.' instead?

I'm surprised by the %#.ng results for 0;  this looks
like questionable behaviour (producing n+1 digits when
only n significant digits were requested).  Is the MS
implementation of printf directly responsible for this,
or is the CPython code somehow adding the extra 0?
If this is just the way that Windows behaves for formatting
of zeros, then I suppose we could add code to work around
this, but it's not clear that it's really worth it.

I suspect that we're in for some complaints when
Windows users discover that Python 3.1 string formatting
does round-half-to-even rather than the round-half-up
they're used to in Python 2.x.

--

___
Python tracker 

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

[issue6123] tarfile: opening an empty tar file fails

[Lars Gustäbel]

Lars Gustäbel  added the comment:

Thanks for the report. Empty archives are perfectly valid and tarfile
should be able to read them without error. I will take care of this
issue soon.

--
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

___
Python tracker 

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

[issue3292] Position index limit; s.insert(i,x) not same as s[i:i]=[x]

[Dennis Benzinger]

Changes by Dennis Benzinger :


--
nosy: +dcbbcd

___
Python tracker 

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

[issue4966] Improving Lib Doc Sequence Types Section

[Dennis Benzinger]

Changes by Dennis Benzinger :


--
nosy: +dcbbcd

___
Python tracker 

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

[issue6198] test_float fails on Windows

[Eric Smith]

Eric Smith  added the comment:

Checked in to trunk in r73240.

--
assignee: marketdickinson -> eric.smith
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue6204] Missing reference in section 4.6 to chapter on classes

[Michael Markert]

New submission from Michael Markert :

In section 4.6 there is described that classes will be explained later
on. I think a real reference would be more appropriate.
See attached patch.

--
assignee: georg.brandl
components: Documentation
files: controlflow.rst.patch
keywords: patch
messages: 88939
nosy: cofi, georg.brandl
severity: normal
status: open
title: Missing reference in section 4.6 to chapter on classes
versions: Python 3.1
Added file: http://bugs.python.org/file14192/controlflow.rst.patch

___
Python tracker 

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

[issue6202] Obsolete default file encoding "mac-roman" on OS X, not influenced by locale env variables

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I'm setting the priority to "release blocker" because the current 
behaviour is completely unwanted, the "mac-roman" encoding is no longer 
used by default on OSX. All system tools write UTF-8 encoded files by 
default, and the LANG variable is set to an UTF8 encoding as well.

I won't be able to look into before sunday, and possibly only after next 
week (that is june 15th or later) because I'll be at a conference and 
don't know if I have spare time to spent on this after sunday.

--
priority:  -> release blocker

___
Python tracker 

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

[issue6198] test_float fails on Windows

[Eric Smith]

Eric Smith  added the comment:

I had to remove a bunch of tests. Some were of the form
"5", rounded to before the 5. Some were comparing a large
number of digits.

Then there's these:
%#.0g 0 -> 0. Got '0.0'
%#.1g 0 -> 0. Got '0.0'
%#.2g 0 -> 0.0Got '0.00'
%#.3g 0 -> 0.00   Got '0.000'
%#.4g 0 -> 0.000  Got '0.'

I'm going to remove these, too, since they're all based on underlying
printf differences. But they seem like a bigger problem than the other
cases.

--
assignee: eric.smith -> marketdickinson

___
Python tracker 

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

[issue1943] improved allocation of PyUnicode objects

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine Pitrou wrote:
> Antoine Pitrou  added the comment:
> 
> Raymond suggested the patch be committed in 3.1, so as to minimize
> disruption between 3.1 and 3.2. Benjamin, what do you think?

Has Guido pronounced on this already ?

--

___
Python tracker 

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

[issue6195] Serious regression in doctest in Py3.1rc1

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Patches (fix+test) are good.

--
nosy: +amaury.forgeotdarc
resolution:  -> accepted

___
Python tracker 

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

[issue6196] tarfile.extractall(readaccess=True)

[Lars Gustäbel]

Lars Gustäbel  added the comment:

I am still not convinced why tarfile needs this kind of a work-around
built in. We talk about a very small number of cases here and the
generator_tools-0.3.5.tar.gz is really broken beyond repair. It is the
only thing that should be fixed here IMO ;-)
I agree with David here. It is easy to manipulate the tarfile in
advance, as you have shown yourself. The performance argument does not
convince me either.

--
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

___
Python tracker 

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

[issue6198] test_float fails on Windows

[Mark Dickinson]

Mark Dickinson  added the comment:

[Eric]
> I can do this and verify it works on Windows before checking in, if
> you'd like.

That would be great---yes, please!  My main computer died yesterday, 
taking my Windows access and my python svn access with it. :-(

--
assignee: marketdickinson -> eric.smith

___
Python tracker 

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

[issue6203] 3.x locale does not default to C, contrary to the documentation and to 2.x behavior

[Ned Deily]

New submission from Ned Deily :

In the Library Reference section 22.2.1 for locale, it states:

"Initially, when a program is started, the locale is the C locale, no 
matter what the user’s preferred locale is. The program must explicitly 
say that it wants the user’s preferred locale settings by calling 
setlocale(LC_ALL, '')."

This is the case for python2.x:

$ export LANG=en_US.UTF-8
$ python2.5
Python 2.5.4 (r254:67916, Feb 17 2009, 20:16:45) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale; locale.getlocale()
(None, None)
>>> locale.getdefaultlocale()
('en_US', 'UTF8')
>>> 

but not for 3.1:
$ python3.1
Python 3.1a1+ (py3k, Mar 23 2009, 00:12:12) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale; locale.getlocale()
('en_US', 'UTF8')
>>> locale.getdefaultlocale()
('en_US', 'UTF8')
>>> 

Either the code is incorrect in 3.1 or the documentation should be 
updated.

--
assignee: georg.brandl
components: Documentation
messages: 88932
nosy: georg.brandl, nad
severity: normal
status: open
title: 3.x locale does not default to C, contrary to the documentation and to 
2.x behavior
type: behavior
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

[issue6198] test_float fails on Windows

[Eric Smith]

Eric Smith  added the comment:

Yes, this test passes on py3k on my Windows box. That would be a
nightmare if it didn't!

I agree that this is a test problem, not a code problem. I suggest we
just remove the offending line from formatfloat_testcases.txt in trunk.
I can do this and verify it works on Windows before checking in, if
you'd like.

--

___
Python tracker 

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

[issue6198] test_float fails on Windows

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for the report.  It sounds as though I might have backported
some tests from py3k to trunk that shouldn't have been backported.

abbeyj or eric, do you know whether py3k also has this failure on your 
machine?  I'm hoping not:  py3k doesn't use the CRT *printf functions for 
float formatting, so the test should pass there.

--
assignee:  -> marketdickinson

___
Python tracker 

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

[issue6202] Obsolete default file encoding "mac-roman" on OS X, not influenced by locale env variables

[Ned Deily]

New submission from Ned Deily :

Potential Release Blocker

The default file encoding for 3.x file objects is the value of 
locale.getpreferredencoding(). Currently, the locale module behavior on 
OS X deviates from other python POSIX platforms in a few unexpected and 
bad ways:

1. On OS X, locale.getpreferredencoding() returns "mac-roman", an 
obsolete encoding from the old "Classic" MacOS days.

2. Unlike other POSIX platforms (at least Debian Linux), the values 
returned by locale.getdefaultlocale() and locale.getpreferredencoding() 
on OS X are not influenced by the settings of the POSIX locale 
environment variables, i.e LANG.  So, unlike on the other POSIX 
platforms, one can't override the (obsolete) encoding without explicitly 
setting the encoding argument to open().

Compare the results from Debian Linux:

$ unset LANG
$ python3.1
Python 3.1a1+ (py3k, Mar 23 2009, 00:12:12) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'ANSI_X3.4-1968'
>>> open('blah','r').encoding
'ANSI_X3.4-1968'
>>> locale.getlocale()
(None, None)
>>> locale.getdefaultlocale()
(None, None)
>>> 
$ export LANG=en_US.UTF-8
$ python3.1
Python 3.1a1+ (py3k, Mar 23 2009, 00:12:12) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'UTF-8'
>>> open('blah','r').encoding
'UTF-8'
>>> locale.getlocale()
('en_US', 'UTF8')
>>> locale.getdefaultlocale()
('en_US', 'UTF8')
>>> 

... to OS X:

$ unset LANG
$ python3.1
Python 3.1rc1+ (py3k, Jun  3 2009, 14:31:41) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'mac-roman'
>>> open('blah','r').encoding
'mac-roman'
>>> locale.getlocale()
(None, None)
>>> locale.getdefaultlocale()
(None, 'mac-roman')
>>> 
$ export LANG=en_US.UTF-8
$ python3.1
Python 3.1rc1+ (py3k, Jun  3 2009, 14:31:41) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'mac-roman'
>>> open('blah','r').encoding
'mac-roman'
>>> locale.getlocale()
('en_US', 'UTF8')
>>> locale.getdefaultlocale()
(None, 'mac-roman')
>>> 

A quick look at the code shows that part of the problem is in 
Modules/_localemodule.c where there is a #if defined(__APPLE__) version 
of PyLocale_getdefaultlocale which appears to have its origins in MacOS 
and should probably just be removed and locale.py modified to 
eliminate/minimize the special case mac/darwin code.  For the case of no 
locale, "UTF-8" would seem to be a reasonable default.  In any case, 
"mac-roman" is not.

--
assignee: ronaldoussoren
components: IO, Library (Lib), Macintosh
messages: 88929
nosy: benjamin.peterson, nad, ronaldoussoren
severity: normal
status: open
title: Obsolete default file encoding "mac-roman" on OS X, not influenced by 
locale env variables
type: behavior
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

[issue1943] improved allocation of PyUnicode objects

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Raymond suggested the patch be committed in 3.1, so as to minimize
disruption between 3.1 and 3.2. Benjamin, what do you think?

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue6198] test_float fails on Windows

[Eric Smith]

Eric Smith  added the comment:

I can duplicate this with Visual C++ 9.0 Express Edition on XP.

--

___
Python tracker 

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

[issue6198] test_float fails on Windows

[Eric Smith]

Changes by Eric Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue6201] test_winreg fails

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue6198] test_float fails on Windows

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +marketdickinson

___
Python tracker 

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

[issue6199] test_unittest fails on Windows

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> michael.foord
nosy: +michael.foord

___
Python tracker 

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