[issue27515] Dotted name re-import does not rebind after deletion

[Guido van Rossum]

Guido van Rossum added the comment:

Are you sure you realize that "import email.charset" doesn't create a
local variable named "email.charset"? It creates a local variable
named "email" which happens to have an attribute "charset".

The problem with "import pack; print(pack.sub)" being unpredictable is
explainable though annoying, but I don't think it can be avoided.
After all there's no intrinsic reason why module "pack" couldn't have
some attribute named "sub" unrelated to a submodule.

I'm not sure what you mean by injections or cleaning them up. Perhaps
there's some overzealousness here that causes this broken behavior?

Is there somewhere in the IDLE code that you'd like me to look at?

--

___
Python tracker 

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

[issue27514] SystemError when compiling deeply nested for loops

[Roundup Robot]

Roundup Robot added the comment:

New changeset e6e7c8368c70 by Benjamin Peterson in branch '3.5':
make too many nested blocks be a SyntaxError instead of a SystemError (closes 
#27514)
https://hg.python.org/cpython/rev/e6e7c8368c70

New changeset 345ec7455b75 by Benjamin Peterson in branch '2.7':
make too many nested blocks be a SyntaxError instead of a SystemError (closes 
#27514)
https://hg.python.org/cpython/rev/345ec7455b75

New changeset d1da87d8b29c by Benjamin Peterson in branch 'default':
merge 3.5 (#27514)
https://hg.python.org/cpython/rev/d1da87d8b29c

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

[issue1621] Do not assume signed integer overflow behavior

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The audioop part LGTM. If this case was found with the help of -ftrapv, I'm for 
adding this option in a debug build.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue27514] SystemError when compiling deeply nested for loops

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM.

--
stage: needs patch -> commit review

___
Python tracker 

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

[issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +nadeem.vawda, serhiy.storchaka
stage:  -> patch review
versions:  -Python 3.3, Python 3.4

___
Python tracker 

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

[issue1621] Do not assume signed integer overflow behavior

[Martin Panter]

Martin Panter added the comment:

I added Issue 13312 as a dependency, there is currently a test for a negative 
year that relies on overflow handling.

Here is a patch where I tried to fix overflow detection for huge set objects.

--
Added file: http://bugs.python.org/file43729/set-overflow.patch

___
Python tracker 

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

[issue1621] Do not assume signed integer overflow behavior

[Martin Panter]

Martin Panter added the comment:

Inspired by Issue 27473, I did a quick and dirty scan for obvious places that 
expect overflow to wrap, and found the following, which I think should be fixed:

Modules/_ctypes/_ctypes.c:1388, in PyCArrayType_new()
Objects/listobject.c:492, in list_concat()
Objects/tupleobject.c:457, in tupleconcat()
Objects/listobject.c:845, in listextend()

Also I played with enabling GCC’s -ftrapv option. Attached is a patch with 
three changes:

1. configure --with-pydebug enables -ftrapv (experimental, not sure everyone 
would want this)

2. Easy fix for negation overflow in audioop (I am happy to apply this part)

3. Avoid dumb overflows at end of for loop in Element Tree code when handling 
slices with step=sys.maxsize. Technically the overflow is undefined behaviour, 
but the change is annoying, because ignoring the overflow at the end of the 
loop is much simpler than adding special cases. Not sure what I think about 
this part.

--
dependencies: +test_time fails: strftime('%Y', y) for negative year
nosy: +martin.panter
Added file: http://bugs.python.org/file43728/trapv.patch

___
Python tracker 

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

[issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more

[Martin Panter]

Martin Panter added the comment:

This is on my list of things to look at, just that I have been away and am a 
bit backlogged atm.

--

___
Python tracker 

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

[issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more

[Xiang Zhang]

Xiang Zhang added the comment:

ping

--

___
Python tracker 

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Martin Panter]

Martin Panter added the comment:

I can try to add the RuntimeWarning soon. Obviously we want the warning when 
executing a submodule like “package.module”. It also seems reasonable to warn 
when executing a top-level module that has already been imported. I presume we 
want these to go into the next 3.5 release. What about 2.7?

I guess we don’t want a warning when executing “package.__main__”, even if the 
parent package is already imported. So I also need to check if 
sys.modules[...].__path__ exists.

Another thing that I wonder about: What if the message “Error finding spec for 
. . .” was changed to “Error getting import information for . . .”? I am only 
just starting to understand that “finding spec” may mean this (I think the 
documentation has improved since I last tried to understand it).

--

___
Python tracker 

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

[issue27515] Dotted name re-import does not rebind after deletion

[Terry J. Reedy]

Terry J. Reedy added the comment:

I don't understand the statement that having 'import email.charset' set 
email.charset is an optional side effect.  Without the name setting, the module 
is inaccessible except through sys.modules, which is not obvious to beginners.  
To me, making a module directly accessible is the main point of an import.  As 
it is now, the second 'import email.charset' in the example is equivalent to 
'pass'.

The test example is simplified to show the core behavior.  The real life 
problem arises when the second 'import package.submodule' is in a different 
module, perhaps the main module, or in the case of an IDE such as IDLE, in user 
code exec()ed as is it were running in a main module.

When a module runs 'import pack.sub' (for now, only the first time), the 'pack' 
module is 'monkey-patched' by externally injecting 'sub'.  After this, without 
a deletion, the normally buggy "import pack; print(pack.sub)" executed anywhere 
in the process will work.

Since June 2015, there have been 4 StackOverflow questions about IDLE giving 
implicit false positives by running code that fails when run directly in 
Python.  I believe that this is more questions during this period than for any 
other IDLE issue.

Currently, if a module author tries to be conscientious and clean up any 
injections it caused, then the process-global effect is to disable normally 
correct code.

The point of this issue, however classified, is to make it possible for a 
module to access the modules of a different package without causing mysterious 
action-at-a-distance effects.  Sorry I did not initially explain this better 
here.

--

___
Python tracker 

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

[issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice

[Benjamin Fogle]

Benjamin Fogle added the comment:

The above code demonstrates two separate issues. One with the decompressor, and 
one with the compressor.

In the compressor example, the first output differs from the rest because it is 
a file header which is always emitted. That behavior is correct.

--

___
Python tracker 

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

[issue27516] Wrong initialization of python path with embeddable distribution

[Eryk Sun]

Eryk Sun added the comment:

It looks like you haven't copied pyvenv.cfg to your application directory, so 
Python isn't using the "applocal" configuration. That's why you're seeing the 
default paths that are relative to the current directory. It's also why 
PYTHONPATH and PYTHONHOME aren't ignored. 

As to the extension modules, if you don't want them in the application 
directory, add them to the DLLs subdirectory. Here's a possible layout:

App\
DLLs\
_socket.pyd
...
Lib\
vendored_package
...
app.exe
pyvenv.cfg
python35.dll
python35.zip
vcruntime140.dll

I created this app in C:\Temp, and here's its sys.path:

['C:\\Temp\\App\\python35.zip', 'C:\\Temp\\App\\DLLs', 
'C:\\Temp\\App\\lib', 'C:\\Temp\\App']

--
nosy: +eryksun

___
Python tracker 

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

[issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail

[Terry J. Reedy]

Terry J. Reedy added the comment:

The SO question and that brought the problem to my attention was in June 2015. 
https://stackoverflow.com/questions/30877112/tkinter-code-using-font-module-cant-run-from-command-line.
  The message I just unlinked had the wrong url.

--

___
Python tracker 

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

[issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
Removed message: http://bugs.python.org/msg259039

___
Python tracker 

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

[issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice

[Decorater]

Decorater added the comment:

Why you passing decompress without passing compress before decompressing it 
again?

Also I would expect that it would show the same compress result trice in a row 
on the 1st test. This must definately be a issue.

--
nosy: +Decorater

___
Python tracker 

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

[issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice

[Benjamin Fogle]

New submission from Benjamin Fogle:

To reproduce:

>>> import lzma
>>> c = lzma.LZMACompressor()
>>> c.compress(b'')
b'\xfd7zXZ\x00\x00\x04\xe6\xd6\xb4F'
>>> c.compress(b'')
b''
>>> c.compress(b'')
Traceback (most recent call last):
  File "", line 1, in 
_lzma.LZMAError: Insufficient buffer space
>>> d = lzma.LZMADecompressor()
>>> d.decompress(b'')
b''
>>> d.decompress(b'')
Traceback (most recent call last):
  File "", line 1, in 
_lzma.LZMAError: Insufficient buffer space

This can occur anytime during compression/decompression when an empty string is 
passed twice in a row.

The problem is that that liblzma interprets a call to lzma_code() with avail_in 
== 0 as a buffer full condition. The second time in a row it encounters this, 
it returns LZMA_BUF_ERROR as per documentation. The attached patch prevents 
this condition from occurring.

--
components: Extension Modules
files: lzma.patch
keywords: patch
messages: 270451
nosy: benfogle
priority: normal
severity: normal
status: open
title: LZMACompressor and LZMADecompressor raise exceptions if given empty 
strings twice
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43727/lzma.patch

___
Python tracker 

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

[issue27516] Wrong initialization of python path with embeddable distribution

[Steve Dower]

Steve Dower added the comment:

Environment variables shouldn't make any different to the embeddable distro - 
it is designed to ignore them. Have you modified it at all?

The path is not as clean as I'd like it to be, but the initialization changes 
necessary are too significant for 3.5 at this stage (expect something better 
for 3.6).

--

___
Python tracker 

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

[issue27516] Wrong initialization of python path with embeddable distribution

[Palm Kevin]

Palm Kevin added the comment:

BTW: Is there a good reason, the folder-of-the-executable is added to the 
python-path? I don't see any...

--

___
Python tracker 

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

[issue27516] Wrong initialization of python path with embeddable distribution

[Ned Deily]

Changes by Ned Deily :


--
components: +Windows
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

[issue27510] Found some Solution build missconfigurations.

[Steve Dower]

Steve Dower added the comment:

I just checked and the pcbuild.sln you posted is identical to what's currently 
checked in.

Batch build settings are not part of the checkin, so if you want to use that 
rather than using the build scripts we provide (see PCBuild/build.bat) then 
you'll need to configure the selection locally.

--
resolution:  -> not a bug
stage: needs patch -> 
status: open -> closed

___
Python tracker 

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

[issue27516] Wrong initialization of python path with embeddable distribution

[Palm Kevin]

New submission from Palm Kevin:

The way the python path is initialized with the embeddable python distribution 
makes no sense for me.

If no environment variable PYTHONPATH is set, then the path is initialized like 
this:
  [python352]\python35.zip;.\DLLs;.\lib;[folder_of_executable]
 --> the distribution folder itself is not in the path ([python352]), an 
import of _socket will thus fail !
 --> Having DLLs and lib in the path is useless
(Notice, that when the PYTHONHOME is initialized, then the path '[python352]' 
is also used for DLLs and lib (instead of '.\')


If the environment variable PYTHONPATH is set, then the path is extended like 
this:
  [python352]\python35.zip;[folder_of_executable]
 --> the distribution folder itself is not in the path ([python352]), an 
import of _socket will thus fail !

I would prefer this behavior:
* python path is not initialized anymore with 'DLLs' and 'lib' 
* the distribution-folder should always be added to the python-path

--
messages: 270447
nosy: palm.kevin
priority: normal
severity: normal
status: open
title: Wrong initialization of python path with embeddable distribution
type: enhancement
versions: Python 3.5

___
Python tracker 

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

[issue27514] SystemError when compiling deeply nested for loops

[Ammar Askar]

Ammar Askar added the comment:

Amended patch with the comment fixed to refer to just the issue numbers 
according to advice from bitdancer.

--
Added file: http://bugs.python.org/file43726/nested_blocks.diff2

___
Python tracker 

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

[issue27514] SystemError when compiling deeply nested for loops

[Ammar Askar]

Ammar Askar added the comment:

This patch changes it to a SyntaxError instead of a SystemError.

--
keywords: +patch
nosy: +ammar2
Added file: http://bugs.python.org/file43725/nested_blocks.diff

___
Python tracker 

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

[issue27515] Dotted name re-import does not rebind after deletion

[R. David Murray]

R. David Murray added the comment:

So, Guido answered your actual question, and I was confused :(  The important 
point is that email.charset still exists in sys.modules, so import doesn't 
reload it, and as Guido says module load is the thing that creates the 
attribute mapping.

--

___
Python tracker 

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

[issue27515] Dotted name re-import does not rebind after deletion

[Guido van Rossum]

Guido van Rossum added the comment:

> On the second import, import finds email in sys.modules

Actually, it only takes the shortcut because it also finds
email.charset in sys.modules.

--

___
Python tracker 

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

[issue27515] Dotted name re-import does not rebind after deletion

[R. David Murray]

R. David Murray added the comment:

Heh, actually strike that last sentence.  Doing a del doesn't remove the module 
from sys.modules, so the version of the email module with charset deleted is 
still there, and doing del email and import email or import email.charset will 
not change the fact that charset is still deleted in the extant module.

--

___
Python tracker 

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

[issue27515] Dotted name re-import does not rebind after deletion

[R. David Murray]

R. David Murray added the comment:

Or, to put it another way, you deleted the charset attribute from the email 
module.  On the second import, import finds email in sys.modules, so it doesn't 
reimport it, so charset doesn't get recreated.  So, the difference is you 
didn't do 'del email'.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue27515] Dotted name re-import does not rebind after deletion

[Guido van Rossum]

Guido van Rossum added the comment:

I don't think this is a bug. You're paraphrasing step 2 incorrectly. The local 
name-binding behavior just creates a local named "email" -- it doesn't concern 
itself with ensuring that the email package has an attribute "charset". That 
attribute is set as a side effect of *loading* the charset submodule, not as a 
side effect of every import statement.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue25958] Implicit ABCs have no means of "anti-registration"

[Ivan Levkivskyi]

Ivan Levkivskyi added the comment:

What holds back this issue now?

It looks like Andrew did a great job.
When I was making a patch for #25987 following Andrew's ideas, I was surprised 
how many different idioms has been used for __subclasshook__.
I was going to open an issue on this, when I noticed a week ago that there is 
already this issue.

Is any help needed here?

--

___
Python tracker 

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

[issue27515] Dotted name re-import does not rebind after deletion

[Terry J. Reedy]

New submission from Terry J. Reedy:

https://docs.python.org/3/reference/simple_stmts.html#the-import-statement says 
that import , where  can optionally be a dotted name referring 
to a module within a package, does two things:

1. Find a module object corresponding to , creating it if necessary.
2. Bind the object to the name in the local namespace.  In short, 'import x' is 
shorthand for "x = __import__('x', ...)".

AFAIK, this works for simple names, including re-imports after name deletion.

>>> import email; email

>>> del email
>>> import email; email


However, the same is not true for dotted names.

>>> import email.charset; email.charset

>>> del email.charset
>>> import email.charset; email.charset
Traceback (most recent call last):
  File "", line 1, in 
import email.charset; email.charset
AttributeError: module 'email' has no attribute 'charset'

It appears that for dotted names, when step 1 is cut short by finding the 
cached module, step 2 is (improperly) omitted.  I consider this a bug in the 
code rather than the doc.  I think the name binding should not depend on how 
the module was found.  I don't know whether the bug is somewhere in importlib 
or in the core machinery that uses it.

This bug, in relation to tkinter package modues, prevented and AFAIK prevents 
me from fixing the bug of #25507 in 3.x versions prior to 3.6 (Tkinter in 2.x 
was not a package).  (For 3.6, I can and will refactor idlelib to eliminate the 
need for the deletion by preventing excess imports.)

--
components: Interpreter Core, Library (Lib)
messages: 270438
nosy: brett.cannon, eric.snow, ncoghlan, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Dotted name re-import does not rebind after deletion
type: behavior
versions: Python 2.7, 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

[issue27501] Add typing.py class describing a PEP 3118 buffer object

[Raymond Hettinger]

Raymond Hettinger added the comment:

Looking at the patch, I'm thinking that this endeavor isn't at all worthwhile.  
We don't need an ABC for everything especially if there in no pure python API 
involved.  I recommend closing this one until there is a proven need and a 
clear path forward.

--

___
Python tracker 

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

[issue27510] Found some Solution build missconfigurations.

[Decorater]

Decorater added the comment:

was targeting*

--

___
Python tracker 

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

[issue27510] Found some Solution build missconfigurations.

[Decorater]

Decorater added the comment:

Some parts rargenting win32 was having the solution set of 64 bit making x86 
with x64 setting mixups.
Basically it was doing both 32 and 64 bit assembling at the same time which of 
course would make it fail.

--

___
Python tracker 

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

[issue25393] 'resource' module documentation error

[Alakshendra Yadav]

Alakshendra Yadav added the comment:

It does seem that the mentioned line belongs under RLIMIT_STACK instead of 
RLIMIT_FSIZE. I am submitting a patch.

--
keywords: +patch
nosy: +Alakshendra Yadav
Added file: http://bugs.python.org/file43724/resource.patch

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Tim Peters]

Tim Peters added the comment:

About:  "The notion of categorically refusing to let a process end perhaps 
overreaches in certain situations."  threading.py addressed that all along:  if 
the programmer _wants_ the process to exit without waiting for a particular 
threading.Thread, that's fine, they ask the Thread constructor for a "daemon" 
thread.  Whether a threading.Thread does or doesn't prevent process exit before 
it's .join()'ed has always been the programmer's choice.  Python never 
attempted to guess their intent (except for "the main thread", which is 
necessarily non-daemonic).  That's why it's especially surprising that 
multiprocessing can silently overrule what had always been an explicit choice 
about process-exit threading.Thread behavior.

About compatibility, yup, that's potentially painful.  I will note that 
compability was already broken on Windows with no apparent angst, or subsequent 
complaints (the program in issue 27508 is an example:  "runs forever" under 
3.5.2 but "ends very quickly" under 2.7.11; "runs forever" is what the 
programmer wanted, matching how they expected non-daemon threading.Threads to 
work).

--

___
Python tracker 

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

[issue27377] Add smarter socket.fromfd()

[Neil Schemenauer]

Neil Schemenauer added the comment:

Tested on FreeBSD 10.3.  getsockname() on a IPPROTO_SCTP protocol socket 
returns errno = FileNoFoundError.  We could just comment out that test I guess.

My theory is that on FreeBSD, getsockname() on an SCTP socket fails if it is 
not bound.  Indeed, adding a bind(('127.0.0.1', 11234)) call before the 
fdtype() call makes the test pass.

--

___
Python tracker 

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

[issue24254] Make class definition namespace ordered by default

[Eric Snow]

Eric Snow added the comment:

FTR: PEP 520 "Preserving Class Attribute Definition Order" 
(https://www.python.org/dev/peps/pep-0520/)

--

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Xiang Zhang]

Xiang Zhang added the comment:

Thanks Brett, also others. Restore the moving around.

--
Added file: http://bugs.python.org/file43723/fix_fspath_crash_v3.patch

___
Python tracker 

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

[issue27377] Add smarter socket.fromfd()

[Neil Schemenauer]

Neil Schemenauer added the comment:

Updated patch, v5.  Disable fdtype() function on Windows.  Fix documentation 
nits as suggested by review of v4.

--
Added file: http://bugs.python.org/file43722/fromfd2_v5.txt

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Brett Cannon]

Brett Cannon added the comment:

The reordering of the tests is unnecessary. Because you both changed the code 
*and* moved a test you have to be very careful to notice the change, otherwise 
it just looks like you cut-and-pasted the code to another location. Had you 
left the test method where it was and just simplified the code then it would be 
very obvious what you changed and reviewing it would be much easier.

--
assignee:  -> brett.cannon

___
Python tracker 

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Brett Cannon]

Brett Cannon added the comment:

+1 from me

--

___
Python tracker 

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

[issue27377] Add smarter socket.fromfd()

[Neil Schemenauer]

Neil Schemenauer added the comment:

I just tested on Windows.  fdtype() fails with:
OSError: [WinError 10022] An invalid argument was supplied

The getsockname() call fails with WSAGetLastError() == 10022.  getsockname() is 
used to find the address family.  Perhaps there is some other way to get it on 
Windows.

The easiest fix would be to #ifdef MS_WINDOWS out the whole socket_fdtype() 
function.  Passing file descriptors around is not a thing on Windows anyhow.

There is still the issue of unexpected errors getting returned inside fdtype() 
(e.g. as suggested by Martin).  One idea is to commit the code as is and fix 
errors as they appear.

--

___
Python tracker 

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

[issue27513] email.utils.getaddresses does not handle Header objects

[R. David Murray]

R. David Murray added the comment:

This appears to be something that was overlooked when btyes support was added 
in 3.2.  getaddresses should indeed be able to handle a Header object if handed 
one.

--
title: email.utils.getaddresses raises exception from erroneous message get_all 
input -> email.utils.getaddresses does not handle Header objects
versions: +Python 3.5, Python 3.6 -Python 3.4

___
Python tracker 

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

[issue20842] pkgutil docs should reference glossary terms not PEP 302

[Jaysinh shukla]

Jaysinh shukla added the comment:

Adding updated patch after merging Issue 26896. Requesting to review. Thanks!

--
Added file: http://bugs.python.org/file43721/issue20842_v2.diff

___
Python tracker 

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

[issue23722] During metaclass.__init__, super() of the constructed class does not work

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue14977] mailcap does not respect precedence in the presence of wildcards

[R. David Murray]

R. David Murray added the comment:

I think a doc update is probably worthwhile, but I haven't looked at the docs 
so I'm not sure.

I'll try to give this a complete review this weekend, though I'm a bit busy so 
it may not happen.

--

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[R. David Murray]

R. David Murray added the comment:

As far as muliprocessing's "mentality" goes, it aims to provide the *same* API 
as Threading, so it is logical that it should preserve threading's behavior 
with respect to child threads in a process, rather than violating threading's 
model.  Anything else is counter-intuitive to a python programmer, as 
demonstrated by this issue and Tim's comments :)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[R. David Murray]

R. David Murray added the comment:

Note, however, that fixing this will be a backward compatibility issue, since 
there are doubtless programs relying on this behavior, probably mostly 
unintentionally.

--

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Xiang Zhang]

Xiang Zhang added the comment:

I have to explain for myself.

First, I know tests *are* important. This is not the first time
uploading patches here. I don't want to add tests for this case
is because such codes: call something and test for failure appears
all the places in the code base. This case is nothing special. For
this reason, I think simply add the missing code back is enough.
But then Serhiy presents his opinion that some test cases should be
added, I think it's quite reasonable because it's testing the whole
fspath behaviour, not just this case.

Second, maybe I cannot agree with your opinions in your last message.
I think changes are welcome if they *are* reasonable. The unreasonable
aspects including what you have stated. For this patch, I don't know
which part is unreasonable. Moving test_fsencode_fsdecode after
test_pathlike makes the first 3 tests test for valid arguments.
Extracting bad pathlike tests into a single test does not sounds like
a bad idea. And it's small, right? So it's not hard to figure out
what the change is made and what is actually changed.

--

___
Python tracker 

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

[issue25144] 3.5 Win install fails with "TARGETDIR"

[Futur Fusionneur]

Futur Fusionneur added the comment:

For me the custom installer worked by combining the two solutions above:

1. open an elevated command prompt
2. run the installer by specifying the TargetDir

--
nosy: +Futur Fusionneur

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Eryk Sun]

Eryk Sun added the comment:

> all atexit handlers, for example, would be called multiple times.

Davin is (I think) proposing a multiprocessing atexit facility, which can be 
used to ensure threading._shutdown is called. But could Python's regular atexit 
handling be reset in the child, allowing Py_Finalize to be called? In other 
words, can atexit can be integrated into the PyOS_AfterFork 
(Modules/signalmodule.c) sequence? multiprocessing could set a sys flag that 
forces atexit to clear its registered handlers, and for Py_AtExit, reset the 
static nexitfuncs variable in Python/pylifecycle.c. Or is that just opening a 
can of worms that will cause Py_Finalize to crash in various scenarios?

> There's also the problem that fork() isn't MT-safe

This issue is about joining Python threads created in the child, which has a 
clean slate via PyOS_AfterFork, PyEval_ReInitThreads (Python/ceval.c), and 
threading._after_fork.

--

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Ethan Furman]

Ethan Furman added the comment:

> I think such omissions are hard to predict and you won't know where is
> the omission until you encounter it. So if you don't know, how do you
> know what to put in the tests?

True.

> And if it is encountered and fixed, such errors should not happen again.

False.

Such errors *will* happen again -- they are called regressions.  In order to 
avoid those we add tests, and those tests serve several purposes:

- confirm the problem has been fixed (not every bug is a core-dump)
- confirm that changes in the future don't reintroduce the bug
- communicate past difficulties and possible gotchas to new developers

In short:  add tests; patches are not complete without them.

--

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Ethan Furman]

Ethan Furman added the comment:

> I ... reorganize the existing tests a little.

Please don't.

Moving tests around makes it harder for reviewers to see what
actually changed.

Rewriting tests to do the same thing as before also takes more
work from reviewers as we have to verify the new code does the
same as the old code, and then wonder why the change was made.

--

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Davin Potts]

Davin Potts added the comment:

Tim:  Totally agreed about threading.Thread not being a POSIX thread.  It was 
not my intent to suggest that they were equivalent -- apologies for the 
confusion.

Instead I was attempting to describe a mentality of processes and their common 
behavior across multiple platforms at termination.  The behavior of child 
processes via multiprocessing currently appears to follow this common mentality 
of signal the threads then exit quickly.  (To avoid confusion, I am making an 
observation here.)

Whereas threading.Thread is attempting to provide something homogeneous across 
platforms, achieving a similar goal in multiprocessing.Process is complicated 
by the concepts of fork vs. spawn and their availability on various OSes (a 
source of real confusion for some).  This further opens the question of what 
should the mentality be for multiprocessing.Process?  The notion that a process 
can die in such a way that not all of its threads were given time to clean up 
does not strike me as a foreign concept.  The notion that a threading.Thread 
should always be (or at least be attempted to be) joined makes sense.  The 
notion of categorically refusing to let a process end perhaps overreaches in 
certain situations.

I believe the more general solution exists in offering atexit handlers on 
multiprocessing.Process.

--

___
Python tracker 

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

[issue18858] dummy_threading lacks threading.get_ident() equivalent

[Berker Peksag]

Berker Peksag added the comment:

> This patch adds a test but does not fix the bug.

I forgot to explain what the first patch does. The specific problem reported by 
OP has already been fixed in default branch (but not in 3.5) so issue18858.diff 
was added a test to make sure that threading and dummy_threading API are in 
sync.

dummy_threading.currentThread() and dummy_threading.activeCount() still don't 
work in both 3.5 and default branches so we basically need two different 
patches. I'm attaching a patch for 3.5.

--
stage: needs patch -> patch review
Added file: http://bugs.python.org/file43720/issue18858_v2.diff

___
Python tracker 

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

[issue13312] test_time fails: strftime('%Y', y) for negative year

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue27510] Found some Solution build missconfigurations.

[Steve Dower]

Steve Dower added the comment:

I believe changes to the batch build dialog are local to your machine, so there 
won't be any changes to the solution file.

A regular build should include all packages. Can you explain what didn't work 
and why you needed to fix it?

--

___
Python tracker 

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

[issue27501] Add typing.py class describing a PEP 3118 buffer object

[Daniel Moisset]

Daniel Moisset added the comment:

As a description of the idea I'm attaching a rough patch with an 
implementation. Some tests fail because of the following:

1) I didn't find a good place to register the Buffer ABC for mmap.mmap, and 
array.mmap; the modeules themselves are C extensions (and it's possible but 
weird to register the ABC from the C API); I could import those in typing.py 
but then I'd make typing depend from mmap and array which also feels wrong; so 
I didn't do that and the related tests that I added fail.

2) I had a similar situation with io.BytesIO. In that case there's a python 
module and I'm doing the abc.register there, but now io imports typing, and the 
test_site fails because many new modules (typing and its dependencies) are 
imported on startup. The alternative is to make typing depend on io (in this 
case it could be a reasonable idea)

After these, I'm feeling that typing.py may not be the best place for this (but 
given that collections.abc isn't either, I'm not sure where's the right place)

--
keywords: +patch
Added file: http://bugs.python.org/file43719/buffer.patch

___
Python tracker 

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

[issue27392] Add a server_side keyword parameter to create_connection

[Jim Fulton]

Jim Fulton added the comment:

Here's a daft doc update.

--
keywords: +patch
Added file: http://bugs.python.org/file43718/connect_accepted_socket-doc.patch

___
Python tracker 

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

[issue27514] SystemError when compiling deeply nested for loops

[Nick Coghlan]

Nick Coghlan added the comment:

+1 for Serhiy's recommendation. It's OK for the compiler to say "Don't do 
that", but the correct error is SyntaxError, even when it's a limitation later 
in the code generation pipeline (rather than failing to comply with the 
language grammar)

--

___
Python tracker 

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

[issue27514] SystemError when compiling deeply nested for loops

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

There is a static limit for the number of statically nested blocks. Getting rid 
of this limit looks not easy.

But SystemError is not an exception that should be raised. SystemError is for 
errors that can't be occurred in normal case. It should only be caused by 
incorrect use of C API or hacking Python internals. I think SyntaxError is more 
appropriate in this case (as in case of passing more than 255 arguments to a 
function).

--
stage:  -> needs patch
versions: +Python 3.5, Python 3.6

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Xiang Zhang]

Xiang Zhang added the comment:

The test requests for the whole fspath are reasonable. I just don't want to add 
tests for these two lines.

1) and 3) have already been tested. I add 2) and reorganize the existing tests 
a little.

--
Added file: http://bugs.python.org/file43717/fix_fspath_crash_v2.patch

___
Python tracker 

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

[issue25733] Code and IDLE should catch all compile errors.

[ppperry]

ppperry added the comment:

>SystemError is serious bug. Please open separate issue for this.

Done. I created issue27514

--

___
Python tracker 

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

[issue27514] SystemError when compiling deeply nested for loops

[ppperry]

New submission from ppperry:

The following code:
for a in range(26):
  for b in range(26):
   for c in range(26):
for d in range(26):
 for e in range(26):
  for f in range(26):
   for g in range(26):
for h in range(26):
 for i in range(26):
  for j in range(26):
   for k in range(26):
for l in range(26):
 for m in range(26):
  for o in range(26):
   for p in range(26):
for q in range(26):
 for r in range(26):
  for s in range(26):
   for t in range(26):
for u in range(26):
 for v in range(26):
   for w in range(26):
 pass
fails to compile with `SystemError:too many statically nested blocks`, which 
was described as a serious bug in issue27081.

--
components: Interpreter Core
messages: 270405
nosy: benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, ppperry, 
serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: SystemError when compiling deeply nested for loops
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

[issue27497] csv module: Add return value to DictWriter.writeheader

[STINNER Victor]

STINNER Victor added the comment:

I'm now ok to add the return, but only in Python 3.6. It would be a minor new 
"feature".

--

___
Python tracker 

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

[issue27510] Found some Solution build missconfigurations.

[Emanuel Barry]

Emanuel Barry added the comment:

Please submit a patch file (see https://docs.python.org/devguide/patch.html ).

--
nosy: +ebarry
stage:  -> needs patch

___
Python tracker 

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

[issue26579] Support pickling slots in subclasses of common classes

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

An alternative way is to expose a default state as object.__getstate__(). It is 
more efficient since it is implemented in C. Following patch implements this 
approach.

--
Added file: http://bugs.python.org/file43716/object_getstate.patch

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think should be tests for following cases:

1) __fspath__ doesn't exist;
2) __fspath__ is not callable or calling __fspath__() raises an exception;
3) the result of __fspath__() is not valid (wrong type).

--

___
Python tracker 

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

[issue27513] email.utils.getaddresses raises exception from erroneous message get_all input

[Hans-Peter Jansen]

Hans-Peter Jansen added the comment:

message.get cannot decode the header correctly, and returns a Header instance 
instead, which makes email.utils.getaddresses stumble upon...

A much better behavior for getaddresses in this case would be returning the 
perfectly valid address, and ignoring the invalid dtext part.

--
Added file: http://bugs.python.org/file43715/decode_from_header.py

___
Python tracker 

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

[issue27507] bytearray.extend lacks overflow check when increasing buffer

[Xiang Zhang]

Xiang Zhang added the comment:

Thanks for the analysis Antti. I don't think if (len == PY_SSIZE_T_MAX) can be 
moved inside the *other* if. Their handlings are different. if (len == 
PY_SSIZE_T_MAX) is True, it should exit immediately. But in the *other* if, you 
can still have a try to allocate PY_SSIZE_T_MAX memory. 

As for your overflow macro, I think it's not very useful. First, not only 
Py_ssize_t can overflow, all signed types can. So a single 
SUM_OVERFLOWS_PY_SSIZE_T is not enough. Second, current overflow check pattern 
like a > PY_SSIZE_T_MAX - b is very obvious in my opinion.

--

___
Python tracker 

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

[issue27513] email.utils.getaddresses raises exception from erroneous message get_all input

[Hans-Peter Jansen]

New submission from Hans-Peter Jansen:

An unfortunate combination of get_all and getaddresses results in a Traceback:

Traceback (most recent call last):
  File "misc/decode_from_header.py", line 17, in 
print('From: %s' % email.utils.getaddresses(val))
  File "/usr/lib64/python3.4/email/utils.py", line 112, in getaddresses
all = COMMASPACE.join(fieldvalues)
TypeError: sequence item 0: expected str instance, Header found

Here's the relevant part of it:
Content-type: text/html;charset=iso-8859-1
From: Itaú Uniclass. 

Obviously, the From header is iso-8859-1 encoded as well, and violates RFC 2822 
as such. But making it crash in the usual combination of

val = msg.get('from')
email.utils.getaddresses([val])

isn't the real McCoy either..

--
components: email
files: iso-8859-1-encoded-from-header.mail
messages: 270399
nosy: barry, frispete, r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.getaddresses raises exception from erroneous message get_all 
input
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file43714/iso-8859-1-encoded-from-header.mail

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Xiang Zhang]

Xiang Zhang added the comment:

I think such omissions are hard to predict and you won't know where is the 
omission until you encounter it. So if you don't know, how do you know what to 
put in the tests? And if it is encountered and fixed, such errors should not 
happen again.

--

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Antti Haapala]

Antti Haapala added the comment:

I believe tests is that they should *especially* be in place for any previously 
found "careless omissions". If it has been done before, who is to say that it 
wouldn't happen again?

--
nosy: +ztane

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Decorater]

Decorater added the comment:

nevermind the above traceback from it is a issue with the code that makes it 
try to copy the redist file from the v14 C++ runtime.

--

___
Python tracker 

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

[issue27507] bytearray.extend lacks overflow check when increasing buffer

[Antti Haapala]

Antti Haapala added the comment:

if (len == PY_SSIZE_T_MAX) is necessary for the case that the iterable is 
already PY_SSIZE_T_MAX items. However it could be moved inside the *other* if 
because if (len == PY_SSIZE_T_MAX) should also fail the overflow check.

However, I believe it is theoretical at most with stuff that Python supports 
that it would even be possible to allocate an array of PY_SSIZE_T_MAX 
*pointers*. The reason is that the maximum size of object can be only that of 
`size_t`, and Py_ssize_t should be a signed type of that size; and it would 
thus be possible only to allocate an array of PY_SSIZE_T_MAX pointers only if 
they're 16 bits wide.

In any case, this would be another place where my proposed macro 
"SUM_OVERFLOWS_PY_SSIZE_T" or something would be in order to make it read

if (SUM_OVERFLOWS_PY_SSIZE_T(len, (len >> 1) + 1)

which would make it easier to spot mistakes in the sign preceding 1.

--
nosy: +ztane

___
Python tracker 

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

[issue27507] bytearray.extend lacks overflow check when increasing buffer

[Xiang Zhang]

Xiang Zhang added the comment:

So would you like to merge it like this or Martin's alternative way? But 
honestly speaking I don't get Martin's point, "without trying to allocate 
Py_SSIZE_T_MAX first", where is this place?

--

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Decorater]

Decorater added the comment:

This does also happen in make_zip too as it does not known about the current 
changes. https://bpaste.net/show/ff826604a5f0

--
nosy: +Decorater

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Xiang Zhang]

Xiang Zhang added the comment:

Ahh, adding tests is easy. But this seems to be just a careless omission, so 
maybe tests is not a must.

--

___
Python tracker 

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

[issue27507] bytearray.extend lacks overflow check when increasing buffer

[Decorater]

Changes by Decorater :


--
nosy: +Decorater

___
Python tracker 

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

[issue27507] bytearray.extend lacks overflow check when increasing buffer

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Totally agreed with Martin.

--

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Could you add tests?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue27497] csv module: Add return value to DictWriter.writeheader

[Logan]

Logan added the comment:

@berker.peksag: Good catch, thank you.  In my code base I'm using a slightly 
different implementation which does use an iterator, so I didn't even catch 
that the default django example was incorrect.

@skip.montanaro: That is exactly the one-liner I'm currently using.  Thank you 
for documenting it here in case anyone else is looking for the same.

--

___
Python tracker 

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

[issue27497] csv module: Add return value to DictWriter.writeheader

[Skip Montanaro]

Skip Montanaro added the comment:

I agree writeheader() should have returned the value of writerow(), but have no 
opinion on the more esoteric stuff you're discussing. I think you could argue 
that adding the "return" would be a bug fix.

Personally, I long ago got in the habit of using the writerow(dict(zip(fh, 
fh))) idiom, didn't catch on at the time that writeheader() was even available 
in 2.7, and still just use the idiom most of the time. It's a one-liner. The OP 
could easily use that in contexts where writeheader() doesn't do the right 
thing.

--

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Xiang Zhang]

Xiang Zhang added the comment:

BTW, the code is also listed in PEP519. So maybe that also needs to be fixed.

--

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Xiang Zhang]

New submission from Xiang Zhang:

When any exception is raised inside __fspath__, operations involving it like 
os.fspath, open are certain to crash.

>>> import os
>>> class Test:
... def __fspath__(self):
... raise RuntimeError
... 
>>> os.fspath(Test())
Segmentation fault (core dumped)

Attach a patch to fix this.

--
components: Extension Modules
files: fix_fspath_crash.patch
keywords: patch
messages: 270386
nosy: brett.cannon, ethan.furman, xiang.zhang
priority: normal
severity: normal
status: open
title: os.fspath is certain to crash when exception raised in __fspath__
type: crash
versions: Python 3.6
Added file: http://bugs.python.org/file43713/fix_fspath_crash.patch

___
Python tracker 

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

[issue27511] Add PathLike objects support to BZ2File

[Xiang Zhang]

Changes by Xiang Zhang :


--
components: +Library (Lib)
type:  -> enhancement
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

[issue27511] Add PathLike objects support to BZ2File

[Xiang Zhang]

New submission from Xiang Zhang:

Attach a patch to add PathLike objects support to BZ2File.

--
files: add_PathLike_objects_support_to_BZ2File.patch
keywords: patch
messages: 270385
nosy: brett.cannon, ethan.furman, xiang.zhang
priority: normal
severity: normal
status: open
title: Add PathLike objects support to BZ2File
Added file: 
http://bugs.python.org/file43712/add_PathLike_objects_support_to_BZ2File.patch

___
Python tracker 

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

[issue27509] Some tests breaks PGO build on Windows

[Decorater]

Decorater added the comment:

Have you tried the 3.6 branch maybe it was fixed there.

--

___
Python tracker 

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

[issue27509] Some tests breaks PGO build on Windows

[Charles G.]

Charles G. added the comment:

Tried with Visual Studio Community 2015 Update 3 with same result.

--

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Charles-François Natali]

Charles-François Natali added the comment:

One reason for not calling sys.exit() is because on Linux, the default
implementation uses fork(), hence the address space in the chilren is
a clone of the parent: so all atexit handlers, for example, would be
called multiple times.
There's also the problem that fork() isn't MT-safe, making the
probability of screwups/deadlocks in various destructors/stack
unwinding greater.

--

___
Python tracker 

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Nick Coghlan]

Nick Coghlan added the comment:

+1 for the more verbose version, since that will tend to nudge folks towards 
.__init__ as the likely culprit (and that does seem to be the most 
likely way for this particular double-import scenario to arise.

Brett, does that resolution sound reasonable to you, too?

Martin, would you have time to put together a follow-up patch adding the 
warning? (If not, I should be able to make time for it)

--

___
Python tracker 

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

[issue27510] Found some Solution build missconfigurations.

[Decorater]

New submission from Decorater:

I went in and looked in the batch build list to find some missconfigurations 
So, I went in and selected the right ones that I can see  currently.

--
components: Build, Windows
files: pcbuild.sln
messages: 270380
nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Found some Solution build missconfigurations.
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file43711/pcbuild.sln

___
Python tracker 

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Wolfgang Maier]

Wolfgang Maier added the comment:

A warning like this sounds good to me though I'd prefer it to be slightly more 
verbose, like:

"RuntimeWarning: '' found in sys.modules after import of package 
'', but prior to execution of '' as '__main__'; this may 
result in unpredictable behaviour"

or it wouldn't really have helped me much to understand what was happening.

P.S.: You understood correctly that my own code is fixed (patch sent to the 
affected user, next release will have the fix). Learnt something about the 
whole __spec__ and double import subject along the way so it wasn't completely 
wasted time.

--

___
Python tracker 

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

[issue27509] Some tests breaks PGO build on Windows

[Charles G.]

Charles G. added the comment:

The compiler itself supports PGO in the Community Edition. I'm not sure about 
the IDE (not using it). Since I compiled python using the batch file (with 
msbuild) so it is not limited by the features of the IDE.

--

___
Python tracker 

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

[issue27509] Some tests breaks PGO build on Windows

[Charles G.]

Charles G. added the comment:

Community Edition. PGO is available in the Community Edition since at least VS 
2012.

--

___
Python tracker 

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

[issue27509] Some tests breaks PGO build on Windows

[Decorater]

Decorater added the comment:

What Edition of Visual Studio are you using? I am using Update 3 of 2015 
Community and PGO is only (as far as I am aware of) in the Ultimate Edition of 
Visual Studio.

--
nosy: +Decorater

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
stage:  -> needs patch
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.5

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Antoine Pitrou]

Antoine Pitrou added the comment:

I agree with Tim. Regardless of what OS threads do, Python tries to enforce 
predictable semantics of its own. There's no reason (apart from historical 
baggage) to not join Python threads (and only Python threads, of course, not 
other OS threads) at the shutdown of a child process.

I don't exactly remember why using os._exit() rather than sys.exit() is 
required in child processes. Presumably it is because we don't want the child 
to clobber any resources shared with the parent (open files?). This doesn't 
have to be a binary thing, though: it may as well be os._exit() + a bunch of 
cleanup steps we know are safe to perform.

--

___
Python tracker 

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

[issue27509] Some tests breaks PGO build on Windows

[Charles G.]

New submission from Charles G.:

Environment:
Python 3.5.2
Visual Studio 2015 Update 2
Windows 7
amd64

I tried to build python with pgo (build.bat --pgo) but found that no  
python35!1.pgc or python!1.pgc was created. Then I run the tests one by one 
while checking the existence of python35!1.pgc and found that these tests when 
run prevents above pgcs from being created:

test_concurrent_futures
test_faulthandler
test_multiprocessing_main_handling
test_multiprocessing_spawn
test_os
test_subprocess

I'm not sure of the reason why no pgc is produced when running these tests.

--
components: Windows
messages: 270374
nosy: Charles G., paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Some tests breaks PGO build on Windows
type: compile error
versions: Python 3.5

___
Python tracker 

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