date:20181008



Change by Serhiy Storchaka :


--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

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

[issue34929] Extract asyncio sendfile tests into a separate test file



Change by Andrew Svetlov :


--
resolution:  -> fixed
stage: patch review -> 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

[issue34758] http.server module sets incorrect mimetype for WebAssembly files



Change by Andrew Svetlov :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.7

___
Python tracker 

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

[issue34758] http.server module sets incorrect mimetype for WebAssembly files



Andrew Svetlov  added the comment:


New changeset 199a280af540e3194405eb250ca1a8d487f6a4f7 by Andrew Svetlov 
(travisoneill) in branch 'master':
bpo-34758: add .wasm to recognized file extensions in mimetypes module (GH-9464)
https://github.com/python/cpython/commit/199a280af540e3194405eb250ca1a8d487f6a4f7


--
nosy: +asvetlov

___
Python tracker 

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

[issue34751] Hash collisions for tuples

2018-10-08 Thread Tim Peters



Tim Peters  added the comment:

We need to worry about timing too :-(  I'm using this as a test.  It's very 
heavy on using 3-tuples of little ints as dict keys.  Getting hash codes for 
ints is relatively cheap, and there's not much else going on, so this is 
intended to be very sensitive to changes in the speed of tuple hashing:

def doit():
from time import perf_counter as now
from itertools import product

s = now()
d = dict.fromkeys(product(range(150), repeat=3), 0)
for k in d:
 d[k] += 1
for k in d:
 d[k] *= 2
f = now()
return f - s

I run that five times in a loop on a mostly quiet box, and pick the smallest 
time as "the result".

Compared to current master, a 64-bit release build under Visual Studio takes 
20.7% longer.  Ouch!  That's a real hit.

Fiddling the code a bit (see the PR) to convince Visual Studio to emit a rotate 
instruction instead of some shifts and an add reduces that to 19.3% longer.  A 
little better.

The variant I discussed last time (add in the length at the start, and get rid 
of all the post-loop avalanche code) reduces it to 8.88% longer.  The avalanche 
code is fixed overhead independent of tuple length, so losing it is more 
valuable (for relative speed) the shorter the tuple.

I can't speed it more.  These high-quality hashes have unforgiving long 
critical paths, and every operation appears crucial to their good results in 
_some_ test we already have.  But "long" is relative to our current tuple hash, 
which does relatively little to scramble bits, and never "propagates right" at 
all.  In its loop, it does one multiply nothing waits on, and increments the 
multplier for the next iteration while the multiply is going on.

Note:  "the real" xxHash runs 4 independent streams, but it only has to read 8 
bytes to get the next value to fold in.  That can go on - in a single thread - 
while other streams are doing arithmetic (ILP).  We pretty much have to "stop 
the world" to call PyObject_Hash() instead.

We could call that 4 times in a row and _then_ start arithmetic.  But most 
tuples that get hashed are probably less than 4 long, and the code to mix 
stream results together at the end is another bottleneck.  My first stab at 
trying to split it into 2 streams ran substantially slower on realistic-length 
(i.e., small) tuples - so that was also my last stab ;-)

I can live with the variant.  When I realized we never "propagate right" now, I 
agreed with Jeroen that the tuple hash is fundamentally "broken", despite that 
people hadn't reported it as such yet, and despite that that flaw had 
approximately nothing to do with the issue this bug report was opened about.  
Switching to "a real" hash will avoid a universe of bad cases, and xxHash 
appears to be as cheap as a hash without glaringly obvious weaknesses gets:  
two multiplies, an add, and a rotate.

--

___
Python tracker 

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

[issue34940] Possible assertion failure due to _check_for_legacy_statements()

2018-10-08 Thread Zackery Spytz



Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +9151
stage:  -> patch review

___
Python tracker 

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

[issue34940] Possible assertion failure due to _check_for_legacy_statements()

2018-10-08 Thread Zackery Spytz



New submission from Zackery Spytz :

The PyUnicode_Tailmatch() and PyUnicode_FromString() calls in 
_check_for_legacy_statements() are not properly checked for failure.

--
components: Interpreter Core
messages: 327379
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Possible assertion failure due to _check_for_legacy_statements()
type: crash
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue34899] Possible assertion failure due to int_from_bytes_impl()

2018-10-08 Thread Zackery Spytz



Change by Zackery Spytz :


--
resolution:  -> fixed
stage: patch review -> 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

[issue34939] Possibly spurious SyntaxError: annotated name can't be global

2018-10-08 Thread Rohan Padhye



New submission from Rohan Padhye :

The following code when run as a script file gives syntax error:

```
def set_x():
global x
x = 1

x:int = 0   # SyntaxError: annotated name 'x' can't be global
```

PEP 526 does not seem to forbid this. The error message "annotated name [...] 
can't be global" is usually seen when using the `global x` declaration *in the 
same scope* as an annotated assignment. In the above case, the annotated 
assignment is outside the function scope, yet Python 3.7 gives a syntax error.


Is this a bug in CPython? Or should the PEP 526 document say something about 
forward references?

Interestingly, if the above program is run in interactive mode, there is no 
syntax error. 

In interactive mode:
```
>>> def set_x():
... global x
... x = 1
... 
>>> x:int = 0
>>> set_x()
>>> print(x)
1
```

Further, forward references work fine with `nonlocal`. For example, the 
following works fine both as a script file and in interactive mode:
```
def outer():
def inner():
nonlocal y
y = 1
y:int = 0
```

I don't see why a forward reference in `global` is a problem.

--
components: Interpreter Core
messages: 327378
nosy: rohanpadhye
priority: normal
severity: normal
status: open
title: Possibly spurious SyntaxError: annotated name can't be global
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue34926] Adding "mime_type" method to pathlib.Path

2018-10-08 Thread Raymond Hettinger



Raymond Hettinger  added the comment:

-0 There is some value in having a separation of responsibilities and in not 
adding another dependency.  On the other hand, I can see how this would 
sometimes be convenient.

Assigning to Antoine to make the decision.

--
assignee:  -> pitrou
nosy: +pitrou, rhettinger

___
Python tracker 

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

[issue9694] argparse required arguments displayed under "optional arguments"

2018-10-08 Thread Jack


Jack  added the comment:

I'd like to note that this also happens with a required mutually exclusive 
group:

group = parser.add_mutually_exclusive_group(required=True)

The arguments in the group are listed under “optional arguments:”.

I'm guessing the mechanism is the same.

--
nosy: +Jacktose

___
Python tracker 

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

[issue32174] nonASCII punctuation characters can not display in python363.chm.



Change by Steve Dower :


--
resolution:  -> fixed
stage: patch review -> 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

[issue34926] Adding "mime_type" method to pathlib.Path

2018-10-08 Thread YoSTEALTH



Change by YoSTEALTH :


--
components:  -Extension Modules

___
Python tracker 

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

[issue12345] Add math.tau

2018-10-08 Thread Danish Prakash



Change by Danish Prakash :


--
pull_requests: +9150

___
Python tracker 

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Chris Angelico

On Tue, Oct 9, 2018 at 9:06 AM Marko Rauhamaa  wrote:
>
> Thomas Jollans :
>
> > On 08/10/2018 08:31, Marko Rauhamaa wrote:
> >> Where I work (and at home), the only control character that is allowed
> >> in source code is LF.
> >
> > No tolerance for form feeds?
>
> None whatsoever.
>
> CR is ok but only if immediately followed by BEL. That way typing source
> code gives out the air of an old typewriter.
>
> Highlighting keywords with ANSI escape sequences can also be rather
> cute.
>

Bah, you're missing out on so much fun by banning control characters.
Inserting a "cursor up one line" character in the middle of a quoted
string makes typing source code ever so much more exciting! Especially
if you carefully engineer it so it gently changes a few variable
names...

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34938] Fix mimetype.init() to account for from import

2018-10-08 Thread YoSTEALTH



New submission from YoSTEALTH :

When a user uses from import, there is a flaw in how mimetype.init() updates 
its global references.

# Option-1 (flawed)
# -
from mimetypes import init, types_map

print(types_map.get('.gz'))  # None
init()  # <- initialize
print(types_map.get('.gz'))  # None

# Option-2
# 
import mimetypes

print(mimetypes.types_map.get('.gz'))  # None
mimetypes.init()  # <- initialize
print(mimetypes.types_map.get('.gz'))  # application/gzip

As you can see in 
https://github.com/python/cpython/blob/master/Lib/mimetypes.py#L344 line:358 
global reference is reassigned and thus it prevents `from mimetype import 
types_map` from being updated and using old `types_map` reference.

Potential solution would be to `types_map.update(new dict content)` vs 
reassigning the variable.

--
messages: 327375
nosy: YoSTEALTH
priority: normal
severity: normal
status: open
title: Fix mimetype.init() to account for from import
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Marko Rauhamaa

Thomas Jollans :

> On 08/10/2018 08:31, Marko Rauhamaa wrote:
>> Where I work (and at home), the only control character that is allowed
>> in source code is LF.
>
> No tolerance for form feeds?

None whatsoever.

CR is ok but only if immediately followed by BEL. That way typing source
code gives out the air of an old typewriter.

Highlighting keywords with ANSI escape sequences can also be rather
cute.

Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32174] nonASCII punctuation characters can not display in python363.chm.



miss-islington  added the comment:


New changeset c4c86fad8024dc91af8d785c33187c092b4e49d9 by Miss Islington (bot) 
in branch '3.7':
bpo-32174: Let .chm document display non-ASCII characters properly (GH-9758)
https://github.com/python/cpython/commit/c4c86fad8024dc91af8d785c33187c092b4e49d9


--

___
Python tracker 

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

[issue32174] nonASCII punctuation characters can not display in python363.chm.



miss-islington  added the comment:


New changeset 64bcedce8d61e1daa9ff7980cc07988574049b1f by Miss Islington (bot) 
in branch '3.6':
bpo-32174: Let .chm document display non-ASCII characters properly (GH-9758)
https://github.com/python/cpython/commit/64bcedce8d61e1daa9ff7980cc07988574049b1f


--
nosy: +miss-islington

___
Python tracker 

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

[issue32174] nonASCII punctuation characters can not display in python363.chm.



Steve Dower  added the comment:

Thanks, that looks perfect!

--

___
Python tracker 

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

[issue32174] nonASCII punctuation characters can not display in python363.chm.



Change by miss-islington :


--
pull_requests: +9149

___
Python tracker 

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

[issue32174] nonASCII punctuation characters can not display in python363.chm.



Change by miss-islington :


--
pull_requests: +9148

___
Python tracker 

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

[issue32174] nonASCII punctuation characters can not display in python363.chm.



Steve Dower  added the comment:


New changeset 6261ae9b01fb8429b779169f8de37ff567c144e8 by Steve Dower 
(animalize) in branch 'master':
bpo-32174: Let .chm document display non-ASCII characters properly (GH-9758)
https://github.com/python/cpython/commit/6261ae9b01fb8429b779169f8de37ff567c144e8


--

___
Python tracker 

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

Re: How to use Python's built-in Logging with Asyncio (Permission Error)

2018-10-08 Thread Ian Kelly

I'm spit-balling here, but I suspect the problem is that
TimedRotatingFileHandler was probably not designed to have multiple
instances of it in different processes all trying to rotate the same
file. Yet that's the situation you have since each subprocess in your
process pool creates its own handler instance.

I've not used it myself, but I believe that this is effectively the
problem that QueueHandler and QueueListener were created to solve:
https://docs.python.org/3.7/library/logging.handlers.html#queuehandler

The parent process should create a queue and a QueueListener to
service that queue, using the TimedRotatingFileHandler. Each
subprocess should log to the queue using QueueHandler instead. This
way the actual log file is only handled by one process.
On Mon, Oct 8, 2018 at 1:54 PM  wrote:
>
> From the logging docs I found out there was another avenue (comp.lang.python) 
> to ask questions about it. I already posted to stackoverflow but if anyone 
> could help out here or via stackoverflow I would greatly appreciate it. Here 
> is the link to my question:
>
> https://stackoverflow.com/questions/52708756/how-to-use-pythons-built-in-logging-with-asyncio-permission-error
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

2018-10-08 Thread Thomas Jollans


On 08/10/2018 08:31, Marko Rauhamaa wrote:

Chris Angelico :

How wide my indents are on my screen shouldn't influence your screen
or your choices.


Where I work (and at home), the only control character that is allowed
in source code is LF.



No tolerance for form feeds?

--
https://mail.python.org/mailman/listinfo/python-list

[issue23831] tkinter canvas lacks of moveto method.

2018-10-08 Thread Juliette Monsel



Change by Juliette Monsel :


--
nosy: +j-4321-i

___
Python tracker 

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

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

2018-10-08 Thread Mario

Mario  added the comment:

On 08/10/2018 17:54, Steve Dower wrote:
> 
> Steve Dower  added the comment:
> 
>> Py_SetProgramName() should be a relative or absolute path that can be used 
>> to set sys.executable and other values appropriately.
> 
> Key point here is *can be*, but it doesn't have to be. Given it has fallbacks 
> all the way to "python"/"python3", we can't realistically use it as 
> sys.executable just because it has a value.
> 
> And right now, it's used to locate the current executable (which is 
> unnecessary on Windows), which is then assumed to be correct for 
> sys.executable. Most embedding cases require *this* assumption to be 
> overridden, not the previous assumption.

I still would like my use case to be acknowledged.

site.py uses the value of sys.executable to set up a virtual environment, which 
is a very valuable 
thing even in an embedded cases.

This constraint is strong enough to force it to point to python.exe or python3 
as it would normally 
do in a scripted (non embedded case).

I still believe the 2 concepts should be decoupled to avoid them clashing and 
having supporters of 
one disagreeing with supporters of the other.

Andrea

--

___
Python tracker 

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Grant Edwards

On 2018-10-08, Peter J. Holzer  wrote:

> Theoretically I would agree with you: Just use a single tab per
> indentation level and let the user decide whether that's displayed
> as 2, 3, 4, or 8 spaces or 57 pixels or whatever.
>
> In practice it doesn't work in my experience.

Nor in mine.  On problem is that under Unix is that there isn't just
one place where you would need to configure the tab width.  There are
dozens of text-processing tools that get used on all sorts of text,
including program sources in a variety of languages.

For "just use tabs" to work, all of those tools would have to
magically recognize that they're looking at Python source and adjust
the tab size accordingly.  That isn't going to happen.

> There is always someone in a team who was "just testing that new
> editor" and replaced all tabs with spaces (or vice versa) or - worse
> - just some of them. It is safer to disallow tabs completely and
> mandate a certain number of spaces per indentation level.

Indeed. That's the only thing that actually works.

-- 
Grant Edwards   grant.b.edwardsYow! Being a BALD HERO
  at   is almost as FESTIVE as a
  gmail.comTATTOOED KNOCKWURST.

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34937] Extract asyncio tests for sock_*() methods into a separate test file



Change by Andrew Svetlov :


--
resolution:  -> fixed
stage: patch review -> 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

[issue31715] Add mimetype for extension .mjs



Change by Andrew Svetlov :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

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

[issue31715] Add mimetype for extension .mjs



Andrew Svetlov  added the comment:


New changeset 0854b92cd25613269d21de3cb5239379ddc0f2fb by Andrew Svetlov 
(Bradley Meck) in branch 'master':
bpo-31715 Add mimetype for extension .mjs (#3908)
https://github.com/python/cpython/commit/0854b92cd25613269d21de3cb5239379ddc0f2fb


--
nosy: +asvetlov

___
Python tracker 

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

How to use Python's built-in Logging with Asyncio (Permission Error)

2018-10-08 Thread liamhanninen

>From the logging docs I found out there was another avenue (comp.lang.python) 
>to ask questions about it. I already posted to stackoverflow but if anyone 
>could help out here or via stackoverflow I would greatly appreciate it. Here 
>is the link to my question:

https://stackoverflow.com/questions/52708756/how-to-use-pythons-built-in-logging-with-asyncio-permission-error
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Observations on the List - "Be More Kind"

2018-10-08 Thread Ethan Furman


On 10/08/2018 07:43 AM, Rhodri James wrote:

I appreciate that the moderators are volunteers, but they have official 
power on this list.  Being volunteers doesn't mean that they can't get 
it wrong, or that we shouldn't call them on it when they do.


I completely agree.


They have got things wrong,


I completely disagree.


and I have called them on it.


Yes, you and a few others -- and nobody has actually talked (emailed) us 
directly, but rather talked *about* us on the list [1].


The response has 
been... I'm trying not to say "patronising" because I'm fairly sure it 
wasn't meant that way, but "I'm sorry you feel that way" made me feel 
patronised.


You're right, I didn't mean it that way, and I apologize.

To briefly explain our decisions of late:

Suspending D'Aprano:
---
His public post to me was shared with several people, including 
moderators of others lists, and it was unanimously agreed that his post 
was completely unacceptable and a two month suspension was appropriate. 
I restarted that suspension because, according to his own words, "I am 
ignoring the ban in this instance"; had he emailed me privately I would 
have correctly posted the notice to the list; had he not said that and 
just posted I would have fixed the filter and left the suspension alone 
(he posts from comp.lang.python).


Suspending Mark Lawrence:

He has a history of posting attacks.  I sent him a private warning, he 
responded a couple days later with another attack.


Suspending BartC:

Many, if not most, of his posts' primary relation to Python was how his 
personal language was better.  The resulting threads seemed to be 
largely unfriendly, unproductive, and unnecessary.


Banning Rick Johnson:

Hopefully no explanation needed [2].

Shutting down threads:
-
There is a problem with threads getting heated and people not exercising 
self-control and posting inappropriately.  That makes the list 
unwelcoming.  As soon as we feel that that is happening we are going to 
shut down the thread.  Personal attacks and name-calling are not 
appropriate and will not be tolerated.  The goal is not to shut down 
debate -- as long as the debate stays civil it will get no moderation 
action.  If a thread is shut down and you feel there is more to be 
(civilly) said -- wait a couple days so everyone can cool off, and then 
start a new thread.


Hopefully you now agree with our decisions, or at least support us in 
them.  If you don't, I actually am sorry -- I would much rather have 
your support (and everyone's).  Either way, we are not changing our 
minds about them.


--
~Ethan~
Python List Moderator



[1] Please correct me if I'm wrong.

[2] If one is needed: his posts can contain profanity, personal attacks, 
condescension, and completely inappropriate language.

--
https://mail.python.org/mailman/listinfo/python-list

Encounter issues to install Python

2018-10-08 Thread Olivier Oussou via Python-list

Hi!I downloaded and installed python 3.6.4 (32-bit) on my computer but I have 
problems and can not access the python interface.
I need your technical assistance to solve this matter. 

Best regard!

Olivier OUSSOUMedical entomologist, Benin
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34937] Extract asyncio tests for sock_*() methods into a separate test file



Change by Andrew Svetlov :


--
keywords: +patch
pull_requests: +9147
stage:  -> patch review

___
Python tracker 

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

[issue34936] tkinter.Spinbox.selection_element() raises TclError

2018-10-08 Thread Juliette Monsel



Change by Juliette Monsel :


--
keywords: +patch
pull_requests: +9146
stage: needs patch -> patch review

___
Python tracker 

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

[issue34937] Extract asyncio tests for sock_*() methods into a separate test file



Change by Andrew Svetlov :


--
components: Tests, asyncio
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Extract asyncio tests for sock_*() methods into a separate test file
versions: Python 3.8

___
Python tracker 

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

[issue34921] NoReturn not allowed by get_type_hints when future import annotations is used

2018-10-08 Thread Ivan Levkivskyi



Change by Ivan Levkivskyi :


--
resolution:  -> fixed
stage: patch review -> 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

[issue34921] NoReturn not allowed by get_type_hints when future import annotations is used

2018-10-08 Thread Ivan Levkivskyi



Ivan Levkivskyi  added the comment:


New changeset 5eea0ad50c32d38909ff4e29309e2cc3c6ccb2c0 by Ivan Levkivskyi (Noah 
Wood) in branch 'master':
bpo-34921: Allow escaped NoReturn in get_type_hints (GH-9750)
https://github.com/python/cpython/commit/5eea0ad50c32d38909ff4e29309e2cc3c6ccb2c0


--
nosy: +levkivskyi

___
Python tracker 

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

[issue34911] Allow Cookies for Secure WebSockets



Change by Andrew Svetlov :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

___
Python tracker 

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

[issue34911] Allow Cookies for Secure WebSockets



Andrew Svetlov  added the comment:


New changeset 4c339970570d07916bee6ade51f4e9781d51627a by Andrew Svetlov (Paul 
Bailey) in branch 'master':
bpo-34911: Added support for secure websocket cookies (GH-9734)
https://github.com/python/cpython/commit/4c339970570d07916bee6ade51f4e9781d51627a


--
nosy: +asvetlov

___
Python tracker 

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

Re: Observations on the List - "Be More Kind"

2018-10-08 Thread Rhodri James


On 05/10/18 11:22, Bruce Coram wrote:
The level of vitriol and personal attacks on the moderators was 
profoundly disappointing, but not totally out of character for those who 
made the attacks.  There is no doubt that these people know software and 
Python and this certainly earns my respect,  but perhaps they need to 
retain a sense of perspective.  There are 7 billion people in the 
world.  There are plenty more people at least as good as you and many 
better, but they don't have the compelling urge to demonstrate their 
genius.  They get on with their work in a quiet professional manner.


Speaking as one of the people who have been vocally unimpressed with the 
moderators of late, I'd personally appreciate something a little more 
specific than "not totally out of character".  Because actually it *is* 
out of character for me to be confrontational.


I appreciate that the moderators are volunteers, but they have official 
power on this list.  Being volunteers doesn't mean that they can't get 
it wrong, or that we shouldn't call them on it when they do.  They have 
got things wrong, and I have called them on it.  The response has 
been... I'm trying not to say "patronising" because I'm fairly sure it 
wasn't meant that way, but "I'm sorry you feel that way" made me feel 
patronised.  It certainly didn't (and doesn't) make me feel that my 
outright anger at their actions has been considered with any degree of 
seriousness.  Unsurprisingly that doesn't lead to me taking them 
seriously any more.  The formal language only makes me take them less 
seriously.


I don't know what else to say to you.  With one or maybe two exceptions, 
I haven't seen anything that is even close to qualifying as vitriol. 
Much of what has been said could be cast as personal attacks, but that 
is true of almost any confrontation, especially where abuse of power is 
or may be involved.  (Oh, and posting a thumbnail character 
assassination of someone who isn't allowed to post in their defense is 
hardly blameless behaviour, by the way.)  Flatly, I do not see what you 
see.  I'm open to persuasion, but I'll say up front I don't expect you 
to succeed.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

2018-10-08 Thread Marko Rauhamaa

Chris Angelico :
> How wide my indents are on my screen shouldn't influence your screen
> or your choices.

Where I work (and at home), the only control character that is allowed
in source code is LF.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

2018-10-08 Thread Chris Angelico

On Tue, Oct 9, 2018 at 4:44 AM Peter J. Holzer  wrote:
>
> On 2018-10-08 10:36:21 +1100, Chris Angelico wrote:
> > TBH, I think that tab width should be up to the display, just like the
> > font. You're allowed to view code in any font that makes sense for
> > you, and you should be able to view code with any indentation that
> > makes sense for you. If someone submits code and says "it looks
> > tidiest in Times New Roman 12/10pt", I'm sure you'd recommend making
> > sure it doesn't matter [1]; if someone submits code and says "you have
> > to set your tabs equal to 5 spaces or it looks ugly", you'd say the
> > same, right?
> >
> > How wide my indents are on my screen shouldn't influence your screen
> > or your choices.
>
> Theoretically I would agree with you: Just use a single tab per
> indentation level and let the user decide whether that's displayed as 2,
> 3, 4, or 8 spaces or 57 pixels or whatever.
>
> In practice it doesn't work in my experience. There is always someone in
> a team who was "just testing that new editor" and replaced all tabs
> with spaces (or vice versa) or - worse - just some of them. It is safer
> to disallow tabs completely and mandate a certain number of spaces per
> indentation level.
>

Ahh yes, it hurts to stick your neck out and have someone hack at it... :|

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files

2018-10-08 Thread Tal Einat



Tal Einat  added the comment:

Can someone clarify whether Modules/overlapped.c should be converted to use AC?

--

___
Python tracker 

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Peter J. Holzer

On 2018-10-08 10:36:21 +1100, Chris Angelico wrote:
> TBH, I think that tab width should be up to the display, just like the
> font. You're allowed to view code in any font that makes sense for
> you, and you should be able to view code with any indentation that
> makes sense for you. If someone submits code and says "it looks
> tidiest in Times New Roman 12/10pt", I'm sure you'd recommend making
> sure it doesn't matter [1]; if someone submits code and says "you have
> to set your tabs equal to 5 spaces or it looks ugly", you'd say the
> same, right?
> 
> How wide my indents are on my screen shouldn't influence your screen
> or your choices.

Theoretically I would agree with you: Just use a single tab per
indentation level and let the user decide whether that's displayed as 2,
3, 4, or 8 spaces or 57 pixels or whatever. 

In practice it doesn't work in my experience. There is always someone in
a team who was "just testing that new editor" and replaced all tabs
with spaces (or vice versa) or - worse - just some of them. It is safer
to disallow tabs completely and mandate a certain number of spaces per
indentation level.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue15994] memoryview to freed memory can cause segfault

2018-10-08 Thread JP Sugarbroad



Change by JP Sugarbroad :


--
nosy: +taralx

___
Python tracker 

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

Re: Python indentation (correct behaviour) (was: Python indentation (3 spaces))

2018-10-08 Thread Peter J. Holzer

On 2018-10-08 18:06:51 +1100, Ben Finney wrote:
> Cameron Simpson  writes:
> > What I do wish was that I had a vim mode that highlighted an indent
> > column so I can line up indented code with its controlling top line.
> 
> For Vim: https://github.com/nathanaelkane/vim-indent-guides>.

Nice.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34936] tkinter.Spinbox.selection_element() raises TclError



Serhiy Storchaka  added the comment:

Do you mind to create a PR against master for fixing this issue Juliette?

--

___
Python tracker 

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

[issue34936] tkinter.Spinbox.selection_element() raises TclError



Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 2.7, Python 3.6, Python 3.8

___
Python tracker 

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

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows



Steve Dower  added the comment:

> Py_SetProgramName() should be a relative or absolute path that can be used to 
> set sys.executable and other values appropriately.

Key point here is *can be*, but it doesn't have to be. Given it has fallbacks 
all the way to "python"/"python3", we can't realistically use it as 
sys.executable just because it has a value.

And right now, it's used to locate the current executable (which is unnecessary 
on Windows), which is then assumed to be correct for sys.executable. Most 
embedding cases require *this* assumption to be overridden, not the previous 
assumption.

--

___
Python tracker 

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

[issue34445] asyncio support in doctests



Change by Andrew Svetlov :


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

[issue34383] asyncio passes SSL certificate error to loop.call_exception_handler()



Andrew Svetlov  added the comment:

Duplicate of #34630

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

[issue34630] Don't log ssl cert errors in asyncio



Change by Andrew Svetlov :


--
resolution:  -> fixed
stage: patch review -> 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

[issue34630] Don't log ssl cert errors in asyncio



Change by Andrew Svetlov :


--
assignee:  -> asvetlov
components: +asyncio
nosy: +yselivanov
versions: +Python 3.8

___
Python tracker 

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

[issue34935] Misleading error message in str.decode()

2018-10-08 Thread Walter Dörwald


Walter Dörwald  added the comment:

OK, I see, http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf (Table 3-7 on 
page 93) states that the only valid 3-bytes UTF-8 sequences starting with the 
byte 0xED have a value for the second byte in the range 0x80 to 0x9F. 0xA0 is 
just beyond that range (as that would result in an encoded surrogate). Python 
handles all invalid sequences according to that table with the same error 
message. I think this issue can be closed.

--

___
Python tracker 

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

[issue34880] About the "assert" bytecode



Serhiy Storchaka  added the comment:

This can't be changed in 3.6. There are two ways of changing it:

1. Make the marshal module supporting AssertionError as it supports booleans, 
None, Ellipsis and StopIteration. This will require adding the new marshal 
format version.

2. Add a new opcode in bytecode.

The latter way is easier. Bytecode is changed in every feature release, and it 
was already changed in 3.8. New marshal versions are added less often.

There was similar issue with StopAsyncIteration. See issue33041.

--
nosy: +serhiy.storchaka
versions: +Python 3.8 -Python 3.6

___
Python tracker 

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

[issue34829] Add missing selection_ methods to tkinter Spinbox



Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> 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

[issue34829] Add missing selection_ methods to tkinter Spinbox



Serhiy Storchaka  added the comment:


New changeset af5658ae93b0a87ab4420a7dc30a07fa5a83e252 by Serhiy Storchaka 
(Juliette Monsel) in branch 'master':
bpo-34829: Add missing selection_ methods to the Tkinter Spinbox. (GH-9617)
https://github.com/python/cpython/commit/af5658ae93b0a87ab4420a7dc30a07fa5a83e252


--

___
Python tracker 

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

[issue34936] tkinter.Spinbox.selection_element() raises TclError

2018-10-08 Thread Juliette Monsel



New submission from Juliette Monsel :

Spinbox.selection_element() raises `TclError: expected integer but got "none"` 
while it should return the currently selected element according to the 
docstring.

I think this issue comes from the Spinbox.selection method which tries to 
convert to int the output of self.tk.call((self._w, 'selection', 'element')) 
while it returns a string ("none", "buttonup" or "buttondown").

--
components: Tkinter
messages: 327359
nosy: j-4321-i
priority: normal
severity: normal
status: open
title: tkinter.Spinbox.selection_element() raises TclError
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue34935] Misleading error message in str.decode()



Serhiy Storchaka  added the comment:

This behavior is intentional, for conformance with the Unicode Standard
recommendations. See issue8271.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue34935] Misleading error message in str.decode()

2018-10-08 Thread Walter Dörwald


New submission from Walter Dörwald :

The following code issues a misleading exception message:

>>> b'\xed\xa0\xbd\xed\xb3\x9e'.decode("utf-8")
Traceback (most recent call last):
  File "", line 1, in 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 0: invalid 
continuation byte

The cause for the exception is *not* an invalid continuation byte, but UTF-8 
encoded surrogates. In fact using the 'surrogatepass' error handler doesn't 
raise an exception:

>>> b'\xed\xa0\xbd\xed\xb3\x9e'.decode("utf-8", "surrogatepass")
'\ud83d\udcde'

I would have expected an exception message like:

UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 0-2: 
surrogates not allowed

(Note that the input bytes are an improperly UTF-8 encoded version of U+1F4DE 
(telephone receiver))

--
components: Unicode
messages: 327357
nosy: doerwalter, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Misleading error message in str.decode()
versions: Python 3.7

___
Python tracker 

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

[issue33014] Clarify str.isidentifier docstring; fix keyword.iskeyword docstring

2018-10-08 Thread Sanyam Khurana



Sanyam Khurana  added the comment:

Marking this fixed via 
https://github.com/python/cpython/commit/ffc5a14d00db984c8e72c7b67da8a493e17e2c14
 and 
https://github.com/python/cpython/commit/fc8205cb4b87edd1c19e1bcc26deaa1570f87988

Thanks, everyone!

--
resolution:  -> fixed
stage: patch review -> 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

[issue34903] strptime %d handling of single digit day of month

2018-10-08 Thread Paul Ganssle



Change by Paul Ganssle :


--
nosy: +p-ganssle

___
Python tracker 

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

[issue34925] 25% speed-up to common case for bisect()

2018-10-08 Thread Raymond Hettinger



Raymond Hettinger  added the comment:


New changeset de2e448414530689f2e60e84fd78bdfebb772898 by Raymond Hettinger in 
branch 'master':
bpo-34925: Optimize common case for bisect() argument parsing (#9753)
https://github.com/python/cpython/commit/de2e448414530689f2e60e84fd78bdfebb772898


--

___
Python tracker 

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

[issue34925] 25% speed-up to common case for bisect()

2018-10-08 Thread Raymond Hettinger



Change by Raymond Hettinger :


--
resolution:  -> fixed
stage: patch review -> 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

[issue13407] tarfile doesn't support multistream bzipped tar files

2018-10-08 Thread Brian Curtin



Change by Brian Curtin :


--
assignee: docs@python -> brian.curtin
resolution:  -> fixed
stage: patch review -> 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

Re: kivy [quick report]

2018-10-08 Thread m

W dniu 05.10.2018 o 18:43, Stefan Ram pisze:
>   BTW: For Android, there is a "Bulldozer" (or some such) that
>   can create an APK. I wonder what the best way to package one's
>   kivy program to distribute it to Windows users?

I use wine + pyinstaller.

regards

m
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34934] Consider making Windows select.select interruptible using WSAEventSelect & WSAWaitForMultipleEvents

2018-10-08 Thread ondrej.kutal



Change by ondrej.kutal :


--
title: Consider making Windows select.select interruptable using WSAEventSelect 
& WSAWaitForMultipleEvents -> Consider making Windows select.select 
interruptible using WSAEventSelect & WSAWaitForMultipleEvents

___
Python tracker 

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

[issue34934] Consider making Windows select.select interruptable using WSAEventSelect & WSAWaitForMultipleEvents

2018-10-08 Thread Ondra Kutal



New submission from Ondra Kutal :

At the moment, socket select.select() function is not interruptable on Windows 
OS (in main thread). Following code cannot be interrupted (for example by 
CTRL+C):

import select, socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setblocking(False)
s.bind(('0.0.0.0', ))
s.listen(100)

select.select([s], [], [], None)
s.close()

However this can be achieved by replacing select() calls with use of Windows 
native APIs WSAEventSelect and WSAWaitForMultipleEvents (see for example 
https://stackoverflow.com/questions/10353017). I have tried a quick prototype 
in selectmodule.c, replacing

Py_BEGIN_ALLOW_THREADS
errno = 0;
n = select(max, , , , tvp);
Py_END_ALLOW_THREADS

with 

#ifndef MS_WINDOWS
Py_BEGIN_ALLOW_THREADS
errno = 0;
n = select(max, , , , tvp);
Py_END_ALLOW_THREADS
#else

if (!_PyOS_IsMainThread()) {
Py_BEGIN_ALLOW_THREADS
errno = 0;
n = select(max, , , , tvp);
Py_END_ALLOW_THREADS
}
else
{
// quick prototype, only for read sockets
WSAEVENT events[50];
for (u_int i = 0; i < ifdset.fd_count; ++i)
{
events[i+1] = WSACreateEvent();
WSAEventSelect(ifdset.fd_array[i], events[i+1], FD_ACCEPT | 
FD_READ); 
}

/* putting interrupt event as a first one in the list
*/
events[0] = _PyOS_SigintEvent();
ResetEvent(events[0]);

Py_BEGIN_ALLOW_THREADS
errno = 0;
n = WSAWaitForMultipleEvents(ifdset.fd_count, events, FALSE, tvp ? 
(DWORD)_PyTime_AsMilliseconds(timeout, _PyTime_ROUND_CEILING) : WSA_INFINITE, 
FALSE);
Py_END_ALLOW_THREADS

if (n == 0) 
errno = EINTR;
else if (n == WSA_WAIT_FAILED)
n = SOCKET_ERROR;
else
n = 1; /* prototype implementation, acting like just 1 socket 
is ready,
   for actual number it will be probably necessary to query 
WSAWaitForMultipleEvents 
   multiple times since it otherwise returns only index of 
first ready event...
   */
}
#endif

and then I was able to interrupt the script above. I noticed slight performance 
loss when having timeout 0, repeating select 1000 times it took ~2000 us, wile 
after this update it took ~3000 us.

I am just throwing it here to consider as a possibility. Clearly my code above 
is just proof of concept, modification would be needed (include write fd, some 
proper fd limit, possibly check multiple times to get actual number of ready 
fds, etc...).

--
components: Interpreter Core, Windows
messages: 327354
nosy: Ondra Kutal, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Consider making Windows select.select interruptable using WSAEventSelect 
& WSAWaitForMultipleEvents
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue34933] json.dumps serializes double quotes incorrectly



Serhiy Storchaka  added the comment:

>>> print(json.dumps(a))
{"a": "//a[@asdf=\"asdf\"]"}

You seen the repr or the resulting string, not the resulting string itself.

--
nosy: +serhiy.storchaka
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

[issue34933] json.dumps serializes double quotes incorrectly

2018-10-08 Thread Juozas Masiulis



New submission from Juozas Masiulis :

currently python behaves like this:
>>> import json
>>> a={'a': '//a[@asdf="asdf"]'}
>>> json.dumps(a)
'{"a": "//a[@asdf=\\"asdf\\"]"}'

this behaviour is incorrect.

the resulting string should be '{"a": "//a[@asdf=\"asdf\"]"}'

The difference is that double quotes inside double quotes are escaped twice 
instead of once. 

compare it to behaviour in javascript:

> var a = {'a': '//a[@asdf="asdf"]'}
undefined

JSON.stringify(a)
"{"a":"//a[@asdf=\"asdf\"]"}"

--
messages: 327352
nosy: Juozas.Masiulis
priority: normal
severity: normal
status: open
title: json.dumps serializes double quotes incorrectly
type: behavior
versions: Python 2.7, Python 3.6

___
Python tracker 

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Rhodri James

On 05/10/18 21:48, ts9...@gmail.com wrote:

I am new to Python programming but have significant SQL and C experience. My simple question
is,"Why not standardize Python indentations to 3 spaces instead of 4 in order to avoid
potential programming errors associated with using "TAB" instead of 4 spaces?"

Thank you for the suggestion, Thomas. Unfortunately I think it's a
perfect example of something that was being discussed elsewhere, the
well-intentioned name change that actually makes things worse in the
long run.

I think the most likely outcome of switching to 3 space indentation,
which we could do right now with no need to change a single thing, is
that it would all seem to work perfectly well for a while. It wouldn't
take long for people to get irritated with actually typing three spaces
though, and to reprogram their Tab keys to three space tab stops. Once
that happens, it's only a matter of time before the people who believe
that Tabs should give you actual Tab characters do the same, and lo and
behold you are back where you started but with 3-space tab stops as well
as 4-space tab stops.

Why do I think that's what would happen? Because that's how we got
4-space tab stops in the first place. The original de facto standard
was for 8-space tab stops (see
https://en.wikipedia.org/wiki/Tab_key#Tab_characters for some
background). 8 characters on a 132-character line printer isn't that
much. 8 characters on an 80 column monitor is quite a long way, on the
other hand. People started using four spaces as a more reasonable size,
used the Tab key for convenience and eventually ended up with the unholy
mess we know and love today.

Fortunately 2-space tabbing never attracted the attention of the
tab-character purists, or we'd be in an even worse situation :-)

I've watched this sort of thing happen in too many different arenas over
the years, most obviously with my father's job. He worked with disabled
people, and changing terms used to refer to them never once got rid of
the associated prejudices. This doesn't seem to be an easy thing to
hear particularly when it's associated with something emotive like the
master/slave debate, but changing terms buys you at best a couple of
months free of previous associations. Then the old associations catch
up, and usually bring some new friends with them.

Changing indent sizes is falling into the same trap as changing
terminology, I'm afraid. It's an obvious, well-intentioned thought, but
it won't actually change anything for the better. Thank you for
bringing it up, though.

--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

[issue34931] os.path.splitext with more dots



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue34932] Add macOS TCP_KEEPALIVE to available socket options

2018-10-08 Thread Roundup Robot



Change by Roundup Robot :


--
keywords: +patch
pull_requests: +9144
stage:  -> patch review

___
Python tracker 

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

[issue34932] Add macOS TCP_KEEPALIVE to available socket options

2018-10-08 Thread Robert



New submission from Robert :

macOS uses TCP_KEEPALIVE in place of TCP_KEEPIDLE. It would be good to have 
this available in the socket library to use directly. 

Pull request coming up.

--
components: Library (Lib)
messages: 327351
nosy: llawall
priority: normal
severity: normal
status: open
title: Add macOS TCP_KEEPALIVE to available socket options
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue28167] remove platform.linux_distribution()

2018-10-08 Thread Chih-Hsuan Yen



Change by Chih-Hsuan Yen :


--
nosy:  -yan12125

___
Python tracker 

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

[issue28167] remove platform.linux_distribution()

2018-10-08 Thread Petr Viktorin



Petr Viktorin  added the comment:

Actually, the scope (right balance between usefulness and maintainability) is 
probably the hardest real problem to solve here.
PyPI lets you iterate on that. For a straight-to-stdlib module, you'd need to 
get it exactly right on the first time.

--

___
Python tracker 

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

[issue28167] remove platform.linux_distribution()

2018-10-08 Thread Petr Viktorin


Petr Viktorin  added the comment:

> I wasn't aware that starting out with a PyPI module is the only accepted 
> process for getting functionality into stdlib.

It's the main way things should get in. (Other ways exist, for example, 
dataclasses were added as simplification/merging of several existing libraries.)

> That certainly is a lot of work for what would be a trivial handful of lines 
> to parse key/value pairs and handle error paths, etc (and corresponding tests 
> of course).

Releasing on PyPI is trivial once you have the tests and documentation. I'll be 
glad to help with that.


> IMHO, forcing the PyPI route seems like a recipe for scope creep to me in 
> this case.

Not necessarily. You just need to carefully define the scope of the PyPI module 
– same as you would for the stdlib module. There's not much difference between 
stdlib and PyPI here:
after all, I'd argue the main reason platform.linux_distribution() was removed 
is that its scope was too wide to be maintainable.

> The cost of adding Yet Another Dependency has to be paid in either case.

Indeed. But it will be hard to get in otherwise.

BTW, another way a PyPI release help is that the functionality would be useful 
for previous versions of Python. At this point new features are targetting 
Python 3.8.
So, even if this does get into stdlib, a backport on PyPI would still be 
useful. Consider prior art like:
https://pypi.org/project/dataclasses/
https://pypi.org/project/asyncio/

--

___
Python tracker 

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

[issue28167] remove platform.linux_distribution()

2018-10-08 Thread rb



rb  added the comment:

Apologies for my tone. I wasn't aware that starting out with a PyPI module is 
the only accepted process for getting functionality into stdlib. That certainly 
is a lot of work for what would be a trivial handful of lines to parse 
key/value pairs and handle error paths, etc (and corresponding tests of course).

As a distribution developer, from my perspective we've already (finally) 
managed to reach widespread standardization and unification on a simple 
key/value pair specification, so it is particularly surprising to me that as a 
Python developer I cannot easily get to it.

IMHO, forcing the PyPI route seems like a recipe for scope creep to me in this 
case. Looking at that module, it tries to do so much more. /etc/os-release is 
widely accepted nowadays, and I think it would be widely useful to the majority 
of users to simply pass the values through to a Python dictionary, reflecting 
"this is what the OS says it is" over "this is my promised stable view". Many 
of the issues there are because it's trying to be "clever", IMHO, rather than 
just passing through the provided information from the platform. My proposed 
API promise would simply be "this is what os-release says" or "os-release 
information not available".

Of course the most popular PyPI module to solve a particular problem will 
always be the one with the widest scope, so there seems little point in writing 
a parallel minimal one. The cost of adding Yet Another Dependency has to be 
paid in either case.

--

___
Python tracker 

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

[issue32174] nonASCII punctuation characters can not display in python363.chm.

2018-10-08 Thread Ma Lin



Change by Ma Lin :


Added file: https://bugs.python.org/file47858/PR 9758 effects.png

___
Python tracker 

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

[issue28167] remove platform.linux_distribution()

2018-10-08 Thread Petr Viktorin


Petr Viktorin  added the comment:

In the recommended library, distro, real-world issues blew the code size up to 
1000 lines of code and the open issue count to 15 – so while it's definitely 
useful, it doesn't seem either fully complete or trivial to maintain: 
https://github.com/nir0s/distro/blob/master/distro.py
If you can do better, please make a library to implement the simple name/value 
parsing, publish it on PyPI (sadly, as Yet Another Dependency at this point), 
make sure it's unit-tested, documented and widely useful in the real world, and 
*then* suggest inclusion in the standard library. That's how things get into 
the stdlib nowadays.

If that sounds like a lot of work, please consider your tone when asking others 
to do it.

--

___
Python tracker 

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

[issue34931] os.path.splitext with more dots

2018-10-08 Thread Jan Novak



New submission from Jan Novak :

There are some old tickets about changing splitext() in 2007:
https://bugs.python.org/issue1115886
https://bugs.python.org/issue1681842

Present python documentation:
Leading periods on the basename are ignored; splitext('.cshrc') returns 
('.cshrc', '').
Changed in version 2.6: Earlier versions could produce an empty root when the 
only period was the first character.

But nobody take care about more than one dots:
For example this possible corect filenames:

>>> os.path.splitext('jpg')
('jpg', '')

So present function is insuficient (buggy) to use to detect right extension.
Maybe new parameter would be helpfull for that?
Like parameter "preserve_dotfiles" discussed in 2007.

And what to do with the wrong '.', '..', '...', ... filenames?

--
messages: 327346
nosy: xnovakj
priority: normal
severity: normal
status: open
title: os.path.splitext with more dots
type: behavior

___
Python tracker 

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

[issue28167] remove platform.linux_distribution()

2018-10-08 Thread rb



rb  added the comment:

> Maintaining the necessary logic Python is not really possible in the stdlib. 
> It's better to have a PyPI module for this which can be updated much more 
> easily.

The /etc/os-release syntax is stable, the file is implemented nearly everywhere 
and is unlikely to change, so I don't see why it'll be difficult to maintain. 
Just parse and give us the key/value pairs, please!

It's disappointing to have to add Yet Another Dependency to get this 
functionality, contrary to Python's "batteries included" philosophy.

--
nosy: +rb

___
Python tracker 

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

[issue32174] nonASCII punctuation characters can not display in python363.chm.

2018-10-08 Thread Ma Lin


Ma Lin  added the comment:

It seems impossible to specify the encoding of .chm to ASCII [1], the available 
encodings of .chm are limited to a list [2].

So I wrote a Sphinx extension for .chm output, it escapes the characters which 
(codepoint > 0x7F) to 7-bit ASCII. Most escaped characters are: “”’–…—

[1] 
https://github.com/sphinx-doc/sphinx/blob/master/sphinx/builders/htmlhelp.py#L203-L206
[2] 
https://github.com/sphinx-doc/sphinx/blob/master/sphinx/builders/htmlhelp.py#L136-L170

--

___
Python tracker 

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

[issue34930] sha1module: Switch sha1 implementation to sha1dc/hardened sha1

2018-10-08 Thread Antoine Pietri



New submission from Antoine Pietri :

SHA-1 has been broken a while ago. While the general recommandation is to 
migrate to more recent hashes (like SHA-2 and SHA-3), a lot of industry 
applications (notably Merkle DAG implementations like Git or Blockchains) 
require backwards compatibility with SHA-1, at least for the time being 
required for all the users to transition.

The SHAttered authors published along with their paper a reference 
implementation of a "hardened SHA-1" algorithm, a SHA-1 implementation that 
uses counter-cryptanalysis to detect inputs that were forged to produce a hash 
collision. What that means is that Hardened SHA-1 is a secure hash function 
that produces the same output as SHA-1 in 99.99...% of cases, and only 
differs when two inputs were specifically made to generate collisions. The 
reference implementation is here: 
https://github.com/cr-marcstevens/sha1collisiondetection

A large part of the industry has adopted Hardened SHA-1 as a temporary 
replacement for SHA-1, most notably Git under the name "sha1dc": 
https://github.com/git/git/commit/28dc98e343ca4eb370a29ceec4c19beac9b5c01e

Since CPython has its own implementation of SHA-1, I think it would be a good 
idea to provide a hardened SHA-1 implementation. So either:

1. we replace the current implementation of sha1 by sha1dc completely, which 
might be a problem for people who write script to detect whether two files 
collide with classic sha1

2. we replace the current implementation but we keep the old one under a new 
name, like "sha1_broken" or "sha1_classic", which breaks backwards 
compatibility in a few marginal cases but the functionality can be trivially 
restored by changing the name of the hash

3. we keep the current implementation but add a new one under a new name 
"sha1dc", which probably means most people will stay on a broken implementation 
for no good reason, but it will be fully backwards-compatible even in the 
marginal cases

4. we don't implement Hardened SHA-1 at all, and we advise people to change 
their hash algorithm, while realizing that this solution is not feasible in a 
lot of cases.

I'd suggest going with either 1. or 2. What would be your favorite option?

Not sure whether this should go in security or enhancement, so I put it in the 
latter category to be more conservative in issue prioritization. I added the 
devs who worked the most on Modules/sha1module.c in the Nosy list.

--
components: Library (Lib)
messages: 327343
nosy: antoine.pietri, christian.heimes, loewis, vstinner
priority: normal
severity: normal
status: open
title: sha1module: Switch sha1 implementation to sha1dc/hardened sha1
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue33643] Mock functions with autospec STILL don't support assert_called_once, assert_called, assert_not_called

2018-10-08 Thread Stéphane Wirtel


Stéphane Wirtel  added the comment:

There is a problem with your code, you use `mock` library but this one does not 
exist in the standard library. 

You should use `unittest.mock` 

Because this issue is not related with the unittest.mock library, I am going to 
close this issue.

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

[issue33643] Mock functions with autospec STILL don't support assert_called_once, assert_called, assert_not_called

2018-10-08 Thread Justin Dray



Justin Dray  added the comment:

I can still reproduce this with python 3.6.5:

https://gist.github.com/justin8/c6a565d3b64222a9ba3a2568d1d830ee

no .assert_called() on autospec'd functions, but it works with normal 
mock.MagicMock()

ipython autocomplete shows assert_any_call, assert_called_once, 
assert_called_with and assert_has_calls as valid functions however?

--
nosy: +Justin Dray

___
Python tracker 

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

[issue32174] nonASCII punctuation characters can not display in python363.chm.

2018-10-08 Thread Ma Lin



Change by Ma Lin :


--
keywords: +patch
pull_requests: +9143
stage:  -> patch review

___
Python tracker 

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

[issue34929] Extract asyncio sendfile tests into a separate test file



Change by Andrew Svetlov :


--
keywords: +patch
pull_requests: +9142
stage:  -> patch review

___
Python tracker 

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

[issue34929] Extract asyncio sendfile tests into a separate test file



Change by Andrew Svetlov :


--
components: Tests, asyncio
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Extract asyncio sendfile tests into a separate test file
versions: Python 3.8

___
Python tracker 

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

[issue34925] 25% speed-up to common case for bisect()



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue34928] string method .upper() converts 'ß' to 'SS' instead of 'ẞ'


Karthikeyan Singaravelan  added the comment:

No problem. Thanks for the confirmation I am closing this as a duplicate.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Germany made the upper case ß official. 'ß'.upper() should now 
return ẞ.

___
Python tracker 

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

[issue34928] string method .upper() converts 'ß' to 'SS' instead of 'ẞ'

2018-10-08 Thread Marc Richter



Marc Richter  added the comment:

Sorry then; that did not show up in my search :/
Yes, seems like this is duplicating that one.

--

___
Python tracker 

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

[issue33014] Clarify str.isidentifier docstring; fix keyword.iskeyword docstring

2018-10-08 Thread Lele Gaifax



Change by Lele Gaifax :


--
keywords: +patch
pull_requests: +9141
stage: needs patch -> patch review

___
Python tracker 

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

[issue34928] string method .upper() converts 'ß' to 'SS' instead of 'ẞ'