[issue14244] No information about behaviour with groups in pattern in the docstring for re.split

[Roundup Robot]

Roundup Robot  added the comment:

New changeset b96251d9f36a by Georg Brandl in branch '3.2':
Closes #14244: add info about capturing groups and maxsplit to the docstring of 
re.split().
http://hg.python.org/cpython/rev/b96251d9f36a

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue14186] Link to PEP 3107 in "def" part of Language Reference

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c18d538d2ece by Georg Brandl in branch '3.2':
Closes #14186: add link to PEP 3107 (function annotations) to the function 
definition section.
http://hg.python.org/cpython/rev/c18d538d2ece

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue14244] No information about behaviour with groups in pattern in the docstring for re.split

[Georg Brandl]

Georg Brandl  added the comment:

Thank you, should be fixed now.

--
nosy: +georg.brandl
stage: committed/rejected -> 

___
Python tracker 

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

[issue14244] No information about behaviour with groups in pattern in the docstring for re.split

[py.user]

py.user  added the comment:

"+returning a list containing the resulting substrings.  If
+capturing parentheses are used in pattern, then the text of all
+groups in the pattern are also returned as part of the resulting
+list."

not only text

>>> import re
>>> re.split(r'(a)(x)?', 'abcabc')
['', 'a', None, 'bc', 'a', None, 'bc']
>>>

--

___
Python tracker 

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

[issue14245] float rounding examples in FAQ are outdated

[Zbyszek Szmek]

New submission from Zbyszek Szmek :

http://docs.python.org/dev/faq/design.html#why-are-floating-point-calculations-so-inaccurate

This whole paragraph is wrong since #9337 (Make float.__str__ behave 
identically to float.__repr__).
"""
The str() function prints fewer digits and this often results in the more 
sensible number that was probably intended:
>>> 1.1 - 0.9
0.20007
>>> print(1.1 - 0.9)
0.2
"""

Applies from 3.2 onwards.

--
assignee: docs@python
components: Documentation
messages: 155300
nosy: docs@python, zbysz
priority: normal
severity: normal
status: open
title: float rounding examples in FAQ are outdated
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

[issue14246] Accelerated ETree XMLParser cannot handle io.StringIO

[Phil Thompson]

New submission from Phil Thompson :

The old unaccelerated ETree XMLParser accepts input from a io.StringIO, but the 
accelerated version does not. Any code that relies on this is broken by Python 
v3.3.

--
components: XML
messages: 155301
nosy: philthompson10
priority: normal
severity: normal
status: open
title: Accelerated ETree XMLParser cannot handle io.StringIO
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

[issue14245] float rounding examples in FAQ are outdated

[Mark Dickinson]

Mark Dickinson  added the comment:

Agreed.  Do you have a suggested rewrite?

That faq entry could be improved significantly in many ways;  the tutorial 
material is much better.  I'm wondering whether it would be better to cut down 
the FAQ to much something much briefer, and leave the link to the tutorial for 
people who want more.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue14245] float rounding examples in FAQ are outdated

[Mark Dickinson]

Mark Dickinson  added the comment:

Proposed rewrite:




Why are floating point calculations inaccurate?
---

Users are often surprised by results like this::

   >>> 1.2 - 1.0
   0.16

and think it is a bug in Python.  It's not.  This has little to do with Python,
and much more to do with how the underlying platform handles floating-point
numbers.

Python floats are stored internally in binary floating-point, using a fixed
precision (typically 53 bits).  Many numbers that can be written easily in
decimal notation (``1.2``, for example), cannot be expressed exactly in this
internal binary format.  After::

   >>> x = 1.2

the value stored for x is a (very good) approximation to the value ``1.2``, but
is not exactly equal to it.  (On a typical machine, the actual stored value
is::

   1.1999555910790149937383830547332763671875

which is accurate to around 16 decimal digits.)  Similarly, the result of any
floating-point operation must often be rounded to fit into the internal format,
resulting in another tiny error.

For a more detailed explanation of what's involved, please see the chapter on
:ref:`floating point arithmetic ` in the Python tutorial.

--

___
Python tracker 

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

[issue14169] compiler.compile fails on "if" statement in attached file

[Mark Dickinson]

Mark Dickinson  added the comment:

Here's the trackback I get with Python 2.7.  Look's like something's assuming 
that POP_JUMP_IF_FALSE target of 65541 fits in 16 bits.


Python 2.7.2 (default, Jan 13 2012, 17:11:09) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> with open('small_with_error.py') as f:
... contents = f.read()
... 
>>> import compiler
>>> compiler.compile(contents, '', 'exec')
POP_JUMP_IF_FALSE 65541
114 5 256
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/compiler/pycodegen.py",
 line 65, in compile
gen.compile()
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/compiler/pycodegen.py",
 line 117, in compile
self.code = gen.getCode()
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/compiler/pycodegen.py",
 line 248, in getCode
return self.graph.getCode()
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/compiler/pyassem.py",
 line 313, in getCode
self.makeByteCode()
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/compiler/pyassem.py",
 line 518, in makeByteCode
lnotab.addCode(self.opnum[opname], lo, hi)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/compiler/pyassem.py",
 line 612, in addCode
self.code.append(chr(arg))
ValueError: chr() arg not in range(256)

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue14169] compiler.compile fails on "if" statement in attached file

[Mark Dickinson]

Mark Dickinson  added the comment:

Interestingly, dis.dis also fails to decompile the .pyc bytecode generated by 
importing the file.  (This was after adding dummy AddUnit, MakeCustomaryToBase 
and MakeBaseToCustomary definitions to the top of the file to prevent the 
import raising an exception.)


>>> with open('small_with_error.pyc', 'r') as f:
... bytecode = f.read()
... 
>>> bytecode = bytecode[8:]
>>> dis.dis(bytecode)

<... lots of output snipped ...>

   65686 LOAD_GLOBAL 4 (4)
   65689 STOP_CODE  
   65690 STOP_CODE  
   65691 POP_JUMP_IF_TRUE 27749
   65694 BUILD_TUPLE  1140
   65697 STOP_CODE  
   65698 STOP_CODE  
   65699 STOP_CODE  
   65700 STORE_GLOBAL26482 (26482)
   65703 POP_JUMP_IF_TRUE  1652
   65706 STOP_CODE  
   65707 STOP_CODE  
   65708 STOP_CODE  
   65709 COMPARE_OP  24951
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/Library/Frameworks/Python.framework/Versions/7.2/lib/python2.7/dis.py", line 
45, in dis
disassemble_string(x)
  File 
"/Library/Frameworks/Python.framework/Versions/7.2/lib/python2.7/dis.py", line 
147, in disassemble_string
print '(' + cmp_op[oparg] + ')',
IndexError: tuple index out of range

--

___
Python tracker 

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

[issue14169] compiler.compile fails on "if" statement in attached file

[Mark Dickinson]

Mark Dickinson  added the comment:

D'oh.  Ignore that last message;   all it shows is that I'm stupid.

--

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Nicholas Cole]

Nicholas Cole  added the comment:

Martin: sorry to be completely dense, but I can't get this to work properly 
with the python3.3a1 build.  Could you post some example code?

--

___
Python tracker 

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

[issue14169] compiler.compile fails on "if" statement in attached file

[Mark Dickinson]

Mark Dickinson  added the comment:

Okay, so the issue is simply that the compiler module doesn't have logic for 
emitting the EXTENDED_ARGS[1] bytecode instruction to properly deal with a jump 
target that won't fit in two bytes.  Given that the compiler module is 
deprecated, I propose closing this as 'won't fix'.

[1] http://docs.python.org/library/dis.html#opcode-EXTENDED_ARG

--

___
Python tracker 

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

[issue14243] NamedTemporaryFile unusable under Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This is quite silly indeed, and is due to the use of O_TEMPORARY in the file 
creation flags.

--
nosy: +ncoghlan, pitrou
title: NamedTemporaryFile usability request -> NamedTemporaryFile unusable 
under Windows
type:  -> behavior
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

[issue14245] float rounding examples in FAQ are outdated

[Martin v . Löwis]

Martin v. Löwis  added the comment:

+1

--
nosy: +loewis

___
Python tracker 

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

[issue14246] Accelerated ETree XMLParser cannot handle io.StringIO

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
nosy: +eli.bendersky

___
Python tracker 

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

[issue14245] float rounding examples in FAQ are outdated

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

On 03/10/2012 12:26 PM, Mark Dickinson wrote:
>
> Mark Dickinson  added the comment:
>
> Proposed rewrite:

Hi,
thanks for the quick reply. If we were to rewrite the whole entry, some 
more changes could be done:

I think it would be useful to mention explicitly that Python simply uses 
the native floating-point implementation in hardware and thus behaves 
very similarly to other languages which do this, for instance C or Java. 
This should clear up a lot of the behaviour for people who know other 
programming languages. "how the underlying platform handles 
floating-point" says something very similar, but the reader needs to 
understand what the "underlying platform" exactly is.

It is easy to count, that exactly 17 digits are accurate.

I have to admit, that I'm completely lost here --- why would a vastly 
inaccurate number (with more than half of digits wrong) be ever stored?
If "1.2" is converted to a float (a C double in current implementation), 
it has 15.96 decimal digits of precision.

"Similarly, the result of a floating-point operation must be rounded to 
fit into the fixed precision, often resulting in another tiny error." ?

--

___
Python tracker 

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

[issue14245] float rounding examples in FAQ are outdated

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

[part mangled by the tracker]

"> 1.1999555910790149937383830547332763671875
">
"> which is accurate to around 16 decimal digits.)

It is easy to count, that exactly 17 digits are accurate.

I have to admit, that I'm completely lost here --- why would a vastly
inaccurate number (with more than half of digits wrong) be ever stored?
If "1.2" is converted to a float (a C double in current implementation),
it has 15.96 decimal digits of precision.

" > Similarly, the result of any
" > floating-point operation must often be rounded to fit into the
" > internal format, resulting in another tiny error.
"Similarly, the result of a floating-point operation must be rounded to 
fit into the fixed precision, often resulting in another tiny error." ?

--

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Please see the attached width.py for an example

--
Added file: http://bugs.python.org/file24773/width.py

___
Python tracker 

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

[issue14245] float rounding examples in FAQ are outdated

[Mark Dickinson]

Mark Dickinson  added the comment:

> I think it would be useful to mention explicitly that Python simply uses 
> the native floating-point implementation in hardware and thus behaves 
> very similarly to other languages which do this, for instance C or Java. 

Agreed that it's useful to say something here to make it obvious that Python's 
behaving just like most other mainstream programming languages.  Perhaps most 
straightforward would be to state that CPython just uses C doubles.  (That 
sidesteps nitpicking about software floating-point :-).

> It is easy to count, that exactly 17 digits are accurate.

Hmm;  that depends a bit on your definitions.  The relative error here is 
around 3.7e-17, so in this particular case you're getting something between 16 
and 17 decimal digits of accuracy.  Other cases would produce different 
relative errors, with a max relative error for normal cases of 2**-53, or 
approximately 1.1e-16.

> I have to admit, that I'm completely lost here --- why would a vastly 
> inaccurate number (with more than half of digits wrong) be ever stored?

Because that number is the unique closest representable IEEE 754 double to the 
target number (1.2).  You can go through all the steps here:

 - convert 1.2 to binary, to get:

1.001100110011001100110011.  repeated ad infinitum

 - round to the nearest 53-bit number:

1.0011001100110011001100110011001100110011001100110011

 - convert back to decimal to get the number that I gave.

But this sort of detail is already there in the tutorial, and doesn't seem 
appropriate for the FAQ entry.  For the FAQ, maybe it would be less confusing 
to give only about a 20-digit approximation.

> "Similarly, the result of any
> floating-point operation must often be rounded to fit into the 
> internal format,
> resulting in another tiny error." ?

The aim here was to make the point that it's not just conversion from decimal 
to binary that introduces errors;  it's also true that any arithmetic operation 
has the potential to introduce errors.  For example, 10**16 and 1 are both 
exactly representable as floats, but the sum of 10**16 + 1 is not;  the result 
has to be rounded to fit into a float.  Suggestions for rewording to make this 
clearer are welcome!

--

___
Python tracker 

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

[issue14245] float rounding examples in FAQ are outdated

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> I think it would be useful to mention explicitly that Python simply uses
> the native floating-point implementation in hardware and thus behaves
> very similarly to other languages which do this, for instance C or Java.
> This should clear up a lot of the behaviour for people who know other
> programming languages. "how the underlying platform handles
> floating-point" says something very similar, but the reader needs to
> understand what the "underlying platform" exactly is.

Well, people may just be as confused about the term "native 
implementation" as they are seemingly confused about "underlying
platform".

 >
> I have to admit, that I'm completely lost here --- why would a vastly
> inaccurate number (with more than half of digits wrong) be ever stored?
> If "1.2" is converted to a float (a C double in current implementation),
> it has 15.96 decimal digits of precision.

Since it has this number of decimal digits of precision, the text says
"about 16", rather than "exactly 17", which would mislead people into
thinking that they get 17 digits of precision.

I don't understand your confusion. The numbers are stored in binary,
and it's *not* the case that half of the digits are wrong. In binary,
all 53 bits of mantissa are correct. When displaying this number in
decimal (which is not the way in which it is stored), then you many more
decimal digits to make the decimal representation correct.

--

___
Python tracker 

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

[issue14243] NamedTemporaryFile unusable under Windows

[Nick Coghlan]

Nick Coghlan  added the comment:

What's the proposal here? If delete is True, close() must delete the file. It 
is not acceptable for close() and __del__() to behave differently.

OTOH, if the proposal is merely to change the way the file is opened on Windows 
so that it can be opened again without closing it first, that sounds fine.

--

___
Python tracker 

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

[issue14243] NamedTemporaryFile unusable under Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> OTOH, if the proposal is merely to change the way the file is opened
> on Windows so that it can be opened again without closing it first,
> that sounds fine.

That would be my proposal. It probably needs getting rid of O_TEMPORARY,
exposing CreateFile and _open_osfhandle, and using the FILE_SHARE_DELETE
open mode.

--

___
Python tracker 

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

[issue14243] NamedTemporaryFile unusable under Windows

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +brian.curtin, tim.golden

___
Python tracker 

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

[issue13496] bisect module: Overflow at index computation

[Mark Dickinson]

Mark Dickinson  added the comment:

Updated patch, with comment.

--
Added file: http://bugs.python.org/file24774/issue13496_v2.patch

___
Python tracker 

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

[issue9574] allow whitespace around central '+' in complex constructor

[Mark Dickinson]

Mark Dickinson  added the comment:

Reclassifying as a doc issue;  I don't think my proposed change is worth it.  
I'll submit some form of Jervis's docfix shortly.

--
components: +Documentation -Interpreter Core
priority: normal -> low

___
Python tracker 

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

[issue9574] allow whitespace around central '+' in complex constructor

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 5a3c89337b50 by Mark Dickinson in branch '2.7':
Closes #9574: Note that complex constructor doesn't allow whitespace around 
central operator.
http://hg.python.org/cpython/rev/5a3c89337b50

New changeset a5b073b1cfea by Mark Dickinson in branch '3.2':
Closes #9574: Note that complex constructor doesn't allow whitespace around 
central operator.
http://hg.python.org/cpython/rev/a5b073b1cfea

New changeset 2f48415e917c by Mark Dickinson in branch 'default':
merge 3.2 (#9574)
http://hg.python.org/cpython/rev/2f48415e917c

--
nosy: +python-dev
resolution:  -> fixed
stage: patch 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

[issue14169] compiler.compile fails on "if" statement in attached file

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I agree. 'deprecated' pretty much means "We do not think this is worth the 
effort of maintaining it. Don't use it unless it is already in old code."

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

[issue13889] str(float) and round(float) issues with FPU precision

[Mark Dickinson]

Mark Dickinson  added the comment:

Patch looks fine to me.  A couple of minor points (which I'm happy to fix at 
commit time if you agree, and don't want to create a new patch):

- it looks to me as though the #ifdef _WIN32 isn't necessary any more;  it's 
enough that we're on MSVC and that this isn't a 64-bit build.

- I'd suggest replacing _PC_53 with _PC_53 | _RC_NEAR.  I know it's technically 
redundant, since _RC_NEAR happens to be 0, but it makes the intent of the code 
clearer.

I'd still want to see all the tests pass on both x64 and x86 Windows before 
applying this;  I may have an opportunity to test this on x64 in the near 
future.

--

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[poq]

poq  added the comment:

Martin, I think you meant to write "if w == 'A':".
Some very common characters have ambiguous widths though (e.g. the Greek 
alphabet), so you can't just raise an error for them.

http://unicode.org/reports/tr11/ says:
"Ambiguous characters occur in East Asian legacy character sets as wide 
characters, but as narrow (i.e., normal-width) characters in non-East Asian 
usage."

So in practice applications can treat ambiguous characters as narrow by 
default, with a user setting to use legacy (wide) width.

As Tom pointed out there are also a bunch of zero width characters, and 
characters with special formatting like tab, soft hyphen, ...

--
nosy: +poq

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Tom Christiansen]

Tom Christiansen  added the comment:

I would encourage you to look at the Perl CPAN module Unicode::LineBreak,
which fully implements tr11.  It includes Unicode::GCString, a class
that has a columns() method to determine the print columns.  This is very
fancy in the case of Asian widths, but of course there are many other cases too.

If you'd like, I can show you a program that uses these, a rewrite the
standard Unix fmt(1) filter that works properly on Unicode column widths.

--tom

--

___
Python tracker 

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

[issue4761] create Python wrappers for openat() and others

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Why use a special value AT_FDCWD instead of None? It is not Pythonish. Clearly, 
when it is used in C, but in dynamically typed Python we are not limited to 
only one C-type. 

Such a large number of new functions littering the namespace. Why not just add 
additional arguments to existing functions? Instead 'fstatat(dirfd, path, 
flags=0)' let it be 'stat(path, *, dirfd=None, flags=0)' or even better 
'stat(path, *, dirfd=None, followlinks=True)' (as in os.fwalk).

--
nosy: +storchaka

___
Python tracker 

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

[issue14204] Support for the NPN extension to TLS/SSL

[Colin Marc]

Colin Marc  added the comment:

Here's an updated patch against 3.3.

--
Added file: http://bugs.python.org/file24775/npn_patch_py3.diff

___
Python tracker 

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

[issue4761] create Python wrappers for openat() and others

[Georg Brandl]

Georg Brandl  added the comment:

I agree about the constant AT_FDCWD.  (At least, None should be allowed in 
addition.)

Your other proposition would break the principle of very thin platform wrappers 
that we try to follow in posixmodule.c.

--
status: closed -> open

___
Python tracker 

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

[issue13496] bisect module: Overflow at index computation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for the updated patch.

--

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Changes by Stefan Krah :


Added file: http://bugs.python.org/file24776/9b3b1f5c4072.diff

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

Here's a new patch that addresses several remarks:

  o _decimal now has __floor__ and __ceil__methods.

  o libmpdec is now in a separate directory.

  o I removed the big libmpdec test suite. This is why:

 - It reduces the number of files that has been criticized multiple times.

 - Probably I'll be the only one who will be running the test suite.

 - The test suite is still on PyPI.

 - The test suite is so large that it's a magnet for toolchain bugs.
   For example, it found a bug in suncc (acknowledged and fixed by Sun)
   and a bug in CompCert (acknowledged and fixed by Xavier Leroy).

   I'm really worried that *if* someone runs the tests and finds
   an obscure bug, I'll have to spend hours debugging something
   that might ultimately be an external bug.

  o Renamed "python" directory into "tests".

  o Test functions in mpdecimal.c are removed.

  o All files in libmpdec that aren't required for _decimal are removed.

  o Extra functionality in _decimal.c is commented out. This does not
yet cover the FloatOperation signal, which I would like to add
to decimal.py as well (I'll ask later on python-dev).

--

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

Here's a new patch that addresses several remarks:

  o _decimal now has __floor__ and __ceil__methods.

  o libmpdec is now in a separate directory.

  o I removed the big libmpdec test suite. This is why:

 - It reduces the number of files that has been criticized multiple times.

 - Probably I'll be the only one who will be running the test suite.

 - The test suite is still on PyPI.

 - The test suite is so large that it's a magnet for toolchain bugs.
   For example, it found a bug in suncc (acknowledged and fixed by Sun)
   and a bug in CompCert (acknowledged and fixed by Xavier Leroy).

   I'm really worried that *if* someone runs the tests and finds
   an obscure bug, I'll have to spend hours debugging something
   that might ultimately be an external bug.

  o Renamed "python" directory into "tests".

  o Test functions in mpdecimal.c are removed.

  o All files in libmpdec that aren't required for _decimal are removed.

  o Extra functionality in _decimal.c is commented out. This does not
yet cover the FloatOperation signal, which I would like to add
to decimal.py as well (I'll ask later on python-dev).

--

___
Python tracker 

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

[issue14247] "in" operator doesn't return boolean

[Damjan Košir]

New submission from Damjan Košir :

In operator acts like it doesn't return a boolean value

>>> 3 in [1,2,3] == True
False

and even

>>> 3 in [1,2,3] == 3 in [1,2,3]
False

but somehow if you add ( ) it starts working

>>> (3 in [1,2,3]) == True
True

Tested on OSX 10.7 Python 2.7.1

--
components: None
messages: 155329
nosy: Damjan.Košir
priority: normal
severity: normal
status: open
title: "in" operator doesn't return boolean
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

[issue14247] "in" operator doesn't return boolean

[Georg Brandl]

Georg Brandl  added the comment:

Chaining comparison operators inserts implicit "and" conditions:

  a OP b OP c OP d

is equivalent to

  (a OP b) and (b OP c) and (c OP d)

This is most useful with ==, <, <= and so forth, but "in" and "is" also count 
as comparison ops and have the same precedence.

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

[issue14243] NamedTemporaryFile unusable under Windows

[Dave Abrahams]

Dave Abrahams  added the comment:

I disagree that it's unacceptable for close() and __del__() to behave 
differently.  The acceptable difference would be that __del__() closes (if 
necessary) /and/ deletes the file on disk, while close() merely closes the file.

If you can in fact "change the way the file is opened on Windows so that it can 
be opened again without closing it first," that would be fine with me.  It 
isn't clear to me that Windows supports that option, but I'm not an expert.

Another possibility, of course, is something like what's implemented in:
https://github.com/dabrahams/zeroinstall/commit/d76de038ef51bd1dae36280f8743e06c7154b44a#L3R44
(an optional argument to close() that prevents deletion).

--

___
Python tracker 

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

[issue14204] Support for the NPN extension to TLS/SSL

[Colin Marc]

Colin Marc  added the comment:

Oops, I had my vim configured wrong and left a few tab characters in there. 
Here's another updated patch =)

--
Added file: http://bugs.python.org/file24777/npn_patch_py3.diff

___
Python tracker 

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

[issue14246] Accelerated ETree XMLParser cannot handle io.StringIO

[Eli Bendersky]

Eli Bendersky  added the comment:

Hi Phil,

Could you please post the problematic code snippet that runs with 3.2 but not 
3.3?

Thanks in advance

--

___
Python tracker 

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

[issue14245] float rounding examples in FAQ are outdated

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

Proposed rewrite (building on Mark's version):
- mention C doubles
- explain ``1.2`` example a bit more

"""
Why are floating-point calculations inaccurate?
---

Users are often surprised by results like this::

   >>> 1.2 - 1.0
   0.16

and think it is a bug in Python.  It's not.  This has little to do with Python,
and much more to do with how the underlying platform handles floating-point
numbers.

The float type in CPython simply uses C ``double`` for storage. The number is 
stored in binary floating-point with a fixed precision (typically 53 bits) and 
Python uses C operations, which in turn rely on the hardware implementation in 
the processor, to perform floating-point operations. This means that as far as 
floating-point operations are concerned, Python behaves like many popular 
languages including C and Java.

Many numbers that can be written easily in decimal notation (``1.2``, for 
example), cannot be expressed exactly in the binary format.  After::

   >>> x = 1.2

the value stored for ``x`` is a (very good) approximation of the value ``1.2``, 
but
is not exactly equal to it.  On a typical machine, the actual stored value
is::

   1.0011001100110011001100110011001100110011001100110011 (binary)

which is approximately::

   1.19995559 (decimal)

53 binary digits are equivalent to about 16 decimal digits and in this case the 
first 17 digits are correct after the conversion back to decimal.

Similarly, the result of any floating-point operation must be rounded to 
fit into the fixed precision, often resulting in another tiny error.

For a more detailed explanation of what's involved, please see the chapter on
:ref:`floating point arithmetic ` in the Python tutorial.
"""

--

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Nicholas Cole]

Nicholas Cole  added the comment:

Marting and Poq: I think the sample code shows up a real problem. "Ambiguous" 
characters according to unicode may be rendered by curses in different ways.

Don't we need a function that actually reports how curses is going to print a 
given string, rather than just reporting what the unicode standard says?

--

___
Python tracker 

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

[issue6147] multithreading.Pool.map() crashes Windows computer

[Merlijn van Deen]

Merlijn van Deen  added the comment:

Two questions:
(1) can this be at least be added as a big fat warning in the documentation?
(2) would it be a reasonable option to let either
  (a) the creation of a Pool
  (b) executing something using the Pool
cause an exception when it happens during the import of the function to run?

I think it makes sense to prevent any accidental forkbombs, especially if they 
are /this/ easy to create. Untested (for obvious reasons...), but this should 
be enough:

import multiprocessing
def x(val):
   return val
multiprocessing.Pool().map(x, range(10))

--
nosy: +valhallasw

___
Python tracker 

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

[issue14246] Accelerated ETree XMLParser cannot handle io.StringIO

[Eli Bendersky]

Eli Bendersky  added the comment:

Note that this code works fine:

---
tree = ET.ElementTree()
stream = io.BytesIO()
stream.write(b'''


''')
stream.seek(0)
tree.parse(stream)

print(tree.getroot())
---

--

___
Python tracker 

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

[issue14204] Support for the NPN extension to TLS/SSL

[Sidney San Martín]

Changes by Sidney San Martín :


--
nosy: +ssm

___
Python tracker 

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

[issue4761] create Python wrappers for openat() and others

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Addition/Substitution of None I think should be in a new issue.

--
status: open -> closed

___
Python tracker 

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

[issue9232] Allow trailing comma in any function argument list.

[Mark Dickinson]

Changes by Mark Dickinson :


--
assignee: mark.dickinson -> 

___
Python tracker 

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

[issue9154] Parser module doesn't understand function annotations.

[Mark Dickinson]

Changes by Mark Dickinson :


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

[issue14245] float rounding examples in FAQ are outdated

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> - explain ``1.2`` example a bit more

+1 for giving the binary representation; -1 for rounding
the decimal version of it.

--

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Martin, I think you meant to write "if w == 'A':".
> Some very common characters have ambiguous widths though (e.g. the Greek 
> alphabet), so you can't just raise an error for them.

That's precisely why I don't think this should be in the library, but
in the application. Application developers who need that also need
to concern themselves with the border cases, and decide on how
they need to resolve them.

--

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> I would encourage you to look at the Perl CPAN module Unicode::LineBreak,
> which fully implements tr11.

Thanks for the pointer!

> If you'd like, I can show you a program that uses these, a rewrite the
> standard Unix fmt(1) filter that works properly on Unicode column widths.

I believe there can't be any truly "proper" implementation, as you
can't be certain how the terminal will handle these itself. In any
case, anybody who is interested in contributing a patch should also
be capable of understanding the source of Unicode::LineBreak.

--

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Tom Christiansen]

Tom Christiansen  added the comment:

>Martin v. L=C3=B6wis  added the comment:

>> Martin, I think you meant to write "if w =3D=3D 'A':".
>> Some very common characters have ambiguous widths though (e.g. the Greek =
>alphabet), so you can't just raise an error for them.

>That's precisely why I don't think this should be in the library, but
>in the application. Application developers who need that also need
>to concern themselves with the border cases, and decide on how
>they need to resolve them.

The column-width of a string is not an application issue.  It is
well-defined by Unicode.  Again, please see how we've done it in 
Perl, where tr11 is fully implemented.  The columns() method from 
Unicode::GCString always gives the right answer per the Standard for
any string, even what you are calling ambiguous ones.

This is not an applications issue -- at all.

--tom

--

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Don't we need a function that actually reports how curses is going to
> print a given string, rather than just reporting what the unicode
> standard says?

That may be useful, but

a) this patch doesn't provide that, and
b) it may not actually possible to implement such a change in a portable
way as there may be no function exposed by the curses implementation
that provides this information.

To put my closing this issue differently: I rejected the patch that
Victor initially submitted. If anybody wants to contribute a different
patch that uses a different strategy, please submit a new issue.

--

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
resolution: works for me -> 
status: closed -> open

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Tom Christiansen]

Tom Christiansen  added the comment:

>Martin v. L=C3=B6wis  added the comment:

>> I would encourage you to look at the Perl CPAN module Unicode::LineBreak,
>> which fully implements tr11.

>Thanks for the pointer!

>> If you'd like, I can show you a program that uses these, a rewrite the
>> standard Unix fmt(1) filter that works properly on Unicode column widths.

>I believe there can't be any truly "proper" implementation, as you
>can't be certain how the terminal will handle these itself. 

Hm.  I think we may not be talking about the same thing after all.

If we're talking about the Curses library, or something similar,
this is not the same.  I do not think Curses has support for 
combining characters, right to left text, wide characters, etc.

However, Unicode does, and defines the column width for those.

I have an illustration of what this looks like in the picture
in the very last recipe, #44, in 

http://training.perl.com/scripts/perlunicook.html

That is what I have been talking about by print widths.  It's running
in a Mac terminal emulator, and unlike the HTML which grabs from too
many fonts, the terminal program does the right thing with the widths.

Are we talking about different things?

--tom

--

___
Python tracker 

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

[issue14248] Typo in "What’s New In Python 3.3": "comparaison"

[Jakub Wilk]

New submission from Jakub Wilk :

Typo in Doc/whatsnew/3.3.rst: "comparaison" -> "comparison".

--
assignee: docs@python
components: Documentation
messages: 155347
nosy: docs@python, jwilk
priority: normal
severity: normal
status: open
title: Typo in "What’s New In Python 3.3": "comparaison"
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

[issue14248] Typo in "What’s New In Python 3.3": "comparaison"

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 9afbb3af1693 by Georg Brandl in branch 'default':
Close #14248: fix typo.
http://hg.python.org/cpython/rev/9afbb3af1693

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue14245] float rounding examples in FAQ are outdated

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

On 03/10/2012 07:52 PM, Martin v. Löwis wrote:
>> - explain ``1.2`` example a bit more
>
> +1 for giving the binary representation; -1 for rounding
> the decimal version of it.

Oh, 1.1999555910790149937383830547332763671875
is exactly equal to 
1.0011001100110011001100110011001100110011001100110011. In this case 
yes, rounding it is not beneficial.

So one more version (without this rounding):

"""
Why are floating-point calculations inaccurate?
---

Users are often surprised by results like this::

>>> 1.2 - 1.0
0.16

and think it is a bug in Python.  It's not.  This has little to do with 
Python, and much more to do with how the underlying platform handles 
floating-point numbers.

The float type in CPython simply uses C ``double`` for storage. The 
number is stored in binary floating-point with a fixed precision 
(typically 53 bits) and Python uses C operations, which in turn rely on 
the hardware implementation in the processor, to perform floating-point 
operations. This means that as far as floating-point operations are 
concerned, Python behaves like many popular languages including C and Java.

Many numbers that can be written easily in decimal notation (``1.2``, 
for example), cannot be expressed exactly in the binary format.  After::

>>> x = 1.2

the value stored for ``x`` is a (very good) approximation of the value 
``1.2``, but is not exactly equal to it.  On a typical machine, the 
actual stored value is::

1.0011001100110011001100110011001100110011001100110011 (binary)

which is exactly::

1.1999555910790149937383830547332763671875 (decimal)

53 binary digits are equivalent to about 16 decimal digits and in this 
case the first 17 digits are correct after the conversion back to decimal.

Similarly, the result of any floating-point operation must be rounded to 
fit into the fixed precision, often resulting in another tiny error.

For a more detailed explanation of what's involved, please see the 
chapter on :ref:`floating point arithmetic ` in the 
Python tutorial.
"""

--

___
Python tracker 

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

[issue14204] Support for the NPN extension to TLS/SSL

[Colin Marc]

Colin Marc  added the comment:

Here's the OpenSSL code I referenced for my implementation. It's an excerpt of 
ssl/lib_ssl.c, starting at line 1514.

--
Added file: http://bugs.python.org/file24778/npn_openssl_ref.c

___
Python tracker 

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

[issue14242] Make subprocess.Popen aware of $SHELL

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +gregory.p.smith
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.4

___
Python tracker 

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

[issue14242] Make subprocess.Popen aware of $SHELL

[Éric Araujo]

Éric Araujo  added the comment:

Note that it’s already possible to use any shell with the “executable” argument.

Is there any official spec (i.e. POSIX) for the SHELL environment variable?

--
nosy: +eric.araujo

___
Python tracker 

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

[issue14210] add filename completion to pdb

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 01a25f638c83 by Georg Brandl in branch 'default':
Close #14210: add command argument completion to pdb: complete file names, 
global/local variables, aliases
http://hg.python.org/cpython/rev/01a25f638c83

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue14229] On KeyboardInterrupt, the exit code should mirror the signal number

[Éric Araujo]

Éric Araujo  added the comment:

The Debian bug has some more convincing examples:

> any Python program which is expected to implement the interface of (say) 
> "diff" is buggy, because
> it may exit status 1 ("comparison successful; differences found") when it 
> should have died with
> SIGINT ("comparison not completed due to interrupt signal"); this could in 
> principle cause data loss
> in some applications.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue14229] On KeyboardInterrupt, the exit code should mirror the signal number

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Since Python *does* handle the signal, and exits "regularly", we
> shouldn't

You are arguing from a legal point of view, but from a pratical point of view 
Python doesn't really "handle" the signal: it just defers the exit until after 
all internal structures are cleaned up.

--

___
Python tracker 

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

[issue14246] Accelerated ETree XMLParser cannot handle io.StringIO

[Phil Thompson]

Phil Thompson  added the comment:

This variation of your test doesn't...

---
import io

from xml.etree.ElementTree import parse

stream = io.StringIO()

stream.write('''


''')

stream.seek(0)

parsed = parse(stream)

print(parsed)
---

Phil

--

___
Python tracker 

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

[issue14246] Accelerated ETree XMLParser cannot handle io.StringIO

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue14242] Make subprocess.Popen aware of $SHELL

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

POSIX documents SHELL variable:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

--
nosy: +Arfrever

___
Python tracker 

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

[issue14249] unicodeobject.c: aliasing warnings

[Stefan Krah]

New submission from Stefan Krah :

There are a couple of aliasing warnings in non-debug mode. For example:

http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/1741


Objects/object.c:293: warning: ignoring return value of 'fwrite', declared with 
attribute warn_unused_result
Objects/object.c:302: warning: ignoring return value of 'fwrite', declared with 
attribute warn_unused_result
Objects/unicodeobject.c:5533: warning: dereferencing pointer 'pblock' does 
break strict-aliasing rules
Objects/unicodeobject.c:5533: warning: dereferencing pointer 'pblock' does 
break strict-aliasing rules
Objects/unicodeobject.c:5533: warning: dereferencing pointer 'pblock' does 
break strict-aliasing rules
Objects/unicodeobject.c:5523: warning: dereferencing pointer 'pblock' does 
break strict-aliasing rules
Objects/unicodeobject.c:5523: warning: dereferencing pointer 'pblock' does 
break strict-aliasing rules
cc1: warning: dereferencing pointer 'pblock' does break strict-aliasing rules
cc1: warning: dereferencing pointer 'pblock' does break strict-aliasing rules
cc1: warning: dereferencing pointer 'pblock' does break strict-aliasing rules
Objects/unicodeobject.c:5523: warning: dereferencing pointer 'pblock' does 
break strict-aliasing rules
Objects/unicodeobject.c:5523: warning: dereferencing pointer 'pblock' does 
break strict-aliasing rules
Objects/unicodeobject.c:5533: warning: dereferencing pointer 'pblock' does 
break strict-aliasing rules
Objects/unicodeobject.c:5533: warning: dereferencing pointer 'pblock' does 
break strict-aliasing rules
Objects/unicodeobject.c:5533: warning: dereferencing pointer 'pblock' does 
break strict-aliasing rules
cc1: warning: dereferencing pointer 'pblock' does break strict-aliasing rules
cc1: warning: dereferencing pointer 'pblock' does break strict-aliasing rules
cc1: warning: dereferencing pointer 'pblock' does break strict-aliasing rules

--
components: Build
keywords: buildbot
messages: 155357
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: unicodeobject.c: aliasing warnings
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

[issue4761] create Python wrappers for openat() and others

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Perhaps it is better not export these functions in the `os` module, leaving 
them in `posix`?

In addition, `stat` and `lstat` is not very thin wrappers (especially on 
Windows) given that they are working with `bytes` and with `str`.

--

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

Please add --with-system-libmpdec (or --with-system-mpdecimal) option in 
`configure`, similarly to --with-system-expat and --with-system-ffi options.

--
nosy: +Arfrever

___
Python tracker 

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

[issue14229] On KeyboardInterrupt, the exit code should mirror the signal number

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue14242] Make subprocess.Popen aware of $SHELL

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Users who want to use the SHELL environment variable can do so on their own by 
using it as their executable and constructing an appropriate command line.

Allowing an environment variable to change the behavior of a program that  
assumes shell=True is going to be /bin/sh compatible by default (as it has been 
for ages) is a bad idea.

--
assignee:  -> gregory.p.smith
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

[issue12568] Add functions to get the width in columns of a character

[poq]

poq  added the comment:

It seems this is a bit of a minefield...

GNOME Terminal/libvte has an environment variable (VTE_CJK_WIDTH) to override 
the handling of ambiguous width characters. It bases its default on the locale 
(with the comment 'This is basically what GNU libc does').

urxvt just uses system wcwidth.

Xterm uses some voodoo to decide between system wcwidth and mk_wcwidth(_cjk): 
http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c

I think the simplest solution is to just expose libc's wc(s)width. It is widely 
used and is most likely to match the behaviour of the terminal.

FWIW I wrote a little script to test the widths of all Unicode characters, and 
came up with the following logic to match libvte behaviour:

def wcwidth(c, legacy_cjk=False):
if c in u'\t\r\n\10\13\14': raise ValueError('character %r has no 
intrinsic width' % c)
if c in u'\0\5\7\16\17': return 0
if u'\u1160' <= c <= u'\u11ff': return 0 # hangul jamo
if unicodedata.category(c) in ('Mn', 'Me', 'Cf') and c != u'\u00ad': 
return 0 # 00ad = soft hyphen
eaw = unicodedata.east_asian_width(c)
if eaw in ('F', 'W'): return 2
if legacy_cjk and eaw == 'A': return 2
return 1

--

___
Python tracker 

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

[issue14250] regex.flags is never equal to 0

[py.user]

New submission from py.user :

http://docs.python.org/py3k/library/re.html#re.regex.flags
"or 0 if no flags were provided"

>>> import re
>>> p = re.compile(r'', 0)
>>> p.flags
32
>>>

--
assignee: docs@python
components: Documentation, Regular Expressions
messages: 155362
nosy: docs@python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: regex.flags is never equal to 0
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

[issue14250] regex.flags is never equal to 0

[R. David Murray]

R. David Murray  added the comment:

32 is re.U, which is always ored with the passed in flags, unless re.A is set 
in the passed in flags.  The flag docs should certinaly be updated to reflect 
this.

--
nosy: +r.david.murray
stage:  -> needs patch
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

[issue14190] Minor C API documentation bugs

[Ejaj Hassan]

Ejaj Hassan  added the comment:

The patch removes the function *PyCodec_KnownEncoding
form document codec.rst
found in cpython/doc/c-api

--
keywords: +patch
nosy: +ejjy
Added file: http://bugs.python.org/file24779/issues14190.diff

___
Python tracker 

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

[issue14243] NamedTemporaryFile unusable under Windows

[Nick Coghlan]

Nick Coghlan  added the comment:

The whole point of close() methods is to offer deterministic resource 
management to applications that need it. Pointing out to applications when 
they're relying on CPython's refcounting for prompt resource cleanup is why 
many of the standard types now trigger ResourceWarning for any application that 
relies on the GC to clean up such external resources in __del__.

So, no, we're not going to back away from the explicit guarantee in the 
NamedTemporaryFile docs: "If delete is true (the default), the file is deleted 
as soon as it is closed." (Especially since doing so would also breach backward 
compatibility guarantees)

However, you're right that the exclusive read lock in the current 
implementation makes the default behaviour of NamedTemporaryFile significantly 
less useful on Windows than it is on POSIX systems, so the implementation 
should be changed to behave more like the POSIX variant.

--

___
Python tracker 

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

[issue14251] [PATCH]HTMLParser decode issue

[rednaks]

New submission from rednaks :

Hello !
while parsing a HTML code i got an decode Error :

but this issue can be fixed by replacing  the last string by s.decode() like in
the diff file.
I also tried to execute my script under python3.2 and it does not parsing any 
thing 

  File "/usr/lib/python2.7/HTMLParser.py", line 111, in feed
self.goahead(0)
  File "/usr/lib/python2.7/HTMLParser.py", line 155, in goahead
k = self.parse_starttag(i)
  File "/usr/lib/python2.7/HTMLParser.py", line 260, in parse_starttag
attrvalue = self.unescape(attrvalue)
  File "/usr/lib/python2.7/HTMLParser.py", line 410, in unescape
return re.sub(r"&(#?[xX]?(?:[0-9a-fA-F]+|\w{1,8}));", replaceEntities, s)
  File "/usr/lib/python2.7/re.py", line 151, in sub
return _compile(pattern, flags).sub(repl, string, count)
UnicodeDecodeError: 'ascii' codec can't decode byte 0x97 in position 1: ordinal
not in range(128)

--
components: Library (Lib)
files: patch.txt
messages: 155366
nosy: rednaks
priority: normal
severity: normal
status: open
title: [PATCH]HTMLParser decode issue
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file24780/patch.txt

___
Python tracker 

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

[issue14251] [PATCH]HTMLParser decode issue

[Ezio Melotti]

Ezio Melotti  added the comment:

Can you provide a minimal example to reproduce this error?

On Python 2 it's always better to decode the HTML first and then pass unicode 
to the parser.  Even though on Python 2 the parser accepts bytes string too, 
there are a few corner cases where it fails.

On Python 3 the parser only accepts unicode, and it should work fine with it 
(especially if you have an updated clone of cpython).  Can you show what 
failure you get with Python 3?  Also, can you reproduce the error if you use 
strict=False?

--
assignee:  -> ezio.melotti
nosy: +ezio.melotti
type: crash -> behavior

___
Python tracker 

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

[issue14251] [PATCH]HTMLParser decode issue

[Ezio Melotti]

Ezio Melotti  added the comment:

See also #3932.

--

___
Python tracker 

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

[issue14190] Minor C API documentation bugs

[Ejaj Hassan]

Ejaj Hassan  added the comment:

The diff file is the second submission containing the fixes to the following 
bugs:
* PyCode_GetNumFree accepts a PyCodeObject* not PyObject*
* PyOS_strnicmp returns int, not char*
* PyUnicode_RichCompare returns PyObject*, not int
* PyType_IS_GC needs a PyTypeObject*, not PyObject*
* PyType_HasFeature needs a PyTypeObject*, not PyObject*
 
Well, if the problems given are specified with each's version, then it would 
make it easier. Some of the reported bugs are not associated with version 2.7

--
Added file: http://bugs.python.org/file24781/issues14190-2.diff

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Tom: I don't think Unicode::GCString implements UAX#11 correctly (but this is 
really out of scope of this issue). In particular, it contains an ad-hoc 
decision to introduce the EA_Z east-asian width that UAX#11 doesn't talk about.

In most cases, it's probably reasonable to introduce this EA_Z feature. 
However, there are some significant deviations from UAX#11 here:
- combining characters are given EA_Z in sombok/data/custom.pl, even though 
UAX#11 assigns A or N. UAX#11 points out that the advance width depends on 
whether or not the terminal performs character combination or not. It's not 
clear whether Unicode::GCString aims for "strict" UAX#11, or "advance width".
- control characters are also given EA_Z, even though UAX#11 gives them EA_N. 
In this case, it's neither UAX#11 width nor advance width since control 
characters will have various effects on the terminal (in particular for the tab 
character)

--

___
Python tracker 

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

[issue9949] os.path.realpath on Windows does not follow symbolic links

[Dave Burton]

Dave Burton  added the comment:

It seems that the nt module is implemented in the posixmodule.c source file, 
and the Python 3 version contains the posix__getfinalpathname entry point, but 
the Python 2 version does not.

I presume that PyWin32 could also be used to work around this.  Too bad it 
isn't automatically included with Python:
http://sourceforge.net/projects/pywin32/files/pywin32/Build%20217/

--

___
Python tracker 

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

[issue9949] os.path.realpath on Windows does not follow symbolic links

[Brian Curtin]

Brian Curtin  added the comment:

file, and the Python 3 version contains the posix__getfinalpathname entry
point, but the Python 2 version does not.
>
> I presume that PyWin32 could also be used to work around this.  Too bad
it isn't automatically included with Python:
> http://sourceforge.net/projects/pywin32/files/pywin32/Build%20217/

We can't use external packages in the standard library. If you're looking
for a Python which includes pywin32, ActiveState provides this.

I think we can just implement the function we need.

--

___
Python tracker 

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

[issue12568] Add functions to get the width in columns of a character

[Martin v . Löwis]

Martin v. Löwis  added the comment:

poq: I still remain opposed to exposing wcswidth, since it is just as incorrect 
as any of the other solutions that people have circulated. I could agree to it 
if it was called "wcswidth", making it clear that it does whatever the C 
library does, with whatever semantics the C library wants to give to it (and an 
availability that depends on whether the C library supports it or not). 

That would probably cover the nurses use cases, except that it is not only 
incorrect with respect to Unicode, but also incorrect with respect to what the 
terminal may be doing. I guess users would use it anyway.

For Python's internal use, I could accept using the sombok algorithm. I 
wouldn't expose it, since it again would trick people into believing that it 
was correct in some sense. Perhaps calling it sombok_width might allow for 
exposing it.

--

___
Python tracker 

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

[issue14243] NamedTemporaryFile unusable under Windows

[Dave Abrahams]

Dave Abrahams  added the comment:

If file.close() "offers deterministic resource management," then you have to 
consider the file's open/closed state to be a resource separate from its 
existence.  A NamedTemporaryFile whose close() deterministically managed the 
open/closed state but not the existence of the file would be consistent with 
file.  That said, I understand the move toward deprecating (in the informal 
sense) cleanups that rely on GC.

I'm not suggesting breaking backward compatibility, either.  I'm suggesting 
that it might make sense to allow an explicit close-without-delete as an 
/extension/ of the current interface.  Given the move away from GC-cleanups, 
you'd probably want an explicit unlink() method as well in that case.

--

___
Python tracker 

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

[issue14243] NamedTemporaryFile unusable under Windows

[Nick Coghlan]

Nick Coghlan  added the comment:

Dave, decoupling the lifecycle of the created file from the object that created 
it is exactly what delete=False already covers. The complicated dance in 
NamedTemporaryFile is only to make *__del__* work  a bit more reliably during 
process shutdown (due to some messy internal problems with what CPython is 
doing at that point). If you're doing deterministic cleanup (even via atexit), 
you don't need any of that - you can just use os.unlink().

--

___
Python tracker 

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

[issue14246] Accelerated ETree XMLParser cannot handle io.StringIO

[Eli Bendersky]

Changes by Eli Bendersky :


--
assignee:  -> eli.bendersky
keywords: +3.2regression
stage:  -> needs patch

___
Python tracker 

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

[issue9949] os.path.realpath on Windows does not follow symbolic links

[Dave Burton]

Dave Burton  added the comment:

Excellent!

The ntpath.py change is nearly identical in Python 2.7 to the change for Python 
3.2.  The only difference is that instead of:

+elif isinstance(path, bytes):
+path = os.getcwdb()

It is:

+elif isinstance(path, unicode):
+path = os.getcwdu()

--

___
Python tracker 

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

[issue14246] Accelerated ETree XMLParser cannot handle io.StringIO

[Eli Bendersky]

Eli Bendersky  added the comment:

Both the Python ET and _elementtree use expat, but reach its parsing function 
in a different path when given a file-like object (StringIO, BytesIO).

Python ET reads the stream itself and passes the data to pyexpat's Parse 
method, which uses PyArg_ParseTuple to decode it. The latter turns a string 
into bytes when required, so the parsing of str streams is handled 
transparently.

For _elementtree, on the other hand, ET directly calls the internal 
XMLParser._parse, which uses its own (C) loop to read from the stream. When it 
sees that it hasn't read bytes (but a string) it stops and falls back on 
parsing an empty document.

The fix will have to be in the latter loop, probably just converting the read 
string to bytes before moving on.

--

___
Python tracker 

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