[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Eli Bendersky]

Eli Bendersky  added the comment:

The more I think about it, the more the bootstrap code in _elementtree.c annoys 
me. It's the only instance of calling PyRun_String in Modules/ !

It's hackish and causes ugly import problems. If the C code needs stdlib 
functionality like copy.deepcopy, it should use PyImport_ImportModule like 
everyone else and not through a PyRun_String hack.

Since we've already decided to do some refactoring, I suggest all trace of the 
bootstrap is removed from _elementtree.c

--

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Stefan Behnel]

Stefan Behnel  added the comment:

Eli Bendersky, 11.02.2012 09:08:
> The more I think about it, the more the bootstrap code in _elementtree.c
> annoys me. It's the only instance of calling PyRun_String in Modules/ !
> 
> It's hackish and causes ugly import problems. If the C code needs stdlib
> functionality like copy.deepcopy, it should use PyImport_ImportModule
> like everyone else and not through a PyRun_String hack.

I find it perfectly legitimate to run Python code from a C module.
Certainly not a hack. We all know that most non-trivial functionality can
be expressed much easier in Python than in C, that's why we use Python
after all. In particular, defining a class with attributes and methods is a
couple of lines of code in Python, but a huge amount of code in C. Avoiding
the complexity of writing everything in C, or even of splitting the code in
a harder to understand way, is worth it.

That being said, I think it's worth removing any clear *redundancy* with
ET.py, as Florent's patch did. The goal is to keep _elementtree.c a pure
accelerator module that improves plain ElementTree, and redundancy is
counterproductive in this context. But if the implementation differs for
some reason, I would tend towards leaving it as is.

Stefan

--

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Eli Bendersky]

Eli Bendersky  added the comment:

>> I find it perfectly legitimate to run Python code from a C module.
Certainly not a hack. We all know that most non-trivial functionality can
be expressed much easier in Python than in C, that's why we use Python
after all. In particular, defining a class with attributes and methods is a 
couple of lines of code in Python, but a huge amount of code in C. Avoiding the 
complexity of writing everything in C, or even of splitting the code in a 
harder to understand way, is worth it.
<<

There can be arguments both way, but if we follow the lead of existing standard 
extension modules, the tendency is clearly not to use PyRun_String. Many C 
extensions use functionality from Python, but none does it the "bootstrap way". 
Why is that? Is there a good reason, or is it just convention?

--

___
Python tracker 

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

[issue13953] Get rid of doctests in packaging.tests.test_version

[Francisco Martín Brugué]

Francisco Martín Brugué  added the comment:

Thank you for the review. Just some questions:

Isn't that what the previous code (doctest code) did?

I thought that the code should be ported as far backwards as possible 
and that's why I used the plain assertEqual (I don't know exactly in 
with version the other assert methods were introduced. Unittest2?)

Can one use all the new unittest2 methods to test packaging (distutils2)
code?

> --
> Added file: http://bugs.python.org/file24482/cleanup-test_version.diff
>
> ___
> Python tracker
> 
> ___
>

--

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Florent Xicluna]

Florent Xicluna  added the comment:

> Anyhow, I tried to apply it and a few tests in test_xml_etree_c fail,
> because it can't find fromstring and fromstringlist.

Ooops, I cut some redundancy after running the tests, and I forgot to re-add 
the import. You're right.

> However, why did you leave some bootstrapping code inside?
> It's the only instance of calling PyRun_String in Modules/

I just tried to cut the import cycle and import it the other way.
I think it was done like that historically, for some reason, when
the module was first developped (for Python 1.5 maybe ...)
It is not necessary to remove all the Python code at once, and I am better at 
Python than at C.
We can delay this additional clean-up at a later time, it does not
block the PEP399 implementation.

--

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Florent Xicluna]

Florent Xicluna  added the comment:

Updated patch:
 - fixed missing import and missing alias
 - moved the XMLTreeBuilder alias to the Python module

--

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Florent Xicluna]

Changes by Florent Xicluna :


Added file: http://bugs.python.org/file24485/issue13988_prepare_pep399_v2.diff

___
Python tracker 

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

[issue12659] Add tests for packaging.tests.support

[Francisco Martín Brugué]

Francisco Martín Brugué  added the comment:

On 02/11/2012 05:59 AM, Éric Araujo wrote:

>> BTW: in distutils2 I get (not because of this change):
> Actually I did fix that, but depending on your Python version the conditional 
> in the test may be wrong.  What’s the Python version you used?

I did:
python2.7 runtests.py

The exact version is: python2.7 -V -->
Python 2.7.2+

and the machine is a Debian: uname -a -->
Linux random 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 UTC 2012 x86_64 
GNU/Linux

Thanks for your time as mentor!

--

___
Python tracker 

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

[issue13123] bdist_wininst uninstaller does not remove pycache directories

[Paul Moore]

Paul Moore  added the comment:

I'll try to take a look over the next couple of days.

--

___
Python tracker 

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

[issue13175] packaging uses wrong line endings in RECORD files on Windows

[Paul Moore]

Paul Moore  added the comment:

>> Do I need to hg clone then do some magic pip incantation to get it installed?
> Why would you want to install it?  Clone it, hack on it in place, run tests 
> in place.  :)
>
> FTR, “bin/pip install -e .” is the command to “install” a project in develop 
> (or editable) mode with pip in a virtualenv.

Thanks, that's what I needed. I'm new to pip and know little more than
"pip install" :-)

--

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 31dfb4be934d by Florent Xicluna in branch 'default':
Issue #13988: move the python bootstrap code to cElementTree.py, and remove 
obsolete code for Python 2.4 and 2.5.
http://hg.python.org/cpython/rev/31dfb4be934d

--
nosy: +python-dev

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Florent Xicluna]

Florent Xicluna  added the comment:

I've pushed this first part, which is just a code refactoring.

I tried to work out a patch for the second part.
The tricky thing is because of xml.etree still using doctests.
The patch for the tests seems to be enough small and readable.

We have small differences between C and Python, about the warnings beeing 
raised. In general the C implementation do not raise the deprecation warnings. 
IMHO, this could be fixed later.

Still missing is the patch for the documentation.

--
Added file: http://bugs.python.org/file24486/issue13988_fold_cET_behind_ET.diff

___
Python tracker 

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

[issue13991] namespace packages depending on order

[andrea crotti]

andrea crotti  added the comment:

There is nothing binary in the archive, just a simple example of namespace 
packages, which was the minimal example that I could create to make things fail.

I use the standard pkg_resources way to do things:
__import__('pkg_resources').declare_namespace(__name__)

--

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Eli Bendersky]

Eli Bendersky  added the comment:

Another random cleanup idea:

ElementTree.py has this code:

try:
from . import ElementPath
except ImportError:
ElementPath = _SimpleElementPath()

Since in the stdlib ElementPath.py is always there, this is meaningless, so I'd 
say this try... except ImportError contraption can be removed, as well as 
_SimpleElementPath, and just replaced by:

from . import ElementPath

--

___
Python tracker 

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

[issue13992] Segfault in PyTrash_destroy_chain

[Aaron Staley]

New submission from Aaron Staley :

Am frequently getting segmentation faults with my python program.  I am 
utilizing heavy use of threading and sockets.

All sorts of ones are showing in syslog:

kernel: [7763578.475590] python[10097]: segfault at 88e5a0 ip 0088e5a0 
sp 7f640efd4028 error 15 in python2.7[833000+69000]
Feb 11 11:39:41 ip-10-8-197-187 kernel: [7762910.806782] python[6228]: segfault 
at 16 ip 0016 sp 7fe488fb0028 error 14 in 
python2.7[40+233000]
Feb 11 07:36:09 ip-10-8-197-187 kernel: [7748298.747145] python[11376]: 
segfault at 16 ip 0016 sp 7f28767ab028 error 14 in 
python2.7[40+233000]

Managed to capture one coredump:

Program terminated with signal 11, Segmentation fault.
#0  0x0009 in ?? ()
(gdb) where
#0  0x0009 in ?? ()
#1  0x0046670f in _PyTrash_destroy_chain () at ../Objects/object.c:2448
#2  0x004bd0df in PyEval_EvalCodeEx (co=, 
globals=, locals=, args=, 
argcount=, kws=, kwcount=0, defs=0x0, defcount=0, 
closure=
(, , , , , , , , 
)) at ../Python/ceval.c:3264
#3  0x004b6a5b in fast_function (nk=, na=0, n=, pp_stack=0x7f778ef9c1b0, func=) at 
../Python/ceval.c:4117
#4  call_function (oparg=, pp_stack=0x7f778ef9c1b0) at 
../Python/ceval.c:4042
#5  PyEval_EvalFrameEx (f=, throwflag=) at 
../Python/ceval.c:2666
#6  0x004bcd2d in PyEval_EvalCodeEx (co=0x168f6b0, globals=, locals=, args=, argcount=, 
kws=, kwcount=0, defs=0x169f260, defcount=2, closure=
0x0) at ../Python/ceval.c:3253
#7  0x004b6a5b in fast_function (nk=, na=3, n=, pp_stack=0x7f778ef9c3a0, func=) at 
../Python/ceval.c:4117
#8  call_function (oparg=, pp_stack=0x7f778ef9c3a0) at 
../Python/ceval.c:4042
#9  PyEval_EvalFrameEx (f=, throwflag=) at 
../Python/ceval.c:2666
#10 0x004bd325 in PyEval_EvalCodeEx (co=0x168f8b0, globals=, locals=, args=, argcount=, 
kws=, kwcount=5, defs=0x169a6c8, defcount=5, closure=
0x0) at ../Python/ceval.c:3253
#11 0x004b6a5b in fast_function (nk=, na=1, n=, pp_stack=0x7f778ef9c590, func=) at 
../Python/ceval.c:4117
#12 call_function (oparg=, pp_stack=0x7f778ef9c590) at 
../Python/ceval.c:4042
#13 PyEval_EvalFrameEx (f=, throwflag=) at 
../Python/ceval.c:2666
#14 0x004bcd2d in PyEval_EvalCodeEx (co=0x168a130, globals=, locals=, args=, argcount=, 
kws=, kwcount=0, defs=0x1684d28, defcount=1, closure=
0x0) at ../Python/ceval.c:3253
#15 0x004b6a5b in fast_function (nk=, na=2, n=, pp_stack=0x7f778ef9c780, func=) at 
../Python/ceval.c:4117
#16 call_function (oparg=, pp_stack=0x7f778ef9c780) at 
../Python/ceval.c:4042
#17 PyEval_EvalFrameEx (f=, throwflag=) at 
../Python/ceval.c:2666
#18 0x004b6d77 in fast_function (nk=, na=, n=, pp_stack=0x7f778ef9c8c0, func=) at ../Python/ceval.c:4107
#19 call_function (oparg=, pp_stack=0x7f778ef9c8c0) at 
../Python/ceval.c:4042
#20 PyEval_EvalFrameEx (f=, throwflag=) at 
../Python/ceval.c:2666
#21 0x004b6d77 in fast_function (nk=, na=, n=, pp_stack=0x7f778ef9ca00, func=) at ../Python/ceval.c:4107
#22 call_function (oparg=, pp_stack=0x7f778ef9ca00) at 
../Python/ceval.c:4042
#23 PyEval_EvalFrameEx (f=, throwflag=) at 
../Python/ceval.c:2666
#24 0x004bcd2d in PyEval_EvalCodeEx (co=0xc0d9b0, globals=, locals=, args=, argcount=, 
kws=, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at ../Python/ceval.c:3253
#25 0x00448edf in function_call (func=, 
arg=
(, acquire=, _Condition__waiters=[], 
release=) at 
remote 0x327a790>, _Thread__name='Thread-193', _Thread__daemonic=True, 
_Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, 
_Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=) at remote 0x327ab10>) at remote 
0x33a6350>, _Thread__stderr=, 
instance=, 
arg=, kw=) at ../Objects/abstract.c:2529
#27 0x0043074e in instancemethod_call (func=, arg=
(, acquire=, _Condition__waiters=[], 
release=) at 
remote 0x327a790>, _Thread__name='Thread-193', _Thread__daemonic=True, 
_Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, 
_Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=) at remote 0x327ab10>) at remote 
0x33a6350>, _Thread__stderr=, 
instance=, arg=, kw=) at 
../Objects/abstract.c:2529
#29 0x004b5d76 in PyEval_CallObjectWithKeywords (func=, arg=(), kw=) at ../Python/ceval.c:3890
#30 0x004f06c0 in t_bootstrap (boot_raw=) at 
../Modules/threadmodule.c:614
#31 0x7f77cfbafefc in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#32 0x7f77cea4789d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#33 0x in ?? ()

--
components: Interpreter Core
messages: 153123
nosy: Aaron.Staley
priority: normal
severity: normal
status: open
title: Segfault in PyTrash_destroy_chain
type: crash
versions: Python 2.7

___
Python tracker 

[issue13193] packaging.tests.test_manifest and distutils.tests.test_filelist failures

[Nadeem Vawda]

Nadeem Vawda  added the comment:

All tests pass with the patch applied, on both Windows 7 and Ubuntu 11.10.

I notice that the patch only changes Lib/packaging/manifest.py; does
Lib/distutils/filelist.py perhaps also need to be updated? Changeset
64485e0700ba modified both of these files.

--

___
Python tracker 

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

[issue13992] Segfault in PyTrash_destroy_chain

[Aaron Staley]

Aaron Staley  added the comment:

For some more context:

Python 2.7.2
Running on Amazon EC2
Linux 3.0.0-14-virtual x86_64 in ubuntu 11.10
170 threads in this particular core dump (another similar crash has 135)

--

___
Python tracker 

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

[issue13993] Handling of broken end tags in HTMLParser

[Ezio Melotti]

New submission from Ezio Melotti :

The attached patch fixes the parser to handle broken end tags like:





<

--
assignee: ezio.melotti
components: Library (Lib)
files: issue13993.diff
keywords: patch
messages: 153126
nosy: eric.araujo, ezio.melotti
priority: normal
severity: normal
stage: commit review
status: open
title: Handling of broken end tags in HTMLParser
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24487/issue13993.diff

___
Python tracker 

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

[issue5148] gzip.open breaks with 'U' flag

[Nadeem Vawda]

Changes by Nadeem Vawda :


--
nosy: +nadeem.vawda

___
Python tracker 

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

[issue13989] gzip always returns byte strings, no text mode

[Nadeem Vawda]

Nadeem Vawda  added the comment:

The problem here is that gzip.GzipFile does not support text mode, only
binary mode. Unfortunately, its __init__ method doesn't handle unexpected
mode strings sensibly, so you get a confusing error message.

If you need to open a compressed file in text mode in Python 3.2, use
io.TextIOWrapper:

with io.TextIOWrapper(gzip.open("ex1.sam.gz", "r")) as f:
line = f.readline()

In 3.3, it would be nice for gzip.open to do this transparently when mode
is "rt"/"wt"/"at". However, binary mode will still need to be the default
(for modes "r", "w" and "a"), to ensure backward compatibility.

In the meanwhile, I'll add a note to the documentation about this
limitation, and fix GzipFile.__init__ to produce a more sensible error
message.

--

___
Python tracker 

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

[issue13992] Segfault in PyTrash_destroy_chain

[Charles-François Natali]

Charles-François Natali  added the comment:

The crash occurs in an oject's destructor.
Are you using any third-party module (lsof/pmap can help)?

Also, it'd help if you tried reproducing the crash with a debug build 
(./configure --with-pydebug && make).

--
nosy: +neologix

___
Python tracker 

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

[issue13993] Handling of broken end tags in HTMLParser

[Ezio Melotti]

Changes by Ezio Melotti :


Added file: http://bugs.python.org/file24488/issue13993-2.diff

___
Python tracker 

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

[issue13952] mimetypes doesn't recognize .csv

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> About Antoine’s remark: mimetypes already reads mime.types files, so
> even if our internal registry is not up-to-date the module should know
> about all types present in /etc/mime.types.

The point was about systems which don't have a /etc/mime.types
(Windows).

--

___
Python tracker 

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

[issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler

[Ned Deily]

New submission from Ned Deily :

While final testing Distutils changes for Issue13590, I noticed that a few 
tests were failing unexpectedly on 2.7.x but passing on 3.2.x.  Upon further 
investigation, I discovered that in 2.7 there are two copies of 
"customize_compiler", the function being modified in Issue13590.  It appears 
that at one point prior to the decision to make no feature changes to 
Distutils, that customize_compiler was moved from distutils.sysconfig to 
distutils.ccompiler (fa69e891edf4).  Then, when the decision was made to revert 
changes and proceed with a new Distutils2/packaging, feature changes were 
reverted in 2.7 but, for unexplained reasons, only part of the changes were 
reverted (ad22bc22dddc).  Perhaps a clue is in the commit message:
  "reverting partially distutils to its 2.6.x state so 2.7a4 looks more
   like the 2.7b1 in this. the whole revert will occur after a4 is tagged "

>From the change logs, I see no evidence that the whole revert ever happened.  
>This has left 2.7 Distutils with two virtually identical versions of 
>customize_compiler with some commands and tests calling one and others calling 
>the other.  (In 3.2.x, the only version is in distutils.sysconfig.)  They 
>*were* virtually identically until Issue13590 changed one and missed the other.

Patch to follow which completes the revert for customize_compiler and brings 
2.7.x and 3.2.2 back into sync with respect to this.  This patch is needed 
immediately for the upcoming 2.7.3 release.  I strongly urge a more complete 
audit for other discrepancies between the 2.7.x and 3.2.x versions of 
Distutils; this isn't the first time we've been burned recently by the effects 
of the reverts in 2.7.

--
assignee: tarek
components: Distutils
messages: 153130
nosy: benjamin.peterson, eric.araujo, ned.deily, tarek
priority: release blocker
severity: normal
stage: needs patch
status: open
title: incomplete revert in 2.7 Distutils left two copies of customize_compiler
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

[issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler

[Ned Deily]

Changes by Ned Deily :


--
keywords: +patch
stage: needs patch -> commit review
Added file: http://bugs.python.org/file24489/issue13994_27.patch

___
Python tracker 

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

[issue5411] add xz compression support to shutil

[Nadeem Vawda]

Nadeem Vawda  added the comment:

> This not-so-bad patch adds lzma compression support to the shutil functions, 
> under the 'xztar' name.  Please review.

Functionally, the patch looks good to me. There are some docstrings that
should probably be updated, though:

- _make_tarball (the 'compress' argument)
- make_archive
- _unpack_tarfile
- unpack_archive


> Ideally, tarfile should have an attribute to expose what compression formats 
> are available, then shutil would reuse that, and packaging would just call 
> shutil.

+1

--

___
Python tracker 

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

[issue13878] test_sched failures on Windows buildbot

[Nadeem Vawda]

Nadeem Vawda  added the comment:

Patch looks good, but you might want to make this change to test_priority:

 l = []
 fun = lambda x: l.append(x)
 scheduler = sched.scheduler(time.time, time.sleep)
+now = time.time()
 for priority in [1, 2, 3, 4, 5]:
-z = scheduler.enterabs(0.01, priority, fun, (priority,))
+z = scheduler.enterabs(now + 0.01, priority, fun, (priority,))
 scheduler.run()
 self.assertEqual(l, [1, 2, 3, 4, 5])

--

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Tshepang Lekhonkhobe]

Changes by Tshepang Lekhonkhobe :


--
nosy: +tshepang

___
Python tracker 

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

[issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 6240ff5dfebe by Ned Deily in branch '2.7':
Issue #13994: Earler partial revert of Distutils enhancements in 2.7
http://hg.python.org/cpython/rev/6240ff5dfebe

--
nosy: +python-dev

___
Python tracker 

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

[issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler

[Ned Deily]

Ned Deily  added the comment:

With the release manager's concurrence, I've applied this patch prior to the 
freeze for 2.7.3.

--
assignee: tarek -> ned.deily
priority: release blocker -> normal
resolution:  -> fixed
stage: commit review -> 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

[issue13990] Benchmarks: 2to3 failures on the py3 side

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Antoine (since you last looked at the benchmark suite for Python 3), do 
> you know anything about this?

I don't know. It works here. It may depend on the version of 2to3 used for the 
conversion, try passing PYTHON=some_newer_python when running make_perf.sh.

--

___
Python tracker 

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

[issue13995] sqlite3 Cursor.rowcount documentation for old sqlite bug

[Matthew Woodcraft]

New submission from Matthew Woodcraft :

The documentation for the sqlite3 module contains the following statement, 
under 'Cursor.rowcount':

  For DELETE statements, SQLite reports rowcount as 0 if you make a DELETE FROM 
table without any condition.

This doesn't happen for me (with sqlite 3.7.9): rowcount returns the correct 
value in this case.

According to http://www.sqlite.org/lang_delete.html#truncateopt , this was a 
bug that was fixed in SQLite 3.6.5 (in 2008).

So I think the Python documentation should either omit this paragraph, or else 
explain that it only applies to older versions of SQLite.


Also, the first example under 'Using shortcut methods' has code to work around 
this bug, which should perhaps be removed.

--
assignee: docs@python
components: Documentation
messages: 153136
nosy: docs@python, mattheww
priority: normal
severity: normal
status: open
title: sqlite3 Cursor.rowcount documentation for old sqlite bug

___
Python tracker 

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

[issue2636] Adding a new regex module (compatible with re)

[Tshepang Lekhonkhobe]

Changes by Tshepang Lekhonkhobe :


--
nosy: +tshepang

___
Python tracker 

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

[issue13952] mimetypes doesn't recognize .csv

[R. David Murray]

R. David Murray  added the comment:

On Windows we do (now) read from the registry as well.  My guess is there are a 
lot more Windows systems out there with outdated registries then there are unix 
systems with outdated /etc/mime files, though.

--

___
Python tracker 

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

[issue13996] "What's New in Python" should have initial release date on heading

[Tshepang Lekhonkhobe]

New submission from Tshepang Lekhonkhobe :

As an example, the date near the top of this document 
http://docs.python.org/py3k/whatsnew/3.0.html matches that of today, which can 
be misleading (it appears as if the thing was released today).

Also, by initial release, I mean the first "final", not the point release. 
Maybe any other date mentioned would perhaps be the date the docs were updated, 
*not* the date they were rebuilt.

--
assignee: docs@python
components: Documentation
messages: 153138
nosy: docs@python, tshepang
priority: normal
severity: normal
status: open
title: "What's New in Python" should have initial release date on heading
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue13996] "What's New in Python" should have initial release date on heading

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +eric.araujo, ezio.melotti, georg.brandl, terry.reedy
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

[issue13989] gzip always returns byte strings, no text mode

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 4b32309631da by Nadeem Vawda in branch '3.2':
Issue #13989: Document that GzipFile does not support text mode.
http://hg.python.org/cpython/rev/4b32309631da

New changeset 8dbe8faea0e7 by Nadeem Vawda in branch 'default':
Merge: #13989: Document that GzipFile does not support text mode.
http://hg.python.org/cpython/rev/8dbe8faea0e7

--
nosy: +python-dev

___
Python tracker 

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

[issue13703] Hash collision security issue

[Dave Malcolm]

Dave Malcolm  added the comment:

I'm not quite sure how that would interact with the -R command-line
option for enabling randomization.

The changes to the docs in the latest patch clarifies the meaning of
what I've implemented (I hope).

My view is that we should simply enable hash randomization by default in
3.3

At that point, PYTHONHASHRANDOMIZATION and the -R option become
meaningless (and could be either removed, or silently ignored), and you
have to set PYTHONHASHSEED=0 to get back the old behavior.

--

___
Python tracker 

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

[issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder

[Jesús Cea Avión]

Jesús Cea Avión  added the comment:

Andrew, could you possibly write a patch and a test for 3.3?

--
nosy: +jcea
versions: +Python 3.3 -Python 3.2

___
Python tracker 

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

[issue13703] Hash collision security issue

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Should -R be required to take a parameter specifying "on" or "off" so
that code using a #! line continues to work as specified across the a
change in default behavior when upgrading from 3.2 to 3.3?

#!/usr/bin/python3 -R on
#!/usr/bin/python3 -R off

In 3.3 it would be a good idea to have a command line flag to turn
this off.  Rather than introducing a new flag in 3.3 a parameter that
is specific without regards for the default avoids that entirely.

before anyone suggests it: I do *not* think -R should accept a value
to use as the seed.  that is unnecessary.

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Comments to be addressed added on the code review.

--

___
Python tracker 

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

[issue13996] "What's New in Python" should have initial release date on heading

[Éric Araujo]

Éric Araujo  added the comment:

I agree that the date of the release would be more useful than the date of the 
doc build.

--
nosy: +rhettinger

___
Python tracker 

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

[issue13991] namespace packages depending on order

[Éric Araujo]

Éric Araujo  added the comment:

> There is nothing binary in the archive
The archive is a binary file.  We tend to dislike those because we need to 
download and process them instead of just reading them in a browser tab, and in 
some cases (Windows .exe files) there are also security reasons.  It’s not a 
big deal anyway, just a small matter of convention.

> I use the standard pkg_resources way to do things:
setuptools is not in the standard library nor does it implements PEPs, so it’s 
at most a de facto standard.  More importantly, it is not developed by 
python-dev; could you report the bug to bugs.python.org/setuptools and 
bitbucket.org/tarek/distribute ?  If they find that the bug actually comes from 
distutils, then we’ll reopen this bug.  Thanks!

--
assignee: tarek -> eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue10287] NNTP authentication should check capabilities

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Hynek, the patch doesn't apply properly here. Are you soon it's been generated 
against an up-to-date working copy?

Also, I think the logic is wrong: the capabilities should *always* be queried 
after auth, even if they are already known. That's because they can change 
after auth is successful.

See RFC 4643: “Other capabilities returned in response to a CAPABILITIES
   command received after authentication MAY be different from those
   returned before authentication.  For example, an NNTP server may not
   want to advertise support for a specific extension unless a client
   has been authenticated.”

--

___
Python tracker 

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

[issue10287] NNTP authentication should check capabilities

[Antoine Pitrou]

Antoine Pitrou  added the comment:

(oh, and better if it can come with a test)

--
type:  -> behavior
versions: +Python 3.3

___
Python tracker 

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

[issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler

[Éric Araujo]

Éric Araujo  added the comment:

FWIW I approve of the patch.

Quoting Ned:
> this isn't the first time we've been burned by the after effects of the 2.7 
> Distutils
> revert.  I really think we should go through and make sure there aren't other 
> unnecessary
> discrepancies between the current state of 2.7.x and 3.2.x/default.
The revert indiscriminately reverted new features and bug and doc fixes, some 
of which have been fixed again later when rediscovered.  I never did a 
systematic review but I could.  One of the most painful difference between 2.7 
and 3.x is the use of urllib vs. httplib in the register and upload commands, 
which does not let me port patches easily.

--

___
Python tracker 

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

[issue13953] Get rid of doctests in packaging.tests.test_version

[Éric Araujo]

Éric Araujo  added the comment:

> Isn't that what the previous code (doctest code) did?
I don’t understand, could you rephrase?

> I thought that the code should be ported as far backwards as possible and 
> that's why I
> used the plain assertEqual (I don't know exactly in with version the other 
> assert
> methods were introduced. Unittest2?)
Michael Foord took over maintenance of unittest and released a bunch of 
improvements for 2.7 and 3.1, then further improvements in 3.2.  unittest2 is a 
standalone release of this improved unittest (not sure if it’s like 3.1 or 
3.2).  For packaging in the 3.3 stdlib we have all new methods, and for 
distutils2 we use unittest2 which has them too and works with 2.4, so we have 
compat.

--

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Éric Araujo]

Éric Araujo  added the comment:

>> I think that 3.2 and 2.7 should get a doc note about cET
> What doc note?

I was referring to one of the points raised in the email thread: the docs don’t 
tell people that they can import a faster ET version, cET.

--

___
Python tracker 

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

[issue13950] rm commented-out code

[Éric Araujo]

Éric Araujo  added the comment:

Done as part of my general cleanup of test_version.

--
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Get rid of doctests in packaging.tests.test_version

___
Python tracker 

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

[issue13193] packaging.tests.test_manifest and distutils.tests.test_filelist failures

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c566a3447ba1 by Éric Araujo in branch '2.7':
Fix distutils.filelist.FileList under Windows (#13193).
http://hg.python.org/cpython/rev/c566a3447ba1

--

___
Python tracker 

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

[issue13949] rm needless use of pass statement

[Éric Araujo]

Éric Araujo  added the comment:

Will commit this together with the test_version cleanup.

--
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Get rid of doctests in packaging.tests.test_version

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Eli Bendersky]

Eli Bendersky  added the comment:

>> I was referring to one of the points raised in the email thread: the docs 
>> don’t tell people that they can import a faster ET version, cET.

Well, they *do*, but very modestly :-) I agree that should be improved and 
emphasized a bit, perhaps even mentioning (at least in the 3.2 doc) that in 3.3 
it's going to be done by default. Is that accepted practice? I mean to mention 
in docs of 3.x some upcoming change in version 3.x+1 ?

--

___
Python tracker 

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

[issue13996] "What's New in Python" should have initial release date on heading

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I think this is the wrong place to show release dates (a subject that would be 
further confused by having multiple point releases).

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

___
Python tracker 

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

[issue13948] rm needless use of set function

[Éric Araujo]

Éric Araujo  added the comment:

Done as part of my general test_version cleanup.

--
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Get rid of doctests in packaging.tests.test_version

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Eli Bendersky]

Eli Bendersky  added the comment:

Florent,

The issue13988_fold_cET_behind_ET.diff patch looks good to me. Unless there are 
objections from others, you can commit! Even the tests became simpler now, 
that's awesome ;-)

Now, what's left for this issue:

1. Update the documentation
2. Update "what's new"
3. Discuss and possibly implement the deprecation of cElementTree

I'll send a patch for 1 & 2 soon. What about 3?

--

___
Python tracker 

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

[issue12297] Clarifications to atexit.register and unregister doc

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I assume the patch is an improved description of reality. The old 'without 
binding the original name to ``None``.' is confusing to me in that context, so 
good riddance. However, I am not familiar with atexit or how it is intended to 
work. If you are not sure either, you might ask on pydev.

--

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Eli Bendersky]

Eli Bendersky  added the comment:

Attaching a patch for Doc/library/xml.etree.elementtree.rst and Misc/NEWS.

The doc notice is modeled after a similar notice in the doc of 'pickle'. Note 
that I've also removed the mention that effbot's site is the home of the 
development version of the library, since it's no longer formally true.

--
Added file: http://bugs.python.org/file24492/issue13988_doc_news.1.patch

___
Python tracker 

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

[issue13946] readline completer could return an iterable

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
versions: +Python 3.3 -Python 3.1

___
Python tracker 

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

[issue13193] packaging.tests.test_manifest and distutils.tests.test_filelist failures

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 90b30d62caf2 by Éric Araujo in branch '3.2':
Fix distutils.filelist.FileList under Windows (#13193).
http://hg.python.org/cpython/rev/90b30d62caf2

New changeset 68347f8430ec by Éric Araujo in branch 'default':
Merge fixes for #13193 and FAQ from 3.2
http://hg.python.org/cpython/rev/68347f8430ec

New changeset f06effb61cde by Éric Araujo in branch 'default':
Port the fix for #13193 to packaging
http://hg.python.org/cpython/rev/f06effb61cde

--

___
Python tracker 

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

[issue13193] packaging.tests.test_manifest and distutils.tests.test_filelist failures

[Éric Araujo]

Éric Araujo  added the comment:

Reverted the liberal fix and replaced it with Vinay’s in time for the next 
bugfix releases.  Will watch buildbot and close the report.  Thanks to all who 
helped.

--
resolution:  -> fixed
stage:  -> committed/rejected

___
Python tracker 

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

[issue13952] mimetypes doesn't recognize .csv

[Terry J. Reedy]

Terry J. Reedy  added the comment:

One solution would be to update our mimetypes file just before a new version, 
and then leave it until the next, just as we update unicodedata to current 
unicode and then leave it alone for bugfix releases. Rather than the entire 
IANA file, which has a lot of useless stuff, we might update from the most 
recent *nix files (assuming that they have less than 'everything').

--
nosy: +terry.reedy

___
Python tracker 

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

[issue13997] Add open_ascii() builtin

[Nick Coghlan]

New submission from Nick Coghlan :

(This proposes a new builtin, so may need to become a PEP)

A common programming task is "I want to process this text file, I know it's in 
an ASCII compatible encoding, I don't know which one specifically, but I'm only 
manipulating the ASCII parts so it doesn't matter".

In Python 2, you handle that task by doing:

f = open(fname)

The non-ASCII parts are then carried along as 8-bit bytes and reproduced 
faithfully when written back out.

In Python 3, you handle it by doing:

f = open(fname, encoding="ascii", errors="surrogateescape")

The non-ASCII parts are then carried along as code points in the Unicode 
Private Use Area and reproduced faithfully when written back out.

It would be significantly more friendly to beginners (and migrants from Python 
2) if the following shorthand spelling was available out of the box:

f = open_ascii(fname)

--
messages: 153164
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add open_ascii() builtin

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Eli Bendersky]

Eli Bendersky  added the comment:

Florent,

Just something minor I noticed in the new cElementTree.py:

  # Wrapper module for _elementtree

  from xml.etree.ElementTree import *
  # Not in __all__
  from xml.etree.ElementTree import ElementPath, XMLID, register_namespace

The "wrapper" comment should be removed, and possibly replaced with "This 
module exists for backwards compatibility with releases earlier than 3.3; 
Please import xml.etree.ElementTree directly"

Also, regarding the names not in __all__. Any good reason for them not to be? 
Seems like an omission to me.

--

___
Python tracker 

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

[issue13963] dev guide has no mention of mechanics of patch review

[Terry J. Reedy]

Terry J. Reedy  added the comment:

At one time, reviews (or the fact of a review) were posted back here 
automatically (or perhaps it is an option?) just like push messages. But I am 
not much familiar with the process either.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue13997] Add open_ascii() builtin

[Chris Rebert]

Changes by Chris Rebert :


--
nosy: +cvrebert

___
Python tracker 

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

[issue13997] Add open_ascii() builtin

[Eli Bendersky]

Eli Bendersky  added the comment:

Would not adding a new keyword arg to open() be less intrusive and more 
consistent?

I.e. open(fname, asciionly=True) or something similar.

--
nosy: +eli.bendersky

___
Python tracker 

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

[issue13198] Remove duplicate definition of write_record_file

[Éric Araujo]

Changes by Éric Araujo :


Removed file: 
http://bugs.python.org/file23666/remove-duplicate-write_record_file.diff

___
Python tracker 

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

[issue13972] set and frozenset constructors don't accept multiple iterables

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I believe s = set(); s.update(s1, s2, s3, ...) 
a) does what is requested;
b) is the proper spelling, as the request *is* for a union of input collections.
So I recommend closing.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue13997] Add open_ascii() builtin

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Hmm, what happened to "not every one-liner should be a builtin function"?

> I'm only manipulating the ASCII parts

How can you be sure about that?

> It would be significantly more friendly to beginners (and migrants from 
> Python 2)

To the point that many of them would stop thinking about the problem, and start 
producing unicode-incompatible code.
The idea that it may be presented as a porting recipe is IMO a good reason to 
oppose introducing this new function.

--
nosy: +pitrou

___
Python tracker 

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

[issue13997] Add open_ascii() builtin

[Chris Rebert]

Chris Rebert  added the comment:

@Bendersky:

Unlike open()'s other arguments, that one wouldn't be orthogonal though. It 
would be possible to write e.g.:

f = open(fname, encoding="big5", errors="replace", ascii_only=True)

which seems disturbing, IMO. It would be nicer to rule out such impossible 
combinations categorically.

--

___
Python tracker 

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

[issue13997] Add open_ascii() builtin

[Nick Coghlan]

Nick Coghlan  added the comment:

No point to adding a new keyword arg - if people are going to do something like 
that, they may as well learn to use "errors" and "encoding" properly.

Adding open_ascii() would be an acknowledgement that "basically ASCII, but 
maybe with a few other bytes that just need to round-trip correctly" is a 
common enough use case to special case (in particular, it's convenient to have 
algorithms than can operate on both utf-8 and all 8-bit extended ASCII 
variants, including latin-1).

The downside to using surrogateescape is that if you ever *do* feed it a file 
in a non-ASCII compatible encoding and then perform ASCII-based manipulations, 
you'll get mojibake instead of an early UnicodeDecodeError. (i.e. exactly the 
same problem this kind of thing can cause in Python 2)

--

___
Python tracker 

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

[issue13986] ValueError: cannot convert float NaN to integer

[Terry J. Reedy]

Terry J. Reedy  added the comment:

If I believe the error message, os.fstat(f.fileno()).st_mtime is returning a 
NaN, which would be a bug in our function or your system. Since os.fstat should 
be a thin wrapper over the system call, I would lean to the latter. I do not 
know if writing to sys.stderr would work during compilation, but if it does, 
try inserting a statement to grab the value and print it before the long 
conversion.

Is this error 'deterministic' in being raised consistently?

--
nosy: +terry.reedy

___
Python tracker 

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

[issue13193] packaging.tests.test_manifest and distutils.tests.test_filelist failures

[Éric Araujo]

Éric Araujo  added the comment:

Buildbots exist to crush joy: 
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%202.7/builds/1285/steps/test/logs/stdio/text

Possible ways forward:
- One of you gentlemen with a Windows box and a clear head can try to find a 
correct fix for the bug
- If Benjamin wants to release this week-end, the attached patch reverts to the 
buggy 2.7.2 code and skips the failing test on Windows (more skips may be 
needed)
- I’ll be on the Internet on Monday afternoon (Europe).

--
resolution: fixed -> 
stage: committed/rejected -> needs patch
Added file: http://bugs.python.org/file24493/revert-filelist-fix-2.7.diff

___
Python tracker 

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

[issue13193] packaging.tests.test_manifest and distutils.tests.test_filelist failures

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Possible ways forward:
> - One of you gentlemen with a Windows box and a clear head can try to
> find a correct fix for the bug

This error shows that distutils's own test suite relies on being able to
put both kind of path separators in a manifest, so my fix was probably
the correct one ;)

--

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Éric Araujo]

Éric Araujo  added the comment:

> perhaps even mentioning (at least in the 3.2 doc) that in 3.3 it's going
> to be done by default. Is that accepted practice?
I don’t think we ever do that, and it would be confusing.

-1 to mentioning _elementtree, an implementation detail.  What I was talking 
about is cElementTree.

--

___
Python tracker 

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

[issue12297] Clarifications to atexit.register and unregister doc

[Éric Araujo]

Éric Araujo  added the comment:

I wrote the patch after testing in a shell, so I’m confident it describes 
reality; I was more asking a wording/phrasing review.

--

___
Python tracker 

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

[issue13193] packaging.tests.test_manifest and distutils.tests.test_filelist failures

[Éric Araujo]

Éric Araujo  added the comment:

I’d say there is a bug in the tests then.  Remember that they were added 
recently and only tested on posix, so they’re not authoritative.

--

___
Python tracker 

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

[issue13193] packaging.tests.test_manifest and distutils.tests.test_filelist failures

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I’d say there is a bug in the tests then.  Remember that they were
> added recently and only tested on posix, so they’re not authoritative.

How about people who have similar "bugs" in their code then?
I think you're trying to be pure instead of practical.

--

___
Python tracker 

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

[issue13997] Add open_ascii() builtin

[Éric Araujo]

Éric Araujo  added the comment:

IMO it is a fact that the characters used by human languages are stored as 
bytes by computers, so a programmer needs to know the basics about text 
handling and encoding.  I don’t like the idea of a built-in function helping 
people to put their hands on their ears and sing “la-la-la everything is 
ASCII”.  I know that it is hard to find oneself confronted with a 
UnicodeDecodeError, I’ve been there, but then I learned.  My hope is that good 
explanations in the FAQ, howto and library ref (with good PageRank, so that 
people googling error messages find us) can help people understand how to work 
with text.

That said, I’m going to re-read Armin’s post about Python 3 and Nick’s reply to 
it to understand your position better.

can’t-put-my-damn-name-in-so-many-websites-in-2012-grumble’ly yours

--
nosy: +eric.araujo

___
Python tracker 

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

[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree

[Eli Bendersky]

Eli Bendersky  added the comment:

Éric,

Could you please open a new issue (with a dependency on this one) and explain 
there clearly what you want/mean?

--

___
Python tracker 

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

[issue11751] Increase distutils.filelist / packaging.manifest test coverage

[Éric Araujo]

Éric Araujo  added the comment:

FYI the tests revealed a bug in the code on Windows: #13193

--

___
Python tracker 

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

[issue13997] Add open_ascii() builtin

[Nick Coghlan]

Nick Coghlan  added the comment:

Pondering it further (and reading subsequent comments here and in the thread), 
I agree an open_ascii() builtin would be a step backwards, not forwards.

So, morphing this issue into a documentation one to work out:
- the bare minimum we think Python 3 users should be learning about Unicode
- deciding where to document that (with a reference to the Unicode HOWTO for 
anyone that wants to know more)

Some ideas specifically in the context of text files (for readers already 
familiar with the basic concept of text encodings):

1. The world is moving towards standardising on UTF-8 as the binary encoding 
used to store text files. However, we're a long way from living in that world 
right now. Other encodings (many, but far from all, ASCII compatible) will be 
encountered quite often, either as the default encoding on a particular 
platform, or as the encoding of a particular text file. Dealing with these 
correctly requires additional work.

2. To maximise the chance of correct local interoperability, Python 3's default 
choice of encoding is actually taken from the underlying platform rather than 
being forced to UTF-8. While it is becoming more and more common for platforms 
to set their preferred encoding to UTF-8, this is not yet universal (notably, 
Windows still does not use UTF-8 as the default encoding for text files in 
order to preserve compatibility with various Unicode-unaware legacy 
applications).

To handle this correctly in cross-platform applications and libraries, it is 
often necessary to explicitly pass "encoding='utf-8'" when opening a UTF-8 
encoded text file.

The default encoding on a given platform can be checked by running "import 
locale; locale.getpreferredencoding()" at the interactive prompt.

3. Currently, it is still fairly common to encounter text files that are known 
to be stored in an ASCII-compatible text encoding without knowing precisely 
*which* encoding is used. The Python 2 text model allowed such files to be 
processed naively simply by assuming they were in an ASCII-compatible encoding 
and passing any non-ASCII characters faithfully through to the result. This 
permissive behaviour can be requested explicitly in Python 3 by passing 
"encoding='ascii'" and "errors='surrogateescape'" when opening a text file.

This approach parallels the behaviour of Python 2 and works correctly so long 
as it is fed data solely in ASCII compatible encodings (such as UTF-8 and 
latin-1). Behaviour when fed data that uses other encodings is unpredictable - 
common symptoms include Unicode encoding and decoding errors at unexpected 
points in a program, as well as silent corruption of the output text.

--

___
Python tracker 

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

[issue13997] Clearly explain the bare minimum Python 3 users should know about Unicode

[Nick Coghlan]

Changes by Nick Coghlan :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
title: Add open_ascii() builtin -> Clearly explain the bare minimum Python 3 
users should know about Unicode
versions: +Python 3.2, Python 3.3

___
Python tracker 

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

[issue13997] Clearly explain the bare minimum Python 3 users should know about Unicode

[Eli Bendersky]

Eli Bendersky  added the comment:

If the concept is accepted. I see no better place for this than the
Unicode HOWTO. If it's too long, then a TL;DR; section should be added
in the beginning detailing "the bare minimum". No need to scatter such
information in bits and pieces around the documentation. That's what
the Unicode HOWTO is for.

--

___
Python tracker 

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

[issue13609] Add "os.get_terminal_size()" function

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

test_stty_match() should be skipped also when os.isatty(sys.__stdin__.fileno()) 
is False.
This test fails when test suite is run by Portage (Gentoo package manager), 
which somehow sets null input.

--

___
Python tracker 

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

[issue13609] Add "os.get_terminal_size()" function

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

Hi,

looking at the tests, the test should be skipped with 'stty invocation 
failed'. Does something different happen? Can you post the output from 
the tests?

--

___
Python tracker 

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

[issue13198] Remove duplicate definition of write_record_file

[Éric Araujo]

Éric Araujo  added the comment:

Patch attached.  Adding people from #13175 for review/testing on Windows.

--
keywords: +needs review
nosy: +pmoore, tarek, vinay.sajip
stage: test needed -> patch review
Added file: 
http://bugs.python.org/file24494/remove-duplicate-write_record_file.diff

___
Python tracker 

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