[issue25885] ast Str type does not annotate the string type when it parses a python document

[Myron Walker]

New submission from Myron Walker:

The 'ast' module does not indicate the type of string, ''' or '"' or '"""', 
that it has encountered when it parses a python document.

This prevents accurate reproduction of the original parsed document by a writer 
walking over an instance of a abstract syntax tree.

--
components: Extension Modules
messages: 256529
nosy: Myron Walker
priority: normal
severity: normal
status: open
title: ast Str type does not annotate the string type when it parses a python 
document
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue25885] ast Str type does not annotate the string type when it parses a python document

[SilentGhost]

Changes by SilentGhost :


--
components: +Library (Lib)
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan
stage:  -> test needed

___
Python tracker 

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

[issue25884] inspect.getmro() fails when base class lacks __bases__ attribute.

[Brandon Zerbe]

Brandon Zerbe added the comment:

I am using Python 2.7.5.  The segment of code from inspect that I previously 
extracted came from line 332 although you may also find it by "finding" 
_searchbases.

This is really an issue with Forthon:

http://hifweb.lbl.gov/Forthon/

Specifically the Forthon class, which I think is older than current standards.  
If you guys want this Forthon class to flag an error (I can work around that 
too), than the proposed fix I sent can be rejected, and this ticket can be 
closed.  I just wanted to bring this case to you attention just in case.

Thanks again,

Brandon

Quoting "R. David Murray" :

>
> R. David Murray added the comment:
>
> Which version of python are you running?  I can't match that 
> traceback up to the code in the current 2.7 inspect module.
>
> That said, the same issue probably exists in the current code.  A 2.7 
> class is expected to have either an __mro__ or a __bases__ attribute, 
> and if it has neither inspect probably *should* throw an error, since 
> it can't know what to do with the class.  The error could be clearer, 
> though.
>
> But, let's see what others think.
>
> --
> nosy: +r.david.murray
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue25883] python 2.7.11 mod_wsgi regression on windows

[Steve Dower]

Steve Dower added the comment:

This is probably the registry key issue25824. That'll often show up as an 
import error on site if you're loading python##.dll while outside of an install 
directory. Without the key, it can't find its way to the stdlib.

Try renaming the registry key as described in that issue and see if it works.

--

___
Python tracker 

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

[issue25885] ast Str type does not annotate the string type when it parses a python document

[Brett Cannon]

Brett Cannon added the comment:

Two things. One, this won't change in Python 2.7 due to compatibility, so this 
only applies to Python 3.6. Two, the AST has not been designed to support 
round-trip syntax transpiling, e.g. there is no way to get back comments in the 
source code.

Because the AST is not meant to round-trip on source code I'm going to close 
this as "not a bug" since I don't see any benefit in supporting this even if we 
gain comment nodes in the AST.

--
resolution:  -> not a bug
status: open -> closed
versions: +Python 3.6 -Python 2.7

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

[SilentGhost]

Changes by SilentGhost :


--
nosy: +SilentGhost

___
Python tracker 

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

[issue25885] ast Str type does not annotate the string type when it parses a python document

[R. David Murray]

R. David Murray added the comment:

Unlike the tokenizer, I don't think the AST module makes any guarantee about 
being able to reproduce the original source.  This might be a reasonable 
enhancement request, though.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue25885] ast Str type does not annotate the string type when it parses a python document

[R. David Murray]

R. David Murray added the comment:

Please respect the decisions of the python core developers as to issue status 
(you can argue with us until we ask you to stop, but let us make the status 
change if you convince us :)

We aren't rejecting your ideas, just this bug report (as not being a bug).  To 
pursue your ideas you will want to subscribe to the python-ideas mailing list 
and begin a discussion there.  This is far too big a topic for the bug tracker.

--
status: open -> closed

___
Python tracker 

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

[issue25886] ast module is combining string literals that are concatenated with plus operator

[Brett Cannon]

Changes by Brett Cannon :


--
resolution: duplicate -> not a bug

___
Python tracker 

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

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

[Martin Panter]

Martin Panter added the comment:

I think changing the TextIOBase API would be hard to do if you want to keep 
compatibility with existing code. I agree that encoding the position to a 
number and back seems like a bad design, but I doubt it is worth changing it at 
this point.

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Martin Panter]

Martin Panter added the comment:

It should always be valid to create a new coroutine instance. Perhaps you meant:

instance = foo()
print(await instance)  # Okay the first time
print(await instance)  # Second time should be an error

This seems sensible, at least for 3.6. Maybe it should also be an error to 
re-await if the coroutine raised an exception, and if it was cancelled via 
close().

--
nosy: +martin.panter

___
Python tracker 

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

[issue25886] ast module is combining string literals that are concatenated with plus operator

[SilentGhost]

SilentGhost added the comment:

Hm, I'm going to close this as duplicate since a commenter in your previous 
issue clearly stated: "I don't think the AST module makes any guarantee about 
being able to reproduce the original source".

--
nosy: +SilentGhost, benjamin.peterson, brett.cannon, georg.brandl, ncoghlan
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> ast Str type does not annotate the string type when it parses a 
python document
type:  -> behavior

___
Python tracker 

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

[issue25891] Stray variable meth_idx in enable_symlink

[Alexander Riccio]

New submission from Alexander Riccio:

See: https://hg.python.org/cpython/file/tip/Modules/posixmodule.c#l12383

The variable int meth_idx is initialized but not used. I have no idea how it 
got there.

--
components: Windows
messages: 256553
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Stray variable meth_idx in enable_symlink
type: compile error

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

[Martin Panter]

Martin Panter added the comment:

With patch v4 many tests still fail for me. How are you running the test suite? 
Some excerpts:

  File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 
1567, in test_isoformat
self.assertEqual(t.isoformat(timespec='milliseconds'), 
"0001-02-03T04:05:01.000")
AssertionError: '0001-02-03T04:05:01.00' != '0001-02-03T04:05:01.000'

  File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 
2310, in test_isoformat
self.assertEqual(t.isoformat(), "00:00:00")
AssertionError: '00:00:00.00' != '00:00:00'

  File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 
2379, in test_str
self.assertEqual(str(self.theclass(12, 2, 3, 0)), "12:02:03")
AssertionError: '12:02:03.00' != '12:02:03'

The C module doc string I referred to is this one; I left a review comment at 
the source:

>>> print(datetime.isoformat.__doc__)
[sep] -> string in ISO 8601 format, -MM-DDTHH:MM:SS[.mm][+HH:MM].

sep is used to separate the year from the time, and defaults to 'T'.

--

___
Python tracker 

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

[issue25893] Second variable DWORD reqdSize in getpythonregpath is initialized but not used

[Alexander Riccio]

New submission from Alexander Riccio:

See: https://hg.python.org/cpython/file/tip/PC/getpathp.c#l324

The second variable named `reqdSize` in getpythonregpath is initialized but not 
used.

--
components: Windows
messages: 256555
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Second variable DWORD reqdSize in getpythonregpath is initialized but 
not used
type: compile error

___
Python tracker 

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

[issue25888] awaiting on coroutine that is being awaited should be an error

[Guido van Rossum]

Guido van Rossum added the comment:

Right.

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Guido van Rossum]

Guido van Rossum added the comment:

OK, but only for await (not for yield from).

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Yury Selivanov]

Yury Selivanov added the comment:

> OK, but only for await (not for yield from).

Sure, generators will stay untouched (I'll even add a unittest for that, if we 
don't have it).


> It should always be valid to create a new coroutine instance. Perhaps you 
> meant:

Correct, Martin, great that you've noticed that!

I'll duplicate the fixed code:

async def coroutine():
return 123
coro = coroutine()

# In Python 3.5.1:
print(await coro)   # will print 123
print(await coro)   # prints None
print(await coro)   # prints None

# What we want in Python 3.5.2
print(await coro)   # will print 123
print(await coro)   # raises RuntimeError

--

___
Python tracker 

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

[issue25890] PyObject *po in _listdir_windows_no_opendir is initialized but not used

[Alexander Riccio]

New submission from Alexander Riccio:

See: https://hg.python.org/cpython/file/tip/Modules/posixmodule.c#l3466

The variable PyObject *po in _listdir_windows_no_opendir is initialized but not 
used. Given that there's a variable named po_wchars, and two PyObject 
variables, I'm going to guess that the programmer forgot about `v`.

--
components: Windows
messages: 256549
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PyObject *po in _listdir_windows_no_opendir is initialized but not used
type: compile error

___
Python tracker 

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

[issue25890] PyObject *po in _listdir_windows_no_opendir is initialized but not used

[Alexander Riccio]

Alexander Riccio added the comment:

(in the same function, char *bufptr is ALSO unused)

--

___
Python tracker 

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

[issue25886] ast module is combining string literals that are concatenated with plus operator

[STINNER Victor]

STINNER Victor added the comment:

"The fact that ast combines strings and does not maintain the original syntax 
of the document means that original syntax information is lost and a writer 
walking the abstract syntax tree is unable to reproduce the original syntax of 
the document."

You should take a look at the RedBaron project which implements a Python 
parser, provide a high-level representation of the code *and* allow to 
regenerates the Python code without loosing the indentation, comment, or 
anything else.

https://redbaron.readthedocs.org/en/latest/

"To achieve this, [RedBaron] is based on Baron a lossless AST for Python that 
guarantees the operation
fst_to_code(code_to_fst(source_code)) == source_code."

--
nosy: +haypo

___
Python tracker 

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

[issue25886] ast module is combining string literals that are concatenated with plus operator

[Myron Walker]

Myron Walker added the comment:

My thought on this is that a syntax tree needs to accurately represent parsed 
syntax of the code.  Two strings being concatenated contain syntax information 
that is different from a single string.

  "Hello" + " World"

Is not the same syntax as:

  "Hello World"

To lose that syntax information seems to defeat the intent of abstract syntax 
tree which is to store the syntax associated with a document.

--

___
Python tracker 

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

[issue25892] PyObject *exc in encode_code_page_strict is initialized but not used

[Alexander Riccio]

New submission from Alexander Riccio:

See: https://hg.python.org/cpython/file/tip/Objects/unicodeobject.c#l7335

The variable PyObject *exc in encode_code_page_strict is initialized but not 
used.

--
components: Windows
messages: 256554
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PyObject *exc in encode_code_page_strict is initialized but not used
type: compile error

___
Python tracker 

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

[issue25886] ast module is combining string literals that are concatenated with plus operator

[R. David Murray]

R. David Murray added the comment:

By the way, if you want to talk about enhancing the AST module to be more 
useful to your use cases, the python-ideas mailing list would be the right 
place to raise the topic (you might want to look for earlier relevant 
discussions first, I'm pretty sure there have been a couple).

--

___
Python tracker 

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

[issue25885] ast Str type does not annotate the string type when it parses a python document

[Myron Walker]

Myron Walker added the comment:

I am re-opening this as I believe this is an important issue for work I would 
like to eventually push into the python core which is python code that recode 
themselves as declarations or as instance representation.

"I don't see any benefit in supporting this even if we gain comment nodes in 
the AST."

There would be a huge benefit to having accurate original syntax information of 
the document and being able to re-write the documents as it would enable self 
modifying code or software written code paradigms.

TestCases that can update themselves in various modes, full auto, 
interactive, etc.

TestData Pattern Generation object or Data Pattern Generation object that 
can be easily or efficiently modified and then asked to write themselves back 
out to files. 

The fact that there are other projects being worked on to provide round trip 
document to syntax tree and syntax tree to document transformations also 
indicates that the lack of accurate syntax storage in 'ast' is a problem that
needs to be addressed.

I would prefer to work with the core python modules in order to provide dynamic 
code modification functionality rather than relying on a third party module as 
eventually I would like to push this into core python.

If a python object has script behind it, I would like to eventually be able to 
tell a the object to write itself to a file as a object declaration or as a 
object instance.

As Declaration:

class SomeObject(SomeBase):
   def some method(self):
   print "blah blah"

As Instance:

   SomeObject()

--
status: closed -> open

___
Python tracker 

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

[issue25034] string.Formatter accepts empty fields but displays wrong when nested

[John Mark Vandenberg]

Changes by John Mark Vandenberg :


--
nosy: +jayvdb

___
Python tracker 

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

[issue25878] CPython on Windows builds with /W3, not /W4

[Alexander Riccio]

Alexander Riccio added the comment:

> The problem with this bug report is that there is little chance that it gets 
> resolved in the near term, and it's quite possible that it will stay open for 
> years. Somebody would have to sit down and start producing patches to fix 
> these warnings correctly, before the actual patch can be applied.


That's perfectly reasonable. In the mean time, we may be able to dramatically 
reduce the timetable by suppressing warnings - C4232 for example - which don't 
offer anything on a case-by-case basis.

C4232(*), for example, warns any time we use the address of a `dllimport`ed 
function. mpd_mallocfunc, mpd_free, and friends - see 
https://hg.python.org/cpython/file/tip/Modules/_decimal/libmpdec/memory.c#l44 - 
are assigned malloc, free, etc... but is it safe to ignore?



And then there are warnings that are safe to ignore in certain places, like 
C4310 in the _Py_ERROR_SURROGATEESCAPE case of PyUnicode_DecodeASCII in 
unicodeobject.c 
(https://hg.python.org/cpython/file/tip/Objects/unicodeobject.c#l6897):

if (error_handler == _Py_ERROR_REPLACE)
PyUnicode_WRITE(kind, data, writer.pos, 0xfffd);

...(here, the constant value 0xfffd is cast to a Py_UCS1, truncating it, inside 
a macro) but are not valid in others, like these insertint calls in 
PyInit_msvcrt, in msvcrtmodule.c 
(https://hg.python.org/cpython/file/tip/PC/msvcrtmodule.c#l538):

insertint(d, "CRTDBG_FILE_STDERR", (int)_CRTDBG_FILE_STDERR);
insertint(d, "CRTDBG_FILE_STDOUT", (int)_CRTDBG_FILE_STDOUT);
insertint(d, "CRTDBG_REPORT_FILE", (int)_CRTDBG_REPORT_FILE);


...(here, _CRTDBG_FILE_STDERR, _CRTDBG_FILE_STDOUT, and _CRTDBG_REPORT_FILE, 
are _HFILEs, which is a void*, here {((_HFILE)(intptr_t)-4), 
((_HFILE)(intptr_t)-5), and ((_HFILE)(intptr_t)-6)} respectively; the void* is 
truncated to an int in 64 bit builds)

(*)C4232, "nonstandard extension used : 'identifier' : address of dllimport 
'dllimport' is not static, identity not guaranteed",  
(https://msdn.microsoft.com/en-us/library/9a1sy630.aspx)

I will try to sort a few of the easy categories, so we can discuss more 
generally.

--

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

[SilentGhost]

SilentGhost added the comment:

Even that produces 3 failures on my setup, though the full list would be 
available when running: ./python -m test -v test_datetime

It is obvious, however, that the tests would fail: you've changed "if us:" to 
"if us is None:".

--

___
Python tracker 

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

[issue25886] ast module is combining string literals that are concatenated with plus operator

[Myron Walker]

New submission from Myron Walker:

ast module is combining string literals that are concatenated with plus 
operator into a single string in the parsestrplus module rather than 
maintaining the true syntax tree of the original document.

The fact that ast combines strings and does not maintain the original syntax of 
the document means that original syntax information is lost and a writer 
walking the abstract syntax tree is unable to reproduce the original syntax
of the document.

--
components: Interpreter Core
messages: 256533
nosy: Myron Walker
priority: normal
severity: normal
status: open
title: ast module is combining string literals that are concatenated with plus 
operator
versions: Python 2.7

___
Python tracker 

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

[issue21815] imaplib truncates some untagged responses

[Lita Cho]

Lita Cho added the comment:

Had some trouble setting up my dev environment for Python. Definitely going
to work on it today and tomorrow.

On Tue, Dec 8, 2015 at 12:33 PM, Maciej Szulik 
wrote:

>
> Maciej Szulik added the comment:
>
> Perfect, thanks!
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue25885] ast Str type does not annotate the string type when it parses a python document

[Myron Walker]

Myron Walker added the comment:

The purpose of a syntax tree is to represent the syntax and not a final 
processed result of processing of syntax.  The current information stored for 
strings is losing syntax information which seems to defeat the purpose of 
offering the information in a syntax tree.  I filed a separate bug because it 
is also combining strings and losing operators for string literals.

   "Hello" + " World"

>From the looks of the code, the above would result in one string type with 
>"Hello World" and syntax information associated with the operator would be 
>lost.

And as indicated, string type information is being lost as well.  The user of 
the AST then has no way of getting the lost syntax information back once it is 
lost.

--
components: +Interpreter Core -Extension Modules, Library (Lib)

___
Python tracker 

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

[issue25888] awaiting on coroutine that is being awaited should be an error

[Yury Selivanov]

New submission from Yury Selivanov:

This problem was discussed in one of the asyncio issues here: 
https://github.com/python/asyncio/issues/288

I propose to raise a RuntimeError if an 'await' expression is used for a 
coroutine object that's being awaited on already.  This change shouldn't impact 
performance in any way.  It will prevent users from writing code that behaves 
in a very weird ways (see the github link for an example).

--
assignee: yselivanov
components: Interpreter Core
messages: 256539
nosy: asvetlov, gvanrossum, haypo, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: awaiting on coroutine that is being awaited should be an error
type: enhancement
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue25885] ast Str type does not annotate the string type when it parses a python document

[R. David Murray]

R. David Murray added the comment:

Oh, that was weird.  I got a weird error message from roundup.  Must have been 
because I was posting at the same time as Brett.  I'll defer to his decision on 
this.

--
stage: test needed -> resolved

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Yury Selivanov]

New submission from Yury Selivanov:

async def foo():
return 123

print(await foo())   # will print 123
print(await foo())   # prints None
print(await foo())   # prints None


The above code illustrates the current behaviour.  I propose to change it, so 
that second 'await' will trigger a RuntimeError, explaining the the coroutine 
was awaited more than once.

This would make coroutines more predictable, and would allow users to catch 
subtle bugs in their code.

This topic was originally brought up in this thread: 
https://mail.python.org/pipermail/python-dev/2015-December/142443.html

--
assignee: yselivanov
components: Interpreter Core
messages: 256535
nosy: asvetlov, gvanrossum, haypo, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: awaiting on coroutine more than once should be an error
type: enhancement
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

[Alessandro Cucci]

Alessandro Cucci added the comment:

Uploaded a new patch (v4):
DONE:
- now all tests work (I also added one more)
- removed non ascii chars
- added milliseconds and nanoseconds as multiple of microseconds
- removed code duplication in the datetime.py
- update the docstring.

TODO:
> The doc string in the C module needs updating. 
Where? I guess "Macros to extract fields from datetime objects." in 
c-api/datetime.rst Tell me if I'm wrong

> I think timespec= option should also be added to the time.isoformat method.
I'll do it when I'm sure that the datetime.isoformat method is correct.

--
Added file: http://bugs.python.org/file41329/issue19475_v4.patch

___
Python tracker 

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

[issue25886] ast module is combining string literals that are concatenated with plus operator

[R. David Murray]

R. David Murray added the comment:

Also note that this probably mirrors the behavior of the actual compiler (I 
haven't checked).

--
nosy: +r.david.murray

___
Python tracker 

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

[issue25889] Find_BOM accepts a char*, but is passed an unsigned char*; and related usage

[Alexander Riccio]

New submission from Alexander Riccio:

This is safe, but warns on /W4. In maybe_handle_shebang, an unsigned char* is 
passed to find_BOM, which accepts a char* 
(https://hg.python.org/cpython/file/tip/PC/launcher.c#l1139).

Without an explicit cast, this generates a warning:

10>..\PC\launcher.c(1139): warning C4057: 'function': 'char *' differs in 
indirection to slightly different base types from 'unsigned char [256]'

for `bom = find_BOM(buffer);`

Similarly, assigning start to buffer generates warnings:

10>..\PC\launcher.c(1141): warning C4057: '=': 'char *' differs in indirection 
to slightly different base types from 'unsigned char *'

for `start = buffer;`


10>..\PC\launcher.c(1148): warning C4057: '=': 'char *' differs in indirection 
to slightly different base types from 'unsigned char *'
for `start = [bom->length];`

--
components: Windows
messages: 256547
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Find_BOM accepts a char*, but is passed an unsigned char*; and related 
usage
type: compile error

___
Python tracker 

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

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

[Марк Коренберг]

Марк Коренберг added the comment:

Well,  03e61104f7a2 adds good description, why not to enforce checks instead of 
saying that some values are unsupported ?

Also, idea in returning special object instance from tell(), this object should 
incapsulate byte offset. And allow for the seek() either such objects or zero.

--

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

[Alessandro Cucci]

Alessandro Cucci added the comment:

I just did that...

~/Documenti/cpython$ ./configure --with-pydebug
~/Documenti/cpython$ make -s -j2
~/Documenti/cpython$ ./python -m test -v datetimetester
...
...

--
Ran 325 tests in 1.128s

OK (skipped=1)
1 test OK.

--

___
Python tracker 

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

[issue25885] ast Str type does not annotate the string type when it parses a python document

[STINNER Victor]

STINNER Victor added the comment:

"Would adding proper storage of syntax information in the AST cause performance 
issues?"

Exactly. And storing syntax information is useless for 90% of usages of AST. So 
Python is optimized for the most common cases.

Again, use a different project (like RedBaron) if you need *all* information in 
the AST.

--

___
Python tracker 

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

[issue25885] ast Str type does not annotate the string type when it parses a python document

[Myron Walker]

Myron Walker added the comment:

Would it be prudent to add a Parse flag to the AST module that could provide 
one of two types of AST's an optimized AST or a complete AST

--

___
Python tracker 

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

[issue25894] unittest subTest failure causes result to be omitted from listing

[Zachary Ware]

New submission from Zachary Ware:

The title can barely be called accurate; the description of the problem isn't 
easy to condense to title length.  Here's the issue:

$ cat subtest_test.py 
import os
import unittest

class TestClass(unittest.TestCase):

def test_subTest(self):
for t in map(int, os.environ.get('tests', '1')):
with self.subTest(t):
if t > 1:
raise unittest.SkipTest('skipped')
self.assertTrue(t)

if __name__ == '__main__':
unittest.main()
$ ./python.exe subtest_test.py 
.
--
Ran 1 test in 0.000s

OK
$ tests=01 ./python.exe subtest_test.py 

==
FAIL: test_subTest (__main__.TestClass) ()
--
Traceback (most recent call last):
  File "subtest_test.py", line 12, in test_subTest
self.assertTrue(t)
AssertionError: 0 is not true

--
Ran 1 test in 0.001s

FAILED (failures=1)
$ tests=012 ./python.exe subtest_test.py 
s
==
FAIL: test_subTest (__main__.TestClass) ()
--
Traceback (most recent call last):
  File "subtest_test.py", line 12, in test_subTest
self.assertTrue(t)
AssertionError: 0 is not true

--
Ran 1 test in 0.001s

FAILED (failures=1, skipped=1)



Note that on the first run, the short summary is ".", as expected.  The second 
is "", when one of the subTests fails, but then the third is "s", when one 
subtest fails but another is skipped.  This also extends to verbose mode:

$ ./python.exe subtest_test.py -v
test_subTest (__main__.TestClass) ... ok

--
Ran 1 test in 0.001s

OK
$ tests=01 ./python.exe subtest_test.py -v
test_subTest (__main__.TestClass) ... 
==
FAIL: test_subTest (__main__.TestClass) ()
--
Traceback (most recent call last):
  File "subtest_test.py", line 12, in test_subTest
self.assertTrue(t)
AssertionError: 0 is not true

--
Ran 1 test in 0.001s

FAILED (failures=1)
$ tests=012 ./python.exe subtest_test.py -v
test_subTest (__main__.TestClass) ... skipped 'skipped'

==
FAIL: test_subTest (__main__.TestClass) ()
--
Traceback (most recent call last):
  File "subtest_test.py", line 12, in test_subTest
self.assertTrue(t)
AssertionError: 0 is not true

--
Ran 1 test in 0.001s

FAILED (failures=1, skipped=1)


Note the first run shows "... ok", the second "... ", and the third "... 
skipped 'skipped'"


I'm unsure what the solution should be.  There should at least be some 
indication that the test finished, but should mixed results be reported as 'm' 
("mixed results" in verbose mode), or should failure/error take precedence, or 
should every different result be represented?

--
components: Library (Lib)
messages: 256580
nosy: ezio.melotti, michael.foord, pitrou, rbcollins, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: unittest subTest failure causes result to be omitted from listing
type: behavior
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue25895] urllib.parse.urljoin does not handle WebSocket URLs

[Martin Panter]

Martin Panter added the comment:

The documentation should probably also be updated. It has a list of supported 
schemes. I imagine this would have to be taken as a new feature for 3.6+, 
rather than a bug fix.

An alternative would be to enable joining for arbitrary schemes; see Issue 
18828.

--
nosy: +martin.panter

___
Python tracker 

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

[issue25895] urllib.parse.urljoin does not handle WebSocket URLs

[Yury Selivanov]

Yury Selivanov added the comment:

Gergely, the patch looks alright. Please sign the contributor agreement and 
we'll have it merged.

--
nosy: +yselivanov

___
Python tracker 

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

[issue25895] urllib.parse.urljoin does not handle WebSocket URLs

[Gergely Imreh]

Gergely Imreh added the comment:

Just signed it, thanks!

--

___
Python tracker 

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

[issue25809] "Invalid" tests on locales

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Just commit to 3.4, merge forward, and push. I don't think there is need to 
pick up this in the final 3.4.4 release. But this can be picked up by 
maintainers of specific Linux distributions if new libc will come with the 
non-breaking space for French locale. Looks as there is a tendency to move from 
the space to the non-breaking space.

--
nosy: +larry

___
Python tracker 

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

[issue25651] Confusing output for TestCase.subTest(0)

[Zachary Ware]

Zachary Ware added the comment:

I think Ezio's suggestion of a sentinel value would be better, allowing None to 
be using as a legitimate 'message' [1].  That is, somewhere at global scope, 
define '_subtest_msg_sentinel = object()', change the msg default at 
Lib/unittest/case.py:500 to be 'msg=_subtest_msg_sentinel', and change the 
check at Lib/unittest/case.py:1400 to check 'if message is not 
_subtest_msg_sentinel'.


[1] For example:

   class TruthTest(unittest.TestCase):
   def test_truth(self):
   for o in None, 1, 0, [], (4,):
   with self.subTest(o):
   self.assertTrue(o)

Should print failure results including '[None]', '[0]', and '[[]]'.

--
nosy: +zach.ware

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Andrew Barnert]

Andrew Barnert added the comment:

@Swati Jaiswal:
> But the work around suggested here ...  is also not a general solution, i.e. 
> ... for any other mapping which does not have 0 as a key, it results in 
> KeyError.

You're missing the point. The workaround isn't intended to be a general 
solution to making mappings reversible. It's intended to produce the exact same 
behavior as the current design, for any code that somehow depends on that. So, 
any mapping that happens to be reversible by luck is reversible with the 
workaround; any mapping that successfully produces odd nonsense produces the 
same odd nonsense; any mapping that raises a KeyError(0) will raise the same 
KeyError(0).

In the incredibly vast majority of cases (probably 100%) you will not want that 
workaround; you will want the new behavior that raises a TypeError instead. I 
don't think the workaround needs to be mentioned in the documentation or 
anything; I just produced it to prove that, on the incredibly unlikely chance 
that the change is a problem for someone, the workaround to restore the old 
behavior is trivial.

Meanwhile, your general solution takes linear space, and linear up-front work, 
which makes it unacceptable for a general __reversed__ implementation. When you 
actually want, you can do it manually and explicitly in a one-liner, as already 
explained in the docs.

If you're still not getting this, pretend I never mentioned the workaround. It 
really doesn't matter.

--

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Andrew Barnert]

Andrew Barnert added the comment:

@R. David Murray:

> What is it that makes reversed raise a typeerror on dict here?

There are separate slots for tp_as_sequence and tp_as_mapping, so a C type can 
be (and generally is) one or the other, not both. 

But for Python types, anything that has __getitem__ is both a sequence and a 
mapping at the C level. (It's one of the few minor inconsistencies between C 
and Python types left, like having separate slots for nb_add and sq_concat in C 
but only __add__ for both in Python.)

> Not that we can change it at this point, but reversed blindly using len and 
> __getitem__ for user classes but not on dict is rather inconsistent.  

But it's consistent with iter blindly using __len__ and __getitem__ if __iter__ 
is not present on Python classes but not doing that on C classes. That's how 
"old-style sequences" work, and I don't think we want to get rid of those (and, 
even if we did, I'm pretty sure that would require at least a thread on -dev or 
-ideas...).

> I suppose the dict TypeError special case catches common mistakes?

Yes. That's probably not why it was implemented (it's easier for a C type to 
_not_ fake being a broken sequence than to do so), but it has that positive 
effect.

> In which case adding a __reversed__ that raises a TypeError to Mapping seems 
> to make sense for the same reason.

Exactly.

I think Raymond's point is that, while it does make sense, it may still not be 
important enough to be worth even two lines of code. Hopefully we can get more 
than two opinions (his and mine) on that question; otherwise, at least as far 
as I'm concerned, he trumps me.

--

___
Python tracker 

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

[issue25895] urllib.parse.urljoin does not handle WebSocket URLs

[Gergely Imreh]

New submission from Gergely Imreh:

Handling the "ws" and "wss" schemes of the WebSocket protocol in 
urllib.parse.urlparse was discussed in a previous issue 
http://bugs.python.org/issue13244 Parsing them seems to work correctly:

>>> urllib.parse.urlparse("wss://domain/endpoint")
ParseResult(scheme='wss', netloc='domain', path='/endpoint', params='', 
query='', fragment='')

On the other hand, urllib.parse.urljoin does not know about these schemes and 
thus cannot be used to construct WebSocket URLs (as, for example some streaming 
data APIs now seem to use it, such as 
https://starfighter.readme.io/docs/quotes-ticker-tape-websocket).

Using the example above I get:

>>> urllib.parse.urljoin("wss://domain/","/endpoint")
'/endpoint'

This is not the expected result, 'wss://example.com/endpoint', because these 
WebSocket schemes are not included in the uses_relative and uses_netloc lists 
in the library settings. For clarity, based on the previous issue's discussion 
and RFC6455 Section 11.1 https://tools.ietf.org/html/rfc6455#section-11.1 , 
these are the only two portions that apply, and should not be listed in 
uses_params.

As a workaround, similarly to the previous issue's recommendation, one can use:

>> import urlparse.parse
>> wsschemes = ["ws", "wss"]
>> urlparse.parse.uses_relative.extend(wsschemes)
>> urlparse.parse.uses_netloc.extend(wsschemes)

Attached patch to this effect. Also added tests to cover these schemes, though 
comments are definitely welcome on all of this!

--
files: 0001-urllib.parse-enable-WebSocket-URL-schemes-to-be-corr.patch
keywords: patch
messages: 256581
nosy: imrehg
priority: normal
severity: normal
status: open
title: urllib.parse.urljoin does not handle WebSocket URLs
type: behavior
versions: Python 3.4, Python 3.5
Added file: 
http://bugs.python.org/file41334/0001-urllib.parse-enable-WebSocket-URL-schemes-to-be-corr.patch

___
Python tracker 

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

[issue25809] "Invalid" tests on locales

[koobs]

koobs added the comment:

Just to note, the koobs-freebsd-current buildbot is still failing on 3.4, which 
reminded me to re-open

--

___
Python tracker 

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

[issue25878] CPython on Windows builds with /W3, not /W4

[Alexander Riccio]

Alexander Riccio added the comment:

Cut out more noisy warnings.

--
Added file: http://bugs.python.org/file41333/W4_v3.patch

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[R. David Murray]

R. David Murray added the comment:

No, the workaround was for duplicating the existing behavior if the fix 
(raising an error like a normal dict does) broken someone's code.  The *only* 
possibility here is to have a __reversed__ that raises a TypeError.

What is it that makes reversed raise a typeerror on dict here?  Not that we can 
change it at this point, but reversed blindly using len and __getitem__ for 
user classes but not on dict is rather inconsistent.  I suppose the dict 
TypeError special case catches common mistakes?  In which case adding a 
__reversed__ that raises a TypeError to Mapping seems to make sense for the 
same reason.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue25878] CPython on Windows builds with /W3, not /W4

[Zachary Ware]

Zachary Ware added the comment:

At this point our MSBuild project files are hand-crafted, and are best edited 
by hand.  You can use the GUI to get a general idea of what the changes should 
be, but it just creates far too much spam to really be usable.

This should be about a 2 line change, but the current patch is several hundred 
lines of spam.  Have a look at PCbuild/pyproject.props:41 for where the change 
should be made.

--

___
Python tracker 

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

[issue25809] "Invalid" tests on locales

[koobs]

koobs added the comment:

Re-open for 3.4 merge

--
status: closed -> open
versions: +Python 3.4

___
Python tracker 

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

[issue5501] Update multiprocessing docs re: freeze_support

[Davin Potts]

Changes by Davin Potts :


--
nosy: +rhettinger

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Swati Jaiswal]

Swati Jaiswal added the comment:

But the work around suggested here as:

def __reversed__(self):
return (self[k] for k in reversed(range(len(self

is also not a general solution, i.e. it is applicable for the following case:
m = MyDict({2:40, 0:10, 1:20})

but for any other mapping which does not have 0 as a key, it results in 
KeyError. So another solution, which would be more general could be:

def __reversed__(self):
keys = [k for k in self.keys()]
return (self[k] for k in reversed(keys))

--

___
Python tracker 

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

[issue25882] argparse help error: arguments created by add_mutually_exclusive_group() are shown outside their parent group created by add_argument_group()

[paul j3]

paul j3 added the comment:

I've attached a file that monkey patches the 
_ActionsContainer._add_container_actions method.

It corrects the `_container` attribute of the copied mutually exclusive groups. 
 I've only tested it for the case presented in this issue (and the relate 
Stackoverflow question).

I may construct of formal patch later.

--
Added file: http://bugs.python.org/file41332/issue25882.py

___
Python tracker 

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

[issue5501] Update multiprocessing docs re: freeze_support

[Davin Potts]

Davin Potts added the comment:

Thank you, Winterflower, for the nudge to see this set right.

In truth, invoking multiprocessing.freeze_support() has zero effect on 
platforms other than Windows.

This should be reflected in the 2.7 docs as well as the 3.x docs that are still 
actively being updated.

Attached are 2 patches -- they should be cleanly applied to the 2.7, 3.5, and 
default (3.6) branches.  This change clarifies the last line of existing 
documentation around freeze_support() as well as clearly states what I 
mentioned above.

--
assignee: jnoller -> davin
stage:  -> patch review
versions: +Python 3.5, Python 3.6 -Python 3.2
Added file: 
http://bugs.python.org/file41330/issue_5501_explicit_freeze_support_nonWin_v27.patch

___
Python tracker 

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

[issue5501] Update multiprocessing docs re: freeze_support

[Davin Potts]

Changes by Davin Potts :


Added file: 
http://bugs.python.org/file41331/issue_5501_explicit_freeze_support_nonWin_v3x.patch

___
Python tracker 

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

[issue25881] A little faster ElementTree serializing

[Martin Panter]

Martin Panter added the comment:

Suggested further speedup

--
nosy: +martin.panter

___
Python tracker 

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

[issue25894] unittest subTest failure causes result to be omitted from listing

[Martin Panter]

Martin Panter added the comment:

Okay, so you have a test with subtests. You have presented three cases:

1. Single subtest which passes. No problem I assume.

2. Two subtests: 1st fails, 2nd passes. This is how subtests are normally used, 
so I guess there is no problem. Is that right?

3. After two subtests have already run (one of which failed), SkipTest is 
raised. I guess you want the test results to be reported better in this case.

What is the use case? Why not skip the test before any subtests are started?

--
nosy: +martin.panter

___
Python tracker 

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

[issue24103] Use after free in xmlparser_setevents (1)

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
dependencies: +Use Py_REPLACE/Py_XREPLACE macros

___
Python tracker 

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

[issue25881] A little faster ElementTree serializing

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Proposed patch makes ElementTree serializing to xml and html formats a little 
faster. For example the write_utf8_parse_bytesIO test from lxml benchmark suite 
now is up to 5% faster, tostring_utf8 now is up to 9% faster.

Even with this patch, serializing ElementTree still is a weak link in 
comparison with lxml, it is 3-5 times slower.

--
components: Library (Lib), XML
files: etree_write.patch
keywords: patch
messages: 256517
nosy: scoder, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: A little faster ElementTree serializing
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41328/etree_write.patch

___
Python tracker 

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

[issue25880] u'..'.encode('idna') → UnicodeError: label empty or too long

[SpaceOne]

SpaceOne added the comment:

But why is the error UnicodeError instead of UnicodeEncodeError?

--
resolution: not a bug -> 
status: closed -> open

___
Python tracker 

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

[issue25880] u'..'.encode('idna') → UnicodeError: label empty or too long

[R. David Murray]

R. David Murray added the comment:

Why does it matter?  If you want to suggest changing it, you could propose a 
patch.  Maybe in reading the code you'll find out why it is the way it is now.  
I haven't looked at that code in a while myself, so I don't remember if there 
is a reason or not :)

--

___
Python tracker 

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

[issue25883] python 2.7.11 mod_wsgi regression on windows

[stephan]

stephan added the comment:

No, I didn't report this to the mod_wsgi folks.

--

___
Python tracker 

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

[issue25880] u'..'.encode('idna') → UnicodeError: label empty or too long

[R. David Murray]

R. David Murray added the comment:

The error message is accurate.  That string has empty label segments in it, 
which RFC 5890 defines as an error on encoding.  There is no such error defined 
for decoding, so that doesn't raise an error.

I don't see anything wrong with the error message, it includes the same one as 
raised in python2.  Perhaps you are confused by the error chaining introduced 
in Python3?  The second part of the traceback is coming from the encoding 
machinery, while the first part lets you know where in the encoder the error 
was raised.  In this case having both doesn't provide much additional 
information, but if one was debugging a codec or the error were coming from 
inside an application, it would.

--
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue25880] u'..'.encode('idna') → UnicodeError: label empty or too long

[R. David Murray]

Changes by R. David Murray :


--
status: open -> closed

___
Python tracker 

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

[issue25883] python 2.7.11 mod_wsgi regression on windows

[R. David Murray]

R. David Murray added the comment:

Regardless of where the bug lies, we're probably going to need the mod_wsgi 
folks to help debug it.  Have you reported it to them as well?

--
nosy: +r.david.murray

___
Python tracker 

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

[issue25883] python 2.7.11 mod_wsgi regression on windows

[stephan]

New submission from stephan:

Hi,

I use apache 32 bit on windows with mod_wsgi for my trac instance,
and other django instances which are attached by reverse-proxy.

With python (32bit) 2.7.10 it works, but as soon
as I updated to python 2.7.11 apache doesn't work anymore
(it does not respond to requests). 

I find out that the mod_wsgi.so module
causes the problem.
If I deactivate mod_wsgi (and by this my trac instance) the
other stuff works again.

In the apache error log I see the following:


[Wed Dec 16 08:56:57.130160 2015] [mpm_winnt:notice] [pid 4184:tid 664] 
AH00428: Parent: child process 6708 exited with status 1 -- Restarting.
[Wed Dec 16 08:56:57.130160 2015] [core:error] [pid 4184:tid 664] AH00546: no 
record of generation 0 of exiting child 6708
[Wed Dec 16 08:56:57.817228 2015] [ssl:warn] [pid 4184:tid 664] AH01873: Init: 
Session Cache is not configured [hint: SSLSessionCache]
[Wed Dec 16 08:56:57.817228 2015] [mpm_winnt:notice] [pid 4184:tid 664] 
AH00455: Apache/2.4.10 (Win32) mod_authn_ntlm/1.0.0 OpenSSL/1.0.1h 
mod_wsgi/4.4.9 Python/2.7.11 configured -- resuming normal operations
[Wed Dec 16 08:56:57.817228 2015] [mpm_winnt:notice] [pid 4184:tid 664] 
AH00456: Apache Lounge VC9 Server built: Jul 19 2014 13:07:40
[Wed Dec 16 08:56:57.817228 2015] [core:notice] [pid 4184:tid 664] AH00094: 
Command line: 'd:\\Programme\\Apache24\\bin\\httpd.exe -d D:/Programme/Apache24'
[Wed Dec 16 08:56:57.820229 2015] [mpm_winnt:notice] [pid 4184:tid 664] 
AH00418: Parent: Created child process 3656
[Wed Dec 16 08:56:59.035350 2015] [ssl:warn] [pid 3656:tid 676] AH01873: Init: 
Session Cache is not configured [hint: SSLSessionCache]
ImportError: No module named site
[Wed Dec 16 08:56:59.054352 2015] [mpm_winnt:notice] [pid 4184:tid 664] 
AH00428: Parent: child process 3656 exited with status 1 -- Restarting.
[Wed Dec 16 08:56:59.054352 2015] [core:error] [pid 4184:tid 664] AH00546: no 
record of generation 0 of exiting child 3656
[Wed Dec 16 08:56:59.819429 2015] [ssl:warn] [pid 4184:tid 664] AH01873: Init: 
Session Cache is not configured [hint: SSLSessionCache]
[Wed Dec 16 08:56:59.819429 2015] [mpm_winnt:notice] [pid 4184:tid 664] 
AH00455: Apache/2.4.10 (Win32) mod_authn_ntlm/1.0.0 OpenSSL/1.0.1h 
mod_wsgi/4.4.9 Python/2.7.11 configured -- resuming normal operations
[Wed Dec 16 08:56:59.819429 2015] [mpm_winnt:notice] [pid 4184:tid 664] 
AH00456: Apache Lounge VC9 Server built: Jul 19 2014 13:07:40
[Wed Dec 16 08:56:59.819429 2015] [core:notice] [pid 4184:tid 664] AH00094: 
Command line: 'd:\\Programme\\Apache24\\bin\\httpd.exe -d D:/Programme/Apache24'
[Wed Dec 16 08:56:59.821429 2015] [mpm_winnt:notice] [pid 4184:tid 664] 
AH00418: Parent: Created child process 8056
[Wed Dec 16 08:57:01.159563 2015] [ssl:warn] [pid 8056:tid 672] AH01873: Init: 
Session Cache is not configured [hint: SSLSessionCache]
ImportError: No module named site
...
...


and so on ... the error.log grows continuously even 
if do not send any request to apache,
because the process is restarted and restarted.

Now: 
 Or mod_wsgi.so (mod_wsgi-4.4.21.tar.gz) has a bug
 which didn't cause problems all the time,
 or the new python version introduced this bug.

--
components: Windows
messages: 256522
nosy: paul.moore, stephan, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: python 2.7.11 mod_wsgi regression on windows
versions: Python 2.7

___
Python tracker 

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

[issue25884] inspect.getmro() fails when base class lacks __bases__ attribute.

[Brandon Zerbe]

New submission from Brandon Zerbe:

I am using a possibly non-standard python package called Forthon, and when I 
inspect an object that is dependent on the Forthon class, I get the following 
error:

  File "/Users/zerbeb/homemade_programs/config2class/src/method_parsing.py", 
line 18, in get_all_init_args
inherited_classes = inspect.getmro(class_obj)  
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py",
 line 346, in getmro
if hasattr(cls, "__bases__"):
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py",
 line 337, in _searchbases
for base in cls.__bases__:
AttributeError: 'Forthon' object has no attribute '__bases__'

This was easy enough to fix, simply add "if not hasattr(cls,'__bases__'): 
return" to the _searchbases function:

def _searchbases(cls, accum):
# Simulate the "classic class" search order.
if cls in accum:
return
if not hasattr(cls, "__bases__"): #Additional code.
return
accum.append(cls)
for base in cls.__bases__:
_searchbases(base, accum)

Maybe you have a better solution, but I think this edge case can be trivially 
solved however you decide to edit the code.

Thanks!

--
messages: 256525
nosy: billyziege
priority: normal
severity: normal
status: open
title: inspect.getmro() fails when base class lacks __bases__ attribute.
versions: Python 2.7

___
Python tracker 

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

[issue25882] argparse help error: arguments created by add_mutually_exclusive_group() are shown outside their parent group created by add_argument_group()

[Balázs Regényi]

New submission from Balázs Regényi:

So, a parent parser is created. It has a "global arguments" group (by 
add_argument_group()) and this group has a mutually exclusive group. Then a 
child parser is created used previous parser as parent. 
The error: in the child parser help: the arguments of the mutually exclusive 
group are printed into the part of child parser instead of their "global 
arguments" group.

The next code shows the problem:

import argparse
# create parent parser
parent_parser = argparse.ArgumentParser(add_help = False)
# create group for its arguments
global_group = parent_parser.add_argument_group("global arguments")
global_group.add_argument("--global-arg1")
global_group.add_argument("--global-arg2")
mutex_group = global_group.add_mutually_exclusive_group()
mutex_group.add_argument("--mutex-arg1")
mutex_group.add_argument("--mutex-arg2")
# create child parser
child_parser = argparse.ArgumentParser(parents = [parent_parser])
child_parser.add_argument("--child-arg1")
child_parser.add_argument("--child-arg2")
print("="*100)
parent_parser.print_help()
print("="*100)
child_parser.print_help()


The output:


usage: test.py [--global-arg1 GLOBAL_ARG1] [--global-arg2 GLOBAL_ARG2]
   [--mutex-arg1 MUTEX_ARG1 | --mutex-arg2 MUTEX_ARG2]

global arguments:
  --global-arg1 GLOBAL_ARG1
  --global-arg2 GLOBAL_ARG2
  --mutex-arg1 MUTEX_ARG1
  --mutex-arg2 MUTEX_ARG2

usage: test.py [-h] [--global-arg1 GLOBAL_ARG1] [--global-arg2 GLOBAL_ARG2]
   [--mutex-arg1 MUTEX_ARG1 | --mutex-arg2 MUTEX_ARG2]
   [--child-arg1 CHILD_ARG1] [--child-arg2 CHILD_ARG2]

optional arguments:
  -h, --helpshow this help message and exit
  --mutex-arg1 MUTEX_ARG1
  --mutex-arg2 MUTEX_ARG2
  --child-arg1 CHILD_ARG1
  --child-arg2 CHILD_ARG2

global arguments:
  --global-arg1 GLOBAL_ARG1
  --global-arg2 GLOBAL_ARG2


The error is that the --mutex-arg-s can be seen in "optional arguments" part 
instead of "global arguments" part in the second (child help) case.
In the first (parent help) case the --mutex-arg-s are printed into the good 
section.

--
messages: 256518
nosy: balage
priority: normal
severity: normal
status: open
title: argparse help error: arguments created by add_mutually_exclusive_group() 
are shown outside their parent group created by add_argument_group()
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue25884] inspect.getmro() fails when base class lacks __bases__ attribute.

[R. David Murray]

R. David Murray added the comment:

Which version of python are you running?  I can't match that traceback up to 
the code in the current 2.7 inspect module.

That said, the same issue probably exists in the current code.  A 2.7 class is 
expected to have either an __mro__ or a __bases__ attribute, and if it has 
neither inspect probably *should* throw an error, since it can't know what to 
do with the class.  The error could be clearer, though.

But, let's see what others think.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue25880] u'..'.encode('idna') → UnicodeError: label empty or too long

[SpaceOne]

New submission from SpaceOne:

Python 3.4.2 (default, Oct  8 2014, 10:45:20)
>>> u'..'.encode('idna')
Traceback (most recent call last):
  File "/usr/lib/python3.4/encodings/idna.py", line 165, in encode
raise UnicodeError("label empty or too long")
UnicodeError: label empty or too long

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "", line 1, in 
UnicodeError: encoding with 'idna' codec failed (UnicodeError: label empty or 
too long)

→ I was expecting that this raises either not at all or UnicodeEncodeError.

>>> b'..'.decode('idna')
'..'
→ Why doesn't this raise then, too?

The error message is also messed up which wasn't the case in python 2.7. It 
could be cleaned up.

--
components: Unicode
messages: 256514
nosy: ezio.melotti, haypo, spaceone
priority: normal
severity: normal
status: open
title: u'..'.encode('idna') → UnicodeError: label empty or too long
versions: Python 2.7, Python 3.4

___
Python tracker 

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

[issue25874] Add notice that XP is not supported on Python 3.5+

[SilentGhost]

SilentGhost added the comment:

Hm, may be I'm seeing things, but the content of the current what's new section 
is this:

Windows XP is no longer supported by Microsoft, thus, per :PEP:`11`, CPython
 
3.5 is no longer officially supported on this OS.

The proposed patch adds two sentences on top of that:

Vista and Later versions of Windows are supported.
Please install the latest 3.4 version of CPython if you are using Windows XP.

I don't really see how that is a useful addition.

--

___
Python tracker 

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

[issue25878] CPython on Windows builds with /W3, not /W4

[Martin v . Löwis]

Martin v. Löwis added the comment:

The problem with this bug report is that there is little chance that it gets 
resolved in the near term, and it's quite possible that it will stay open for 
years. Somebody would have to sit down and start producing patches to fix these 
warnings correctly, before the actual patch can be applied.

I suggest not to add actual fixes to this issue, but instead create new issues 
that come with patches at creation, and that each fix a bunch of the warnings 
(either by warning type, or by code module). These issues could then be added 
as dependencies of this one. Otherwise, it will be difficult to track what 
precisely needs to be done on this issue.

--
nosy: +loewis

___
Python tracker 

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