[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.

[Charles-François Natali]

Charles-François Natali added the comment:

Here's a patch against 2.7 using _PyOS_URandom(): it should apply as-is to 3.3.

--
keywords: +patch
nosy: +neologix
versions: +Python 3.3
Added file: http://bugs.python.org/file39679/mp_sem_race.diff

___
Python tracker 

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

[issue24175] Consistent test_utime() failures on FreeBSD

[Zachary Ware]

Changes by Zachary Ware :


--
nosy: +zach.ware

___
Python tracker 

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

[issue24175] Consistent test_utime() failures on FreeBSD

[koobs]

koobs added the comment:

test_utime is now consistently failing on 3.4, 3.5 and default

--
priority: normal -> high
title: Sporadic test_utime() failures on FreeBSD -> Consistent test_utime() 
failures on FreeBSD
versions: +Python 3.6

___
Python tracker 

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

[issue24324] Remove -Wunreachable-code flag

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
nosy: +pitrou

___
Python tracker 

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

[issue24324] Remove -Wunreachable-code flag

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
nosy: +loewis

___
Python tracker 

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

[issue23391] Documentation of EnvironmentError (OSError) arguments disappeared

[Martin Panter]

Martin Panter added the comment:

New patch with the following changes. Let me know what you think.

* Added extra markup for OSError attributes and constructor signature
* Explained how “winerror” works with and without Windows
* Added “filename2” argument
* Update tests for filename2 defaulting to None

For reference, the argument handling seems to be in oserror_parse_args(), at 
Objects/exceptions.c:724, and related functions.

--
versions: +Python 3.6
Added file: http://bugs.python.org/file39678/os-error-args.v2.patch

___
Python tracker 

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

[issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement

[Alex Lord]

Alex Lord added the comment:

Adding a patch for 3.6 since 3.5 is in beta.

--
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file39677/replace_lastrowid_3_6.patch

___
Python tracker 

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

[issue24408] tkinter.font.Font.measure() broken in 3.5

[Martin Panter]

Martin Panter added the comment:

Some quick googling suggests this “.Helvetica Neue DeskInterface” font is real, 
and because it begins with a full stop it may be normally hidden from the 
normal list of fonts. Perhaps the test could be modified to just check the two 
functions separately:

* families() returns a non-trivial sequence of font names
* actual("family") returns a non-trivial string

--

___
Python tracker 

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

[issue17310] Ctypes callbacks shows problem on Windows Python (64bit)

[Vinay Sajip]

Vinay Sajip added the comment:

I can confirm that the CFFI patch works as expected on Python 2.7.10.

--
stage:  -> test needed
versions: +Python 3.4, 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

[issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst

[Ned Deily]

Ned Deily added the comment:

Thanks for the report!

--
nosy: +ned.deily
resolution:  -> fixed
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

[issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4e7dcf64bba7 by Ned Deily in branch '3.5':
Issue #24423: Fix formatting error in 3.5 whatsnew
https://hg.python.org/cpython/rev/4e7dcf64bba7

New changeset 3156dd82df2d by Ned Deily in branch 'default':
Issue #24423: merger from 3.5
https://hg.python.org/cpython/rev/3156dd82df2d

--
nosy: +python-dev

___
Python tracker 

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

[issue17310] Ctypes callbacks shows problem on Windows Python (64bit)

[Vinay Sajip]

Vinay Sajip added the comment:

I note that the code for CFFI has a fix in ffi_prep_incoming_args_SYSV, as 
follows:

#ifdef _WIN64
  if (z > 8)
{
  /* On Win64, if a single argument takes more than 8 bytes,
 then it is always passed by reference. */
  *p_argv = *((void**) argp);
  z = 8;
}
  else
#endif
  *p_argv = (void*) argp; /* The original code, works for 32-bit */

(Source: 
https://bitbucket.org/cffi/cffi/src/abc8ff5b2885b3d9f22bbb314a011b8dd63c9e14/c/libffi_msvc/ffi.c?at=default)

--

___
Python tracker 

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

[issue24408] tkinter.font.Font.measure() broken in 3.5

[Ned Deily]

Ned Deily added the comment:

Test fails on OS X (10.10) with Cocoa Tk 8.6(.4) and 8.5(.18):

==
FAIL: test_families (test_tkinter.test_font.FontTest)
--
Traceback (most recent call last):
  File 
"/py/dev/27/root/fwd/Library/Frameworks/pytest_10.10.framework/Versions/2.7/lib/python2.7/lib-tk/test/test_tkinter/test_font.py",
 line 79, in test_families
self.assertIn(self.font.actual('family'), families)
AssertionError: '.Helvetica Neue DeskInterface' not found in ('Academy Engraved 
LET', 'Al Bayan', 'Al Nile', 'Al Tarikh', 'American Typewriter', 'Andale Mono', 
'Arial', 'Arial Black', 'Arial Hebrew', 'Arial Hebrew Scholar', 'Arial Narrow', 
'Arial Rounded MT Bold', 'Arial Unicode MS', 'Athelas', 'Avenir', 'Avenir 
Next', 'Avenir Next Condensed', 'Ayuthaya', 'Baghdad', 'Bangla MN', 'Bangla 
Sangam MN', 'Bank Gothic', 'Baoli SC', 'Baskerville', 'Beirut', 'Big Caslon', 
'Blackmoor LET', 'BlairMdITC TT', 'Bodoni 72', 'Bodoni 72 Oldstyle', 'Bodoni 72 
Smallcaps', 'Bodoni Ornaments', 'Bordeaux Roman Bold LET', 'Bradley Hand', 
'Brush Script MT', 'Capitals', 'Chalkboard', 'Chalkboard SE', 'Chalkduster', 
'Charter', 'Cochin', 'Comic Sans MS', 'Copperplate', 'Corsiva Hebrew', 
'Courier', 'Courier New', 'Damascus', 'DecoType Naskh', 'Devanagari MT', 
'Devanagari Sangam MN', 'Didot', 'DIN Alternate', 'DIN Condensed', 'Diwan 
Kufi', 'Diwan Thuluth', 'Euphemia UCAS', 'Farah', 'Farisi', 'Futura', 'GB18030 B
 itmap', 'Geeza Pro', 'Geneva', 'Georgia', 'Gill Sans', 'Gujarati MT', 
'Gujarati Sangam MN', 'GungSeo', 'Gurmukhi MN', 'Gurmukhi MT', 'Gurmukhi Sangam 
MN', 'Hannotate SC', 'Hannotate TC', 'HanziPen SC', 'HanziPen TC', 'HeadLineA', 
'Heiti SC', 'Heiti TC', 'Helvetica', 'Helvetica Neue', 'Herculanum', 'Hiragino 
Kaku Gothic Pro', [...]

--
nosy: +ned.deily
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

___
Python tracker 

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

[issue17310] Ctypes callbacks shows problem on Windows Python (64bit)

[Vinay Sajip]

Vinay Sajip added the comment:

Although Matt was able to work around his problem, this problem seems to still 
be present in 2.7 as well as all 3.x versions. I think I've found the cause of 
the problem: in 64-bit code, the calling conventions for passing structures by 
value are different. From this page:

https://msdn.microsoft.com/en-us/library/zthk2dkh(v=vs.90).aspx

I would point to "Structs/unions of size 8, 16, 32, or 64 bits and __m64 will 
be passed as if they were integers of the same size. Structs/unions other than 
these sizes will be passed as a pointer to memory allocated by the caller. For 
these aggregate types passed as a pointer (including __m128), the 
caller-allocated temporary memory will be 16-byte aligned."

The code in ffi_prep_incoming_args_SYSV (see 
https://hg.python.org/cpython/file/a1b76c1c3be8/Modules/_ctypes/libffi_msvc/ffi.c#l368)
 assumes (see lines 399, 402) that all value parameters are always passed 
inline on the stack - which is plainly not as per the documentation I linked 
to, for 64-bit code.

--
nosy: +vinay.sajip

___
Python tracker 

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

[issue24426] re.split performance degraded significantly by capturing group

[Patrick Maupin]

Patrick Maupin added the comment:

Just to be perfectly clear, this is no exaggeration:

My original file was slightly over 5GB.

I have approximately 1050 bad strings in it, averaging around 11 characters per 
string.

If I split it without capturing those 1050 strings, it takes 3.7 seconds.

If I split it and capture those 1050 strings, it takes 39 seconds.

ISTM that 33 ms to create a capture group with a single 11 character string is 
excessive, so there is probably something else going on like excessive object 
copying, that just isn't noticeable on a smaller source string.

In the small example I posted, if I replace the line:

data = 100 * (20 * ' ' + '\n')

with 

data = 1000 * (50 * ' ' + '\n')

then I get approximately the same 3.7 second vs 39 second results on that 
(somewhat older) machine.  I didn't start out with that in the example, because 
I thought the problem should still be obvious from the scaled down example.

Obviously, your CPU numbers will be somewhat different.  The question remains, 
though, why it takes around 60 million CPU cycles for each and every returned 
capture group.  Or, to put it another way, why can I stop doing the capture 
group, and grab the same string with pure Python by looking at the string 
lengths of the intervening strings, well over 100 times faster than it takes 
for the re module to give me that group?

Thanks,
Pat

--

___
Python tracker 

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

[issue24426] re.split performance degraded significantly by capturing group

[Patrick Maupin]

Patrick Maupin added the comment:

1) I have obviously oversimplified my test case, to the point where a developer 
thinks I'm silly enough to reach for the regex module just to split on a 
linefeed.

2) '\n(?<=(\n))' -- yes, of course, any casual user of the re module would 
immediately choose that as the most obvious thing to do.

3) My real regex is r'( [a-zA-Z0-9_]+ \[[0-9]+\][0-9:]+\].*\n)' because I am 
taking nasty broken output from a Cadence tool, fixing it up, and dumping it 
back out to a file.  Yes, I'm sure this could be optimized, as well, but when I 
can just remove the parentheses and get a 10X speedup, and then figure out the 
string I meant to capture by looking at string lengths, shouldn't there at 
least be a warning that the re module has performance issues with capturing 
groups with split(), and casual users like me should figure out what the 
matching strings are some other way?


I assumed that, since I saw almost exactly the same performance degradation 
with \n as I did with this, that that was a valid testcase.  If that was a bad 
assumption and this is insufficient to debug it, I can submit a bigger testcase.


But if this issue is going to be wontfixed for some reason, there should 
certainly be a documentation note added, because it is not intuitive that 
splitting 5GB of data into 1000 strings of around 5MB each should be 10X faster 
than doing the same thing, but also capturing the 1K ten-byte strings inbetween 
the big ones.


Thanks,
Pat

--

___
Python tracker 

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

[issue24428] Import sys,getopt is having issue while taking inputs

[Eric V. Smith]

Eric V. Smith added the comment:

This is not a problem with python, but rather with how bash interprets your 
program arguments. Try putting the arguments in single quotes, like:

python validate_json_adj.py -i '$#@%'

--
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: behavior -> 

___
Python tracker 

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

[issue24428] Import sys,getopt is having issue while taking inputs

[venkata suresh gummadillli]

New submission from venkata suresh gummadillli:

[@outsidetried ~]$ python validate_json_adj.py 
[@outsidetried ~]$ python validate_json_adj.py -h
validate_json.py -i 
[@outsidetried ~]$ python validate_json_adj.py -i hello.txt
Input JSON file provided for verification: hello.txt
[@outsidetried ~]$ python validate_json_adj.py -i firstfile
Input JSON file provided for verification: firstfile
[@outsidetried ~]$ python validate_json_adj.py -i 
-bash: syntax error near unexpected token `newline'
[sureshgv@outsidetried ~]$ python validate_json_adj.py -i ??
Input JSON file provided for verification: ci
[@outsidetried ~]$ python validate_json_adj.py -i ???
Input JSON file provided for verification: bf1
[@outsidetried ~]$ python validate_json_adj.py -i $#@%
Input JSON file provided for verification: 0@%
[@outsidetried ~]$ cat validate_json_adj.py 
#!/usr/bin/python
"""
"""

import sys,getopt


"""
 """

def main(argv):
   inputfile = ''
   try:
  opts, args = getopt.getopt(argv,"hi:",["input_file="])
   except getopt.GetoptError:
  print 'validate_json.py -i '
  sys.exit(2)
   for opt, arg in opts:
  if opt == '-h':
 print 'validate_json.py -i '
 sys.exit()
  elif opt in ("-i", "--input_file"):
 inputfile = arg
 print 'Input JSON file provided for verification:', inputfile 
if __name__ == "__main__":
   main(sys.argv[1:])

--
components: Library (Lib)
messages: 245142
nosy: venkata suresh gummadillli
priority: normal
severity: normal
status: open
title: Import sys,getopt is having issue while taking inputs
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

[issue24426] re.split performance degraded significantly by capturing group

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Splitting with pattern '\n(?<=(\n))' produces the same result as with pattern 
'(\n)' and is as fast as with pattern '\n'.

--

___
Python tracker 

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

[issue24427] subclass of multiprocessing Connection segfault upon attribute acces

[Charles-François Natali]

New submission from Charles-François Natali:

The following segfaults in _PyObject_GenericGetAttrWithDict:

"""
from socket import socketpair
from _multiprocessing import Connection


class Crash(Connection):
pass

_, w = socketpair()

Crash(w.fileno()).bar
"""

#0  _PyObject_GenericGetAttrWithDict (dict=0xa6b001c, name=0xb7281020, 
obj=0x8c12478) at Objects/object.c:1427
#1  PyObject_GenericGetAttr (obj=0x8c12478, name=0xb7281020) at 
Objects/object.c:1461

(gdb) p *(obj + obj->ob_type->tp_dictoffset)
$8 = {ob_refcnt = 0, ob_type = 0x0}

It's probably not specific to this example, but I'm not familiar enough with 
object construction/descriptors to know what's going on here.

Note that the following atch fixes the crash, but I don't know why:
"""
--- a/Modules/_multiprocessing/connection.h Wed Apr 15 19:30:38 2015 +0100
+++ b/Modules/_multiprocessing/connection.h Wed Jun 10 20:25:15 2015 +0100
@@ -58,7 +58,7 @@
 return NULL;
 }
 
-self = PyObject_New(ConnectionObject, type);
+self = type->tp_alloc(type, 0);
 if (self == NULL)
 return NULL;
 
@@ -86,7 +86,7 @@
 CLOSE(self->handle);
 Py_END_ALLOW_THREADS
 }
-PyObject_Del(self);
+Py_TYPE(self)->tp_free((PyObject*)self);
 }
 
 /*
"""

--
messages: 245140
nosy: neologix, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: subclass of multiprocessing Connection segfault upon attribute acces

___
Python tracker 

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

[issue24426] re.split performance degraded significantly by capturing group

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Regular expression is optimized for the case when it starts with constant 
string or charset. It is no degradation when using '(\n)', but rather an 
optimization of '\n'.

--

___
Python tracker 

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

[issue24420] Documentation regressions from adding subprocess.run()

[Thomas Kluyver]

Thomas Kluyver added the comment:

Thanks, this looks good to me.

--

___
Python tracker 

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

[issue24426] re.split performance degraded significantly by capturing group

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue7267] format method: c presentation type broken in 2.7

[Jakub Wilk]

Changes by Jakub Wilk :


--
nosy: +jwilk

___
Python tracker 

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

[issue24426] re.split performance degraded significantly by capturing group

[Patrick Maupin]

New submission from Patrick Maupin:

The addition of a capturing group in a re.split() pattern, e.g. using '(\n)' 
instead of '\n', causes a factor of 10 performance degradation.

I use re.split a() lot, but never noticed the issue before.  It was extremely 
noticeable on 1000 patterns in a 5BG file, though, requiring 40 seconds instead 
of 4.

I have attached a script demonstrating the issue.  I have tested on 2.7 and 
3.4, but have no reason to believe it doesn't exist on other vesions as well.

Thanks,
Pat

--
components: Regular Expressions
files: splitter2.py
messages: 245137
nosy: Patrick Maupin, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.split performance degraded significantly by capturing group
type: performance
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file39676/splitter2.py

___
Python tracker 

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

[issue24400] Awaitable ABC incompatible with functools.singledispatch

[Stefan Behnel]

Stefan Behnel added the comment:

> I currently do isinstance(x, types.GeneratorType), which will fail if x
> is actually a GeneratorWrapper. I can change this to use
> collections.abc.Generator when it exists, but then I'd have to have some
> conditional logic to switch between collections.abc and types depending
> on what version I'm running on.

I originally planned to make the next Cython release patch the Generator
and Coroutine ABCs into collections.abc, but I now think it would be worth
uploading an "abc_backports" package to PyPI instead that does that and on
which asyncio, tornado and other packages could simply depend with a
try-import.

> It would be nice if that were
> encapsulated in inspect.isgenerator().

+1, code that needs exactly a generator, e.g. for "gi_running" and friends,
can still test for isinstance(obj, types.GeneratorType) in a completely
backwards compatible way, which is more explicit anyway.

> More generally, the inconsistency between isgenerator() and
> iscoroutine() is kind of odd. I would expect that either all inspect
> functions or none of them would use a suitable ABC if one exists.

Yes, it's odd. Either way would work ("types is for types only" vs. "types
includes protocols"), but having both disagree seems wrong.

I think the mere fact that there is a higher level function than
isinstance() suggests that it should really be more high level and not just
doing exactly the same for all times.

--

___
Python tracker 

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

[issue24425] Installer Vender Issue

[Steve Dower]

Steve Dower added the comment:

Can you run the following command and then post the log.txt file it generates:

msiexec /l*vx log.txt /i 

--

___
Python tracker 

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

[issue24425] Installer Vender Issue

[R. David Murray]

Changes by R. David Murray :


--
components: +Extension Modules, Windows -Installation
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue24379] slice.literal notation

[Joe Jevnik]

Joe Jevnik added the comment:

It is a singleton, does not accept the `maketuple` flag, and is written in C. I 
did not know about the s_ attribute of numpy before writing this; however, I 
still think that moving this object to slice improves code clarity (s_ is not a 
super clear name). I also think that this behaviour belongs on the slice object.

--

___
Python tracker 

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

[issue24379] slice.literal notation

[Tal Einat]

Tal Einat added the comment:

So, is this in any ways different than NumPy's s_?

--

___
Python tracker 

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

[issue24425] Installer Vender Issue

[Hayden Young]

New submission from Hayden Young:

For some reason, my Python installer won't run properly. When I click install, 
after DISabling PIP in the installer (And with pip on), it tells me the 
following: "There is a problem with this windows installer package. A program 
required for this install to complete cannot be run. Contact your support 
personnel or package vendor." 

Can anyone help me here?
I really need Python for school, but my laptop won't run this properly.
If it's to do with my specs, they are this:

Laptop: Dell Latitude E6230 (Non-SSD)
Core: Intel i5 Processor

PLEASE HELP!

--
components: Installation
messages: 245132
nosy: Hayden Young
priority: normal
severity: normal
status: open
title: Installer Vender Issue
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

[issue24379] slice.literal notation

[Joe Jevnik]

Joe Jevnik added the comment:

>>> slice.literal[0]
0
>>> y = slice.literal[1:2]
slice(1, 2, None)
>>> slice.literal[0:1, ..., 3]
(slice(0, 1, None), Ellipsis, 3)

The way this object works right now does not create instances of some inner 
class of slice, instead, indexing it returns the key without modification.

--

___
Python tracker 

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

[issue24400] Awaitable ABC incompatible with functools.singledispatch

[Yury Selivanov]

Yury Selivanov added the comment:

> With the two changes I described things appear to be working, although I've 
> only done light testing so far.

Glad to hear that!  I've attached a new patch fixing types.coroutine per your 
request.

> More generally, the inconsistency between isgenerator() and iscoroutine() is 
> kind of odd. I would expect that either all inspect functions or none of them 
> would use a suitable ABC if one exists.

iscoroutine() is just a newer API than isgenerator().  I'll create a new issue 
for this soon.

--
Added file: http://bugs.python.org/file39675/corotype.patch

___
Python tracker 

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

[issue24400] Awaitable ABC incompatible with functools.singledispatch

[Ben Darnell]

Ben Darnell added the comment:

With the two changes I described things appear to be working, although I've 
only done light testing so far.

For inspect.isgenerator(), my use case is here: 
https://github.com/tornadoweb/tornado/blob/2971e857104f8d02fa9107a0e13f50170eb4f30d/tornado/gen.py#L222

I currently do isinstance(x, types.GeneratorType), which will fail if x is 
actually a GeneratorWrapper. I can change this to use collections.abc.Generator 
when it exists, but then I'd have to have some conditional logic to switch 
between collections.abc and types depending on what version I'm running on. It 
would be nice if that were encapsulated in inspect.isgenerator(). 

More generally, the inconsistency between isgenerator() and iscoroutine() is 
kind of odd. I would expect that either all inspect functions or none of them 
would use a suitable ABC if one exists.

--

___
Python tracker 

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

[issue672115] Assignment to __bases__ of direct object subclasses

[Boris]

Changes by Boris :


--
nosy: +borisompol

___
Python tracker 

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

[issue24424] xml.dom.minidom: performance issue with Node.insertBefore()

[Robert Haschke]

New submission from Robert Haschke:

Node.insertBefore() has a serious performance issue:

Using self.childNodes.index(refChild) it searches for the correct index in 
childNodes where the newChild should be inserted.
However, index() is linear in time w.r.t. the size of childNodes.
Hence, if there are many children, runtime dramatically increases.

Adding a simple caching mechanism (caching the previously used reference)
I was able to reduce runtime in my particular case from 16s to 1.6s, i.e. a 
factor of 10!

--
components: XML
files: minidom.insertBefore.patch
keywords: patch
messages: 245128
nosy: Robert Haschke
priority: normal
severity: normal
status: open
title: xml.dom.minidom: performance issue with Node.insertBefore()
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file39674/minidom.insertBefore.patch

___
Python tracker 

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

[issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst

[Stefan Tatschner]

New submission from Stefan Tatschner:

A list item which describes the changes of #22631 is badly indented. The 
attached (trivial) patch fixes that problem.

--
assignee: docs@python
components: Documentation
files: fix-indentation.patch
keywords: patch
messages: 245127
nosy: docs@python, rumpelsepp
priority: normal
severity: normal
status: open
title: Fix wrong indentation in Doc/whatsnew/3.5.rst
versions: Python 3.5
Added file: http://bugs.python.org/file39673/fix-indentation.patch

___
Python tracker 

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

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

[Jan Harkes]

Jan Harkes added the comment:

@Carl.Kleffner: that is an interesting message but it discusses using 
binutils(/mingw?) generated import libraries with the MS linker.

This bugreport was about two 64-bit objects that were accidentally included in 
an otherwise 32-bit library and it has been resolved.

I am not entirely sure why people are anticipating possible problems for which 
I have seen no actual bug reports or build failures. Searching this bugtracker 
for mingw related reports shows 187 reports over the past 13.5 years and at 
first glance I don't see any about compatibility issues between versions. There 
are only 3 for mingw+libpython, one of which is this report.

The various windows forks of mingw, maybe in an attempt to reach Visual C 
compatibility, may have as stable a format but the only failure I have 
personally seen was this 64-bit objects in a 32-bit library problem, which does 
look to me like a tool chain bug but luckily there was a relatively simple 
"--as-flags=--32" workaround.

I just reread my comment and I it reads ruder than I meant it to be, I'm truly 
sorry for that. I appreciated reading the link you included to see some of 
those demons lurking in the depths.

--

___
Python tracker 

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

[issue24400] Awaitable ABC incompatible with functools.singledispatch

[Nick Coghlan]

Nick Coghlan added the comment:

A couple of high level observations:

1. As Yury notes, more clearly separating coroutines and generators is the
intent of the PEP. The computer could clearly cope with them being the same
class, but humans tended to get confused. We were still blurring that line
too much in the initial implementation, this patch aims to fix that by
*really* introducing a separate class for native coroutines.

2. Missing integrations in other modules that are likely to result in
misbehaviour in user code (such as the inspect module not accounting for
the new ABCs) are good candidates for filing as behaviour bugs - finding
that kind of gap in PEP implementations is one of the benefits of the beta
period.

3. Integrating nicely with both asyncio and Tornado is a good pragmatic
design goal to avoid making too many asyncio specific assumptions

--

___
Python tracker 

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

[issue24422] base64 not encode correctly

[Ezio Melotti]

Ezio Melotti added the comment:

No, this is expected.
See http://en.wikipedia.org/wiki/Base64#Padding

--
nosy: +ezio.melotti
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

[issue24422] base64 not encode correctly

[Hector Cloud]

New submission from Hector Cloud:

I use Python 3.4.0 now. But its base64 encoding is not as expected.

import base64
ascii = base64.b64encode(u"YAU-interview-revised20120921".encode(), b'-_')
print(ascii)

The result is b'WUFVLWludGVydmlldy1yZXZpc2VkMjAxMjA5MjE='. There is a character 
'=' at the end which is not expected. In my opinion, the result should contain 
characters [A-Za-z0-9] and '-_'. The '=' should not be in the encoding result.

Is it a bug?

--
components: Library (Lib)
messages: 245123
nosy: Hector Cloud
priority: normal
severity: normal
status: open
title: base64 not encode correctly
type: behavior
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

[issue22359] Remove incorrect uses of recursive make

[Martin Panter]

Martin Panter added the comment:

My math and cmath issue seems to be completely separate. I opened Issue 24421 
for that, so sorry for the noise here :)

I think the patch here should be applied (or adapted if necessary) to the 3.4 
and 2.7 branches. If it breaks cross compilation, then the cross compilation 
technique needs improving instead; perhaps see Issue 22625 for that.

--

___
Python tracker 

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

[issue24421] Race condition compiling Modules/_math.c

[Martin Panter]

New submission from Martin Panter:

Once or twice I have had the math or cmath modules fail to build. There seems 
to be a race condition, because the _math.c file seems to be compiled twice, 
once for each module. Attached is a GCC wrapper that should help reproduce this 
fairly consistently. First, build Python normally:

$ ./configure
$ make -j2

Then force Modules/_math.c to be recompiled using my wrapper script to amplify 
the race condition:

$ touch Modules/_math.c
$ rm 
build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o
$ make -j2 CC=./slow-cc.py
running build
running build_ext
building 'cmath' extension
compiling for  cmath
./slow-cc.py [. . .]/Modules/cmathmodule.o
building 'math' extension
./slow-cc.py [. . .]/Modules/mathmodule.o
./slow-cc.py -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code 
-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes 
-Werror=declaration-after-statement -I./Include -I. -IInclude 
-I/usr/local/include -I/media/disk/home/proj/python/cpython/Include 
-I/media/disk/home/proj/python/cpython -c 
/media/disk/home/proj/python/cpython/Modules/_math.c -o 
build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o
INITIAL COMPILE
./slow-cc.py -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code 
-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes 
-Werror=declaration-after-statement -I./Include -I. -IInclude 
-I/usr/local/include -I/media/disk/home/proj/python/cpython/Include 
-I/media/disk/home/proj/python/cpython -c 
/media/disk/home/proj/python/cpython/Modules/_math.c -o 
build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o
RECOMPILE
RECOMPIILE TRUNCATING
INITIAL COMPILE FINISHED
./slow-cc.py -shared 
build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/mathmodule.o
 
build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o 
-L/usr/local/lib -lm -o 
build/lib.linux-x86_64-3.6/math.cpython-36m-x86_64-linux-gnu.so
build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o:
 file not recognized: File truncated
collect2: error: ld returned 1 exit status
RECOMPILE FINISHED
./slow-cc.py -shared 
build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/cmathmodule.o
 
build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o 
-L/usr/local/lib -lm -o 
build/lib.linux-x86_64-3.6/cmath.cpython-36m-x86_64-linux-gnu.so

Failed to build these modules:
math

--
components: Build
files: slow-cc.py
messages: 245121
nosy: vadmium
priority: normal
severity: normal
status: open
title: Race condition compiling Modules/_math.c
type: behavior
Added file: http://bugs.python.org/file39672/slow-cc.py

___
Python tracker 

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

[issue24086] Configparser interpolation is unexpected

[Jens Diemer]

Jens Diemer added the comment:

IMHO i ran into the same bug, try to "./setup.py upload" with my new password 
in ~/.pypirc:

configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(', 
found: "%foobar"

This is a limitation of the configparser... But what's about to validate this 
on the "set PyPi password view" ?

So that's impossible to set a PyPi password which can't be parsed by 
configparser ?

--
nosy: +jens

___
Python tracker 

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

[issue22359] Remove incorrect uses of recursive make

[koobs]

koobs added the comment:

martin: yes, if the incorrect usage of recursive make is in the 2.7 and 3.4 
branches and the fix is relevant to the issues I reported. Of course all 
subsequent changes (fixing cross-builds) should be applied there too.

--

___
Python tracker 

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

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

[Carl Kleffner]

Carl Kleffner added the comment:

I experienced this behaviour by accident several times. Most likely this is due 
to inconsistenticies in different binutils and mingw-runtime versions/patches. 
See i.e. http://article.gmane.org/gmane.comp.gnu.binutils/46799
A robust solution is to exclusively use import libraries created by the 
toolchain used for building python extensions.

--

___
Python tracker 

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