[issue35979] Incorrect __text_signature__ for the __get__ slot wrapper

[SilentGhost]

SilentGhost  added the comment:

Is it not? This seems to be doing exactly what's intended. If you have a 
reproducible bug trigger, please post it, but I'll close the issue in the 
meantime.

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

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

[SilentGhost]

Change by SilentGhost :


--
resolution:  -> not a bug

___
Python tracker 

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

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

[Mark Dickinson]

Mark Dickinson  added the comment:

Closing as requested by OP.

--
nosy: +mark.dickinson
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

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee:  -> rhettinger

___
Python tracker 

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

[issue35500] Align expected and actual calls on mock.assert_called_with error message

[Susan Su]

Susan Su  added the comment:

After taking a look at the assert_called_with function, I noticed that the 
formatting is inconsistent for the following case:
from unittest import mock

m = mock.Mock()
a = [1, 2, 3, 4]
m.assert_called_with(*a)
Traceback (most recent call last):
  File "", line 1, in 
  File "/vagrant/cpython/Lib/unittest/mock.py", line 817, in assert_called_with
raise AssertionError('Expected call: %s\nNot called' % (expected,))
AssertionError: Expected call: mock(1, 2, 3)
Not called


If you believe it would be appropriate, I would like to change the format of 
the code above to the following:

Traceback (most recent call last):
  File "", line 1, in 
  File "/vagrant/cpython/Lib/unittest/mock.py", line 817, in assert_called_with
raise AssertionError(
AssertionError: expected call not found.
Expected: mock(1, 2, 3, 4)
Not called

This way, we would create consistency in our output.

--
nosy: +suhearsawho

___
Python tracker 

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

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

[shawnberry]

shawnberry  added the comment:

Hi PSF,

Upon further review, random.choices() is O(N).  I was looping through the
values in random.choices() to make it O(N**2) in my code.

Next time I will thoroughly check a function on its own before raising any
issue.  Fyi, BIF is built-in function.  Please close this issue.

Best,
Shawn

On Tue, Feb 12, 2019 at 5:45 PM Steven D'Aprano 
wrote:

>
> Steven D'Aprano  added the comment:
>
> What's "BIF" mean? You use that term multiple times but I have never heard
> it before.
>
> I'm sorry, I don't understand your code (and don't have time to study it
> in detail to decipher it). It would help if you factored out your new
> implementation of choices() into a separate function.
>
> I see that your timing code it not reliable for timing individual function
> calls. You include your setup code that builds the input to choices() as
> well as the time it takes to print messages, so we can't really draw any
> reliable conclusions about the speed of choices() from your timings.
>
> To give an analogy: you start the stopwatch at home. Climb into the shower
> and wash, get dressed, have breakfast, drive to work, park the car, buy a
> coffee at the shop next door, go to your office, greet your fellow
> co-workers, and finally stop the stopwatch. And then you say that the total
> time measured was the time it took you to drive to work alone.
>
> Finally, I can't actually work out what part of your code is intended as a
> replacement for the choices() function. You should factor it out into a
> separate function, then time the two function calls:
>
> choices(dataset, weights)
> shawn_choices(dataset, weights)
>
> alone (without timing the setup of the datasets, or the I/O, or any other
> irrelevant costs). You probably should use the timeit module for the actual
> timing.
>
> As for the versions of Python, 3.6 and older are in "bug fix only" mode,
> so this will not apply to anything older than 3.7.
>
> --
> nosy: +steven.daprano
> versions:  -Python 3.4, Python 3.5, Python 3.6
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue35981] shutil make_archive create wrong file when base name contains dots at end

[maokk]

New submission from maokk :

shutil.make_archive("foo...bar..", "zip", os.path.abspath("c:/test"))

create zipfile called "foo...bar.zip" not "foo...bar...zip"

--
components: Distutils
messages: 335388
nosy: dstufft, eric.araujo, highwind
priority: normal
severity: normal
status: open
title: shutil make_archive create wrong file when base name contains dots at end
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue21107] Add pgen.vcxproj to allow regenerating grammar files on Windows

[Zachary Ware]

Zachary Ware  added the comment:

This patch is *way* out of date, and we're in the midst of removing pgen 
(issue35808) anyway, so I'm closing this issue.

--
resolution:  -> out of date
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

[issue35121] Cookie domain check returns incorrect results

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This issue affects 2.7 as well along with 3.4 and 3.5. The initial report was 
notified to secur...@python.org . 2.7.16 release candidate dates were announced 
at https://mail.python.org/pipermail/python-dev/2019-February/156266.html. I 
have prepared an initial backport of this with tests for 2.7 at 
https://github.com/python/cpython/compare/2.7...tirkarthi:bpo35121-27 . Serhiy 
has approved the PR for master. I have added notes here and on the PR about the 
issue and implementation in other languages. It would be helpful if someone can 
double check my analysis since cookiejar has not received much change over the 
years.

If this is a potential candidate for 2.7 release I can help with that once the 
changes are merged to master. Adding Benjamin Peterson to this issue to take a 
call on if it needs to be backported to 2.7. If it's planned for a backport 
then also to decide on priority if this needs to be part of 2.7.16 or later 
release.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue35927] Intra-package References Documentation Incomplete

[Terry J. Reedy]

Terry J. Reedy  added the comment:

AData> You log and output show that you problem is as described: package 
'sound' is in directory "C:/" and "C:/" is not is sys.path.  Possible remedies:
1. Add "C:/" to sys.path at the top of each module that imports sound.  This is 
a nuisance.
2. Move the sound package to 
'C:\\Users\\user\\AppData\\Local\\Programs\\Python\\Python37\\lib\\site-packages'.
  This can also a nuisance.
3. Add a file named 'C.pth' and containing "C:/" to the site-packages.  ('pth' 
abbreviates 'path'.)  This makes C:/ an extension of site-packages.  But all 
the non-python stuff in C: likely makes this a bad idea.
4 (3 improved). Add a directory such as "C:/pyprojects", make the contents of 
the .pth file "C:/pyprojects", and move sound to pyprojects.  
This is what I have done.  When I install a new version of Python, I copy the 
.pth file to the new site-packeges directory.  Works great.

--

___
Python tracker 

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

[issue35975] Put back the ability to parse files where async/await aren't keywords

[Guido van Rossum]

Change by Guido van Rossum :


--
assignee:  -> gvanrossum
components: +Interpreter Core
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.8

___
Python tracker 

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

[issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed.

[Guido van Rossum]

Guido van Rossum  added the comment:

Fixed by b9d2e97601847a1845bf96e2895a6214f02b92a6 (GH-11832).

--
nosy: +pablogsal
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue35155] Clarify Protocol Handlers in urllib.request Docs

[Terry J. Reedy]

Terry J. Reedy  added the comment:

unittest is another module with half-fixed and half-variable names.  The 
default (glob) pattern for test module names is given as "test*.py".  The fixed 
pattern for test methods is given as "starts with 'test'".  This could have 
been given, I believe, as re "test/w*", but it wasn't.  The former is clearer 
for more people.  So no guidance there.

I agree that we should follow the 2 precedents. Thank you both.

--

___
Python tracker 

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

[issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments

[Michael Sullivan]

Change by Michael Sullivan :


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

___
Python tracker 

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

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

[Steven D'Aprano]

Steven D'Aprano  added the comment:

What's "BIF" mean? You use that term multiple times but I have never heard it 
before.

I'm sorry, I don't understand your code (and don't have time to study it in 
detail to decipher it). It would help if you factored out your new 
implementation of choices() into a separate function.

I see that your timing code it not reliable for timing individual function 
calls. You include your setup code that builds the input to choices() as well 
as the time it takes to print messages, so we can't really draw any reliable 
conclusions about the speed of choices() from your timings.

To give an analogy: you start the stopwatch at home. Climb into the shower and 
wash, get dressed, have breakfast, drive to work, park the car, buy a coffee at 
the shop next door, go to your office, greet your fellow co-workers, and 
finally stop the stopwatch. And then you say that the total time measured was 
the time it took you to drive to work alone.

Finally, I can't actually work out what part of your code is intended as a 
replacement for the choices() function. You should factor it out into a 
separate function, then time the two function calls:

choices(dataset, weights)
shawn_choices(dataset, weights)

alone (without timing the setup of the datasets, or the I/O, or any other 
irrelevant costs). You probably should use the timeit module for the actual 
timing.

As for the versions of Python, 3.6 and older are in "bug fix only" mode, so 
this will not apply to anything older than 3.7.

--
nosy: +steven.daprano
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

[issue35962] Slight error in words in [ 2.4.1. String and Bytes literals ]

[Cheryl Sabella]

Change by Cheryl Sabella :


--
nosy: +ncoghlan
versions: +Python 3.8

___
Python tracker 

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

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

[Emmanuel Arias]

Change by Emmanuel Arias :


--
nosy: +eamanu

___
Python tracker 

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

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

[Ammar Askar]

Ammar Askar  added the comment:

I can't speak to the complexity of the choices function but if you're proposing 
an alternative implementation for choices, it would be wise to show the 
benefits empirically. That is, benchmarks and an explanation of why your 
implementation would be better than just an example of your code among an 
example. Additionally, you need to expand your implementation to match all the 
functionality of the current function and make a pull request to the main 
Python repository.

Adding Raymond to nosy, the original author of random.choices

--
nosy: +ammar2, rhettinger

___
Python tracker 

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

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

[Emmanuel Arias]

Emmanuel Arias  added the comment:

> Otherwise I'd say it would be nice to refactor in such a way that avoids the 
> core dump when the problem is on the Python side 

I agree with @p-ganssle, If exist some problem on initialize Python interpreter 
it would be great if it return a non-zero status and avoid an abort()

+ Python3.5. I test it and has the same result.

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

[issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task

[shawnberry]

New submission from shawnberry :

Please see my GitHub page 
https://github.com/shawnberry/Improved_random.choices/blob/master/Improved_Py3_BIF_random_dot_choices.py
for code that reduces Py3 BIF random.choices() from O(N**2) to O(N).
This is my first suggestion to improve Python code.
Thanks,
shawnberry...@gmail.com

--
components: Library (Lib)
files: Improved_Py3_BIF_random_dot_choices.py
hgrepos: 380
messages: 335379
nosy: shawn_berry
priority: normal
severity: normal
status: open
title: Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the 
same task
type: performance
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: 
https://bugs.python.org/file48135/Improved_Py3_BIF_random_dot_choices.py

___
Python tracker 

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

[issue35979] Incorrect __text_signature__ for the __get__ slot wrapper

[Dan Snider]

New submission from Dan Snider :

The current signature:

"__get__($self, instance, owner, /)\n--\n\nReturn an attribute of instance, 
which is of type owner."

doens't match how wrap_descr_get actually parses the arguments to __get__ with:

PyArg_UnpackTuple(args, "", 1, 2, , )

--
messages: 335378
nosy: bup
priority: normal
severity: normal
status: open
title: Incorrect __text_signature__ for the __get__ slot wrapper

___
Python tracker 

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

[issue35951] os.renames() creates directories if original name doesn't exist

[Chris Jerdonek]

Chris Jerdonek  added the comment:

> As such the cleanup in case of failure should not be expected,

Given that the documentation specifically calls out permissions errors as a 
cause of leaving the new directory in place, it wouldn't be unreasonable for 
someone to think the function does a cleanup step on failure using the same 
pruning process on the target directory.

In fact, that scenario is the one scenario I can think of that makes how the 
note is written make sense -- the cleanup step not having permissions to remove 
the intermediate directories it just created ("This function can fail with the 
new directory structure made if you lack permissions needed to remove the leaf 
directory or file [just created]").

--

___
Python tracker 

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

[issue32810] Expose ags_gen and agt_gen in asynchronous generators

[Joshua Oreman]

Joshua Oreman  added the comment:

I also ran into this. My workaround was to use gc.get_referents() on the 
async_generator_asend object, which returns a one-element list containing the 
async generator object. I don't know if this is guaranteed or just happened to 
work in the cases I was using it, but it might be good enough?

--
nosy: +Joshua Oreman

___
Python tracker 

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

[issue26415] Excessive peak memory consumption by the Python parser

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
nosy: +pablogsal

___
Python tracker 

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

[issue21360] mailbox.Maildir should ignore files named with a leading dot

[Zackery Spytz]

Zackery Spytz  added the comment:

I've created a PR for this issue.

--
nosy: +ZackerySpytz
versions: +Python 3.7, Python 3.8

___
Python tracker 

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

[issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed.

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue35936] Give modulefinder some much-needed updates.

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +barry, brett.cannon, ncoghlan

___
Python tracker 

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

[issue35951] os.renames() creates directories if original name doesn't exist

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

The proposed change makes the problem a lot less likely to occur, but 
technically it doesn't fix it because if the src file/dir disappears between 
"os.path.exists(src)" and os.rename(src, dst)" calls you'll end up with a race 
condition. We may still want to do it, but can't make promises about full 
reliability.

Also, it seems to me this behavior should be expected, because the doc explains 
the whole thing basically happens as a 3-step process (create dst dirs, rename, 
remove old src path). As such the cleanup in case of failure should not be 
expected, nor is promised. Also, FileNotFoundError is just one. os.rename() may 
fail for other reasons (and still leave the dst directory tree behind). If 
there is something we can do here is probably make the doc more clear (it talks 
about "lack of permissions" when instead it should have talked on "any error".

Extra (unrelated): as I commented on the PR, there are no unit-tests for 
os.renames().

--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue35155] Clarify Protocol Handlers in urllib.request Docs

[Cheryl Sabella]

Cheryl Sabella  added the comment:

I don't think there is anything specifically defined for a placeholder.  
However, looking at the current urllib.request documentation, there are 2 
places that use the ``_`` method for a placeholder - .proxy and 
.proxy, with the latter explaining what  means.

> By default, ProxyHandler uses the environment variables named _proxy, 
> where  is the URL scheme involved.

That line was added by Georg Brandl (granted it was part of converting all the 
docs), which would lead me to believe that is the accepted way to do it.

Also, the argument clinic how-to has the following:
> The length of the string will be passed in to the impl function, just after 
> the string parameter, as a parameter named ``_length``.

I'll make a comment on the PR too.

--

___
Python tracker 

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

[issue35967] Better platform.processor support

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Your proposal sounds fine to me.  You could fall back on platform.machine() 
instead of calling `uname` explicitly.

--
nosy: +pitrou

___
Python tracker 

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

[issue35155] Clarify Protocol Handlers in urllib.request Docs

[Matthew Barnett]

Matthew Barnett  added the comment:

You could italicise the "protocol" part using asterisks, like this:

*protocol*_request

or this:

*protocol*\ _request

depending on the implementation of the rst software.

--
nosy: +mrabarnett

___
Python tracker 

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

[issue35810] Object Initialization does not incref Heap-allocated Types

[Stefan Behnel]

Stefan Behnel  added the comment:

Adding Christian Tismer to the nosy list since he might be able to elaborate on 
the impact on PySide (which IIRC uses the stable ABI, and thus, heap types).

--
components: +Extension Modules, Interpreter Core -Library (Lib)
nosy: +Christian.Tismer
title: Object Initialization Bug with Heap-allocated Types -> Object 
Initialization does not incref Heap-allocated Types
type:  -> behavior

___
Python tracker 

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

[issue35505] Test test_imaplib fail in test_imap4_host_default_value

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Matěj Cepl for the fix and thanks Petr Stupka for the bug report ;-)

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue35810] Object Initialization Bug with Heap-allocated Types

[Eddie Elizondo]

Eddie Elizondo  added the comment:

Now, with that in mind - can you guys point me to the right thing to do now - 
how can we move this forward? :) 

* Should I write something up in python-dev/Discourse?
* Do I need to update the PY_VERSION_HEX?
* Do I need to write an entry in the Porting guide?

Let me know what you think!

--

___
Python tracker 

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

[issue35810] Object Initialization Bug with Heap-allocated Types

[Eddie Elizondo]

Eddie Elizondo  added the comment:

Thanks for the thorough feedback Stefan!

I would like to just add an extra thing to everything you already mentioned: 

This change will NEVER cause a crash. The change that we are introducing is an 
incref to a type object (no decrefs). Thus, there are two-ish scenarios:

1) The type object is immortal: This means that the type does not incref/decref 
its refcount automatically on instance creation. Adding this incref will not 
affect the fact that it's already immortal. An example of this is 
structsequences. The change that I added in the PR is to convert it to an 
refcounted type (instead of immortal).

2.1) The type is recounted (automatically): Achieved through the generic 
allocation which already increfs the type. Given that this refactors that 
incref, then this behavior should stay exactly the same.

2.2) The type is refcounted (manually): Achieved by not using the generic 
allocation and instead using `PyObject_{,GC}_New{Var}`. To properly refcount 
this type, a manual incref is required after object instantiation. Usually, 
I've seen this pattern in very carefully engineered types where a NULL is 
jammed into `tp_new` to make it into a non-instantiable type. Examples of this 
are Modules/_tkinter.c and Modules/_curses_panel.c. Anyways, adding this incref 
will leak this type, but will not cause a crash.

--

___
Python tracker 

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

[issue35813] shared memory construct to avoid need for serialization between processes

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> SharedMemoryManager does not subclass SyncManager but it did previously.

Ah, right.  Then it's ok to change the tests IMO.

--

___
Python tracker 

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

[issue35155] Clarify Protocol Handlers in urllib.request Docs

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Cheryl, you know rst better than me.  Is there any markup to indicate that a 
word is a placeholder, not meant to be taken literally?  Or is Denton's 
'' instead of 'placeholder' the best choice? See the PR and answer 
there.

--
nosy: +cheryl.sabella, orsenthil, terry.reedy
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

[issue35978] test_venv fails in Travis with GCC

[STINNER Victor]

STINNER Victor  added the comment:

Hum, test_executable() of test_venv is skipped if run in a venv, but not 
test_multiprocessing():

# If a venv is created from a source build and that venv is used to
# run the test, the pyvenv.cfg in the venv created in the test will
# point to the venv being used to run the test, and we lose the link
# to the source build - so Python can't initialise properly.
@skipInVenv
...
self.run_with_capture(venv.create, self.env_dir)
envpy = os.path.join(os.path.realpath(self.env_dir),
 self.bindir, self.exe)
...

def test_multiprocessing(self):
...
self.run_with_capture(venv.create, self.env_dir)
envpy = os.path.join(os.path.realpath(self.env_dir),
 self.bindir, self.exe)
...

The test has been added by:

commit 4e02f8f8b4baab63f927cfd87b401200ba2969e9
Author: Steve Dower 
Date:   Fri Jan 25 14:59:12 2019 -0800

--
nosy: +steve.dower

___
Python tracker 

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

[issue35978] test_venv fails in Travis with GCC

[STINNER Victor]

STINNER Victor  added the comment:

The Python of the virtual environment created by the test doesn't work:

$ /tmp/tmp0vybyos2/bin/python -c pass
Could not find platform independent libraries 
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
Fatal Python error: initfsencoding: failed to get the Python codec of the 
filesystem encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x7f2956ab8740 (most recent call first):
Aborted

--

___
Python tracker 

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

[issue35813] shared memory construct to avoid need for serialization between processes

[Davin Potts]

Davin Potts  added the comment:

@Antoine:  SharedMemoryManager does not subclass SyncManager but it did 
previously.  This is the source of the confusion.  SharedMemoryManager 
subclasses BaseManager which does not provide Value, Array, list, dict, etc.

Agreed that the manager facility does not appear to see that much use in 
existing code.

When working with shared memory, I expect SharedMemoryManager to be much more 
popular.

--

___
Python tracker 

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

[issue35978] test_venv fails in Travis with GCC

[STINNER Victor]

STINNER Victor  added the comment:

I can reproduce the crash using the same command than the job.

Simplified commands to reproduce the bug:

./configure && make
./python -m venv venv
./venv/bin/python -m test test_venv -m 
test.test_venv.BasicTest.test_multiprocessing

--

___
Python tracker 

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

[issue35813] shared memory construct to avoid need for serialization between processes

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Davin:

> This is my fault because I altered SharedMemoryManager to no longer support 
> functionality from SyncManager that I thought could be confusing to include.  
> I am just now discovering this and am not immediately sure if simply removing 
> the SharedMemoryManager-relevant lines from your patch is the right solution 
> but I wanted to mention this thought right away.

If SharedMemoryManager subclasses SyncManager then I *think* it should obey the 
SyncManager contract.  Regardless of the shared memory facility, the user may 
also want to "shared" regular proxies between processes.

(to be honest, I don't think the multiprocessing Manager facility is used a lot 
currently...)

--

___
Python tracker 

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

[issue35978] test_venv fails in Travis with GCC

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

That looks like a similar example of the problem that bpo35378 solves. But the 
PR is merged and the test keeps failing:

test test_venv failed -- Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_venv.py", line 309, in 
test_multiprocessing
out, err = check_output([envpy, '-c',
  File "/home/travis/build/python/cpython/Lib/test/test_venv.py", line 37, in 
check_output
raise subprocess.CalledProcessError(
subprocess.CalledProcessError: Command '['/tmp/tmplplx90pf/bin/python', '-c', 
'from multiprocessing import Pool; 
print(Pool(1).apply_async("Python".lower).get(3))']' died with 
.

https://travis-ci.org/python/cpython/jobs/492305033


Running that command locally on master does not die with SIGABRT:

❯ ./python -c 'from multiprocessing import Pool; 
print(Pool(1).apply_async("Python".lower).get(3))'; echo $?
python
/home/pablogsal/github/cpython/Lib/multiprocessing/pool.py:234: 
ResourceWarning: unclosed running multiprocessing pool 

  _warn(f"unclosed running multiprocessing pool {self!r}",
ResourceWarning: Enable tracemalloc to get the object allocation traceback
0

--

___
Python tracker 

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

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Pablo for the fix ;-)

--

___
Python tracker 

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[STINNER Victor]

STINNER Victor  added the comment:

Pablo fixed bpo-35378 with:

New changeset 3766f18c524c57784eea7c0001602017d2122156 by Pablo Galindo in 
branch 'master':
bpo-35378: Fix multiprocessing.Pool references (GH-11627)
https://github.com/python/cpython/commit/3766f18c524c57784eea7c0001602017d2122156

Does this change also fix this issue? If not, can we attempt again to fix this 
issue?

Moreover, should we do something in Python 3.7? Sadly, I don't think that we 
can do anything for 3.7 and 2.7.

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[Josh Rosenberg]

Josh Rosenberg  added the comment:

+1 on PR 11830 from me. Can always revisit if #11107 is ever implemented and it 
turns out that the reference count manipulation means startup is too slow due 
to all the slice interning triggered comparisons (unlikely, but theoretically 
possible I guess).

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[Tim Peters]

Tim Peters  added the comment:

> Oh, Tim Peters succeded somehow to
> remove Josh Rosenberg from the nosy list: I add him again ;-)

Certainly wasn't my intent!  That happens too often on the tracker.  Thanks for 
noticing! :-(

--

___
Python tracker 

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

[issue35978] test_venv fails in Travis with GCC

[STINNER Victor]

STINNER Victor  added the comment:

Pablo: Can this issue be related bpo-35378?

commit 3766f18c524c57784eea7c0001602017d2122156
Author: Pablo Galindo 
Date:   Mon Feb 11 17:29:00 2019 +

bpo-35378: Fix multiprocessing.Pool references (GH-11627)

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

Oh, Tim Peters succeded somehow to remove Josh Rosenberg from the nosy list: I 
add him again ;-)

Thanks Josh for your analysis, it seems like we agree :-) I wrote PR 11830 to 
use strong references, as you proposed.

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

> Then again, there's probably no other code in the world that compares slice 
> objects ;-)

Well, that's a good explanation :-) So maybe there is no need to keep the 
micro-optimization and PR 11830 would be safer (use strong references), rather 
than PR 11828 (untrack the 2 internal tuples).

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[Tim Peters]

Tim Peters  added the comment:

Josh, I'd say the speed of this code doesn't matter one whit to anything.  Like 
you, I'd _prefer_ that the issue be fixed by building "real tuples" that own 
their own references, which would also (as you showed) allow for briefer, 
simpler, clearer code.  But I'm OK with playing obscure GC tricks too.

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

I wrote PR 11830: the other solution that I propose, use strong references 
rather than borrowed references.

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +11861

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Ah, I see Victor posted an alternative PR that avoids the reference counting 
overhead by explicitly removing the temporary tuples from GC tracking. I'm 
mildly worried by that approach, only because the only documented use case for 
PyObject_GC_UnTrack is in tp_dealloc (that said, the code explicitly allows it 
to be called twice due to the Py_TRASHCAN mechanism, so it's probably safe so 
long as the GC design never changes dramatically). If slice comparison really 
is performance sensitive enough to justify this, so be it, but I'd personally 
prefer to reduce the custom code involved in a rarely used code path (we're not 
even caching constant slices yet, so no comparisons are likely to occur for 
99.99% of slices, right?).

--
nosy: +josh.r
versions: +Python 3.6, Python 3.7

___
Python tracker 

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

[issue35810] Object Initialization Bug with Heap-allocated Types

[STINNER Victor]

STINNER Victor  added the comment:

> I would suggest clear, open communication of this. It's solving a bug. It 
> makes CPython safer. It's not difficult to adapt your code, once you know 
> it's affected. The usual PY_VERSION_HEX guard will do it for you. I think we 
> should risk it.

It would be nice to give an example of code in the Porting guide (What's new in 
Python 3.8?).

--
nosy: +vstinner

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[Tim Peters]

Tim Peters  added the comment:

> It's impressive *and* scary that such 13 years old
> bug only show up today...

Then again, there's probably no other code in the world that compares slice 
objects ;-)

--
nosy: +tim.peters -josh.r

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Victor found the same bug I found while I was composing this, posting only to 
incorporate proposed solution:

I *think* I have a cause for this, but someone else with greater understanding 
of the cycle collector should check me if the suggested fix has non-trivial 
performance implications (I suspect the answer is no, performance is 
unaffected).

slice_richcompare borrows its behavior from tuple by creating a temporary tuple 
for each slice, the delegating to the tuple comparison ( 
https://github.com/python/cpython/blob/master/Objects/sliceobject.c#L591 ).

Problem is, it uses borrowed references when creating said tuples, not owned 
references. Because test_slice's BadCmp.__eq__ is implemented in Python, the 
comparison can be interrupted by cycle collection during the __eq__ call. When 
then happens, there are precisely two references to the BadCmp object:

1. In the slice (owned)
2. In the temporary tuple (borrowed)

When a cycle collection occurs during the comparison, and subtract_refs ( 
https://github.com/python/cpython/blob/master/Modules/gcmodule.c#L398 ) is 
called, the BadCmp object in question is visited via both the slice and the 
tuple, and since it has no non-container objects referencing it, it ends up 
with the initial reference count of 1 attempting to drop to -1, and the 
assertion is violated. While the code of gcmodule.c appears to have been 
refactored since 3.7 so the assert occurs in a different function, with a 
slightly different message, it would break the same way in both 3.7 and master, 
and whether or not it triggers the bug, the broken behavior of 
slice_richcompare hasn't changed for a *long* time. 

Underlying problem would seem to be slice's richcompare believing it's okay to 
make a tuple from borrowed references, then make a call on it that can trigger 
calls into Python level code (and therefore into the cycle collector); 
everything else is behaving correctly here. I'm guessing the only reason it's 
not seen in the wild is that slices based on Python defined types are almost 
never compared at all, let alone compared on debug builds that would be 
checking the assert and with an accelerated cycle collection cycle that would 
make a hit likely.

Solution would be to stop trying to microoptimize slice_richcompare to avoid 
reference count manipulation and just build a proper tuple. It would even 
simplify the code since we could just use PyTuple_Pack, reducing custom code by 
replacing:

t1 = PyTuple_New(3);
if (t1 == NULL)
return NULL;
t2 = PyTuple_New(3);
if (t2 == NULL) {
Py_DECREF(t1);
return NULL;
}

PyTuple_SET_ITEM(t1, 0, ((PySliceObject *)v)->start);
PyTuple_SET_ITEM(t1, 1, ((PySliceObject *)v)->stop);
PyTuple_SET_ITEM(t1, 2, ((PySliceObject *)v)->step);
PyTuple_SET_ITEM(t2, 0, ((PySliceObject *)w)->start);
PyTuple_SET_ITEM(t2, 1, ((PySliceObject *)w)->stop);
PyTuple_SET_ITEM(t2, 2, ((PySliceObject *)w)->step);

with:

t1 = PyTuple_Pack(3, ((PySliceObject *)v)->start, ((PySliceObject 
*)v)->stop, ((PySliceObject *)v)->step);
if (t1 == NULL)
return NULL;
t2 = PyTuple_Pack(3, ((PySliceObject *)w)->start, ((PySliceObject 
*)w)->stop, ((PySliceObject *)w)->step);
if (t2 == NULL) {
Py_DECREF(t1);
return NULL;
}

and makes cleanup simpler, since you can just delete:

PyTuple_SET_ITEM(t1, 0, NULL);
PyTuple_SET_ITEM(t1, 1, NULL);
PyTuple_SET_ITEM(t1, 2, NULL);
PyTuple_SET_ITEM(t2, 0, NULL);
PyTuple_SET_ITEM(t2, 1, NULL);
PyTuple_SET_ITEM(t2, 2, NULL);

and let the DECREFs for t1/t2 do their work normally.

If for some reason the reference count manipulation is unacceptable, this 
*could* switch between two behaviors depending on whether or not 
start/stop/step are of known types (e.g. if all are NoneType/int, this could 
use the borrowed refs code path safely) where a call back into Python level 
code is impossible; given that slices are usually made of None and/or ints, 
this would remove most of the cost for the common case, at the expense of more 
complicated code. Wouldn't help numpy types though, and I suspect the cost of 
pre-checking the types for all six values involved would eliminate most of the 
savings.

Sorry for not submitting a proper PR; the work machine I use during the day is 
not suitable for development (doesn't even have Python installed).

--
nosy: +josh.r

___
Python tracker 

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

[issue35505] Test test_imaplib fail in test_imap4_host_default_value

[miss-islington]

miss-islington  added the comment:


New changeset 009220eae2e6b456707c1c89ef3f344b682e89d5 by Miss Islington (bot) 
in branch '3.7':
bpo-35505: Skip test_imap4_host_default_value if localhost listens on IMAP port 
(GH-11823)
https://github.com/python/cpython/commit/009220eae2e6b456707c1c89ef3f344b682e89d5


--
nosy: +miss-islington

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

It's impressive *and* scary that such 13 years old bug only show up today...

I modified the GC threshold in the site module with this patch:

diff --git a/Lib/site.py b/Lib/site.py
index ad1146332b..68cdf105b1 100644
--- a/Lib/site.py
+++ b/Lib/site.py
@@ -557,6 +557,10 @@ def main():
 This function is called automatically when this module is imported,
 unless the python interpreter was started with the -S flag.
 """
+import gc, random
+n = random.randint(5, 100)
+gc.set_threshold(n)
+
 global ENABLE_USER_SITE
 
 orig_path = sys.path[:]


Running the test suite with this patch doesn't catch the bug :-(

$ ./python -m test -j0 -r -u all,-gui

--

___
Python tracker 

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

[issue35810] Object Initialization Bug with Heap-allocated Types

[Stefan Behnel]

Stefan Behnel  added the comment:

Victor asked me for a review, so, well, what should I say? The intention seems 
right, and the patch also looks good to me.

>From the top of my head, I wouldn't know any problems this would produce with 
>Cython specifically, although it's worth testing. If we find anything, then 
>it's hopefully easy to adapt to in a point release, which Cython users can 
>then build their code with to support Py3.8+. That's the way it usually works 
>with Cython.

The main problem I see is that while this change may crash in some cases (the 
lucky cases that are easy to detect), it will leak references in others, which 
can be really difficult to detect. My own biased little gut feeling still wants 
me to believe that the impact of this could be somewhat low. Why? Well, how 
many heap-allocated types with a custom "tp_dealloc()" do you expect there to 
be? My feeling is that most existing code still uses statically allocated types 
for that. CPython has a couple of examples (that the PR adapts), but IIRC, 
that's mostly because some core devs wanted to test-ride parts of the newer 
type creation C-API in the standard library (a perfectly valid reason, but that 
also makes it a bad example). From the little valley that I sit in, I don't see 
a large bunch of other usages of that API out in the wild. That doesn't mean 
they are not there, and there might well be some large projects that could be 
bitten by this change. But I'm sure it's not the majority.

So, on the one hand, any breaking change to the C-API may make users end up 
with little maintained projects that they depend on and that break in Py3.y and 
later without anyone having access to the PyPI project account to push a fix 
release. Very annoying situation.

On the other hand, a breaking C-API change is not the only problematic case, 
and people have to deal with similar situations anyway. CPython changes are 
really just one of many, many ways to render your code unusable.

I would suggest clear, open communication of this. It's solving a bug. It makes 
CPython safer. It's not difficult to adapt your code, once you know it's 
affected. The usual PY_VERSION_HEX guard will do it for you. I think we should 
risk it.

--

___
Python tracker 

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

[issue35505] Test test_imaplib fail in test_imap4_host_default_value

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 3dc67d0316740e78e7cd014343f34d85908219b7 by Victor Stinner (Matěj 
Cepl) in branch 'master':
bpo-35505: Skip test_imap4_host_default_value if localhost listens on IMAP port 
(GH-11823)
https://github.com/python/cpython/commit/3dc67d0316740e78e7cd014343f34d85908219b7


--
nosy: +vstinner

___
Python tracker 

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

[issue35505] Test test_imaplib fail in test_imap4_host_default_value

[miss-islington]

Change by miss-islington :


--
pull_requests: +11860

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

Extract of slice_richcompare():

t1 = PyTuple_New(3);
if (t1 == NULL)
return NULL;
t2 = PyTuple_New(3);
if (t2 == NULL) {
Py_DECREF(t1);
return NULL;
}

PyTuple_SET_ITEM(t1, 0, ((PySliceObject *)v)->start);
PyTuple_SET_ITEM(t1, 1, ((PySliceObject *)v)->stop);
PyTuple_SET_ITEM(t1, 2, ((PySliceObject *)v)->step);
PyTuple_SET_ITEM(t2, 0, ((PySliceObject *)w)->start);
PyTuple_SET_ITEM(t2, 1, ((PySliceObject *)w)->stop);
PyTuple_SET_ITEM(t2, 2, ((PySliceObject *)w)->step);

res = PyObject_RichCompare(t1, t2, op);

PyTuple_SET_ITEM(t1, 0, NULL);
PyTuple_SET_ITEM(t1, 1, NULL);
PyTuple_SET_ITEM(t1, 2, NULL);
PyTuple_SET_ITEM(t2, 0, NULL);
PyTuple_SET_ITEM(t2, 1, NULL);
PyTuple_SET_ITEM(t2, 2, NULL);

Py_DECREF(t1);
Py_DECREF(t2);

return res;

t1 and t2 tuples are tracked by the GC, but t1 and t2 items are *borrowed* 
references.

gc.collect() calls subtract_refs() which decreases the reference counter of all 
objects tracked by the GC... but v, w, t1 and t2 contain the same references 
which causes the assertion error.

The code is quite old:

commit 47b9ff6ba11fab4c90556357c437cb4feec1e853
Author: Guido van Rossum 
Date:   Thu Aug 24 00:41:19 2006 +

Restructure comparison dramatically.  There is no longer a default
*ordering* between objects; there is only a default equality test
(defined by an object being equal to itself only).  Read the comment
in object.c.  The current implementation never uses a three-way
comparison to compute a rich comparison, but it does use a rich
comparison to compute a three-way comparison.  I'm not quite done
ripping out all the calls to PyObject_Compare/Cmp, or replacing
tp_compare implementations with tp_richcompare implementations;
but much of that has happened (to make most unit tests pass).
(...)

+static PyObject *
+slice_richcompare(PyObject *v, PyObject *w, int op)
...
+   t1 = PyTuple_New(3);
+   t2 = PyTuple_New(3);
+   if (t1 == NULL || t2 == NULL)
+   return NULL;
+
+   PyTuple_SET_ITEM(t1, 0, ((PySliceObject *)v)->start);
+   PyTuple_SET_ITEM(t1, 1, ((PySliceObject *)v)->stop);
+   PyTuple_SET_ITEM(t1, 2, ((PySliceObject *)v)->step);
+   PyTuple_SET_ITEM(t2, 0, ((PySliceObject *)w)->start);
+   PyTuple_SET_ITEM(t2, 1, ((PySliceObject *)w)->stop);
+   PyTuple_SET_ITEM(t2, 2, ((PySliceObject *)w)->step);
...

I see two options:

* Ensure that t1 and t2 temporary objects are not tracked by the GC
* Modify slice_richcompare() to use strong references, rather than *borrowed* 
references

I wrote PR 11828 which implements the first solution. The second solution has a 
minor impact on performance.

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed.

[Brennan Vincent]

Brennan Vincent  added the comment:

Hi Guido,

I have tried applying your patch. It seems to fix the issue (Valgrind no longer 
reports memory definitely lost).

--

___
Python tracker 

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

[issue5996] abstract class instantiable when subclassing built-in types

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

I removed Lukasz from the nosy list since it's not a regression. No need to 
spam our 3.8 release manager ;-)

--
nosy:  -lukasz.langa

___
Python tracker 

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

[issue35978] test_venv fails in Travis with GCC

[Karthikeyan Singaravelan]

New submission from Karthikeyan Singaravelan :

I noticed this while checking issue35961. test_venv is always failing on GCC 
which is marked as optional in Travis.

Log : https://travis-ci.org/python/cpython/jobs/492123436#L1909

0:39:35 load avg: 1.00 [390/416] test_venv
test test_venv failed -- Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_venv.py", line 309, in 
test_multiprocessing
out, err = check_output([envpy, '-c',
  File "/home/travis/build/python/cpython/Lib/test/test_venv.py", line 37, in 
check_output
raise subprocess.CalledProcessError(
subprocess.CalledProcessError: Command '['/tmp/tmpg8ubeyfn/bin/python', '-c', 
'from multiprocessing import Pool; 
print(Pool(1).apply_async("Python".lower).get(3))']' died with 
.

Also GCC test have been timing out for at least past 4 months : 
https://python.zulipchat.com/#narrow/stream/116742-core.2Fhelp/topic/GCC.20build.20in.20Travis.20always.20times.20out

--
messages: 335338
nosy: pablogsal, vstinner, xtreak
priority: normal
severity: normal
status: open
title: test_venv fails in Travis with GCC
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue35918] multiprocessing's SyncManager.dict.has_key() method is broken

[Josh Rosenberg]

Change by Josh Rosenberg :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue5996] abstract class instantiable when subclassing built-in types

[Rémi Lapeyre]

Change by Rémi Lapeyre :


--
nosy: +remi.lapeyre

___
Python tracker 

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

[issue5996] abstract class instantiable when subclassing built-in types

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Closed #35958 as a duplicate of this issue (and updated the title, since 
clearly the problem is not specific to dict).

Patch probably needs to be rebased/rewritten against latest trunk (given it 
dates from Mercurial days).

--
nosy: +Jon McMahon, josh.r
stage:  -> patch review
title: abstract class instantiable when subclassing dict -> abstract class 
instantiable when subclassing built-in types
versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

It has been crashing for almost all the last 5 PRs merged to master : 

https://travis-ci.org/python/cpython/jobs/492241988 - Feb 12, 21:51
https://travis-ci.org/python/cpython/jobs/492123432 - Feb 12, 17:33
https://travis-ci.org/python/cpython/jobs/491917875 - Feb 12, 06:20
https://travis-ci.org/python/cpython/jobs/491898690 - Feb 12, 05:15
https://travis-ci.org/python/cpython/jobs/491798997 - Feb 12, 01:19

It's easy to overlook this since PR passes on verbose mode . There is another 
test these days that fails very frequently but passes on verbose mode : 
issue35809 . It's little hard to track their first failure since Travis 
provides no search capability for logs.

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

See also this idea of changing gc.set_threshold() when using -X dev:
https://mail.python.org/pipermail/python-dev/2018-June/153857.html

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

Ah! I found a way to reproduce the crash:

diff --git a/Lib/test/test_slice.py b/Lib/test/test_slice.py
index 4ae4142c60..b18f8f1c8c 100644
--- a/Lib/test/test_slice.py
+++ b/Lib/test/test_slice.py
@@ -1,4 +1,8 @@
 # tests for slice objects; in particular the indices method.
+import gc, random
+n = random.randint(1, 700)
+print("set_threshold(%s)" % n)
+gc.set_threshold(n)
 
 import itertools
 import operator


$ ./python -m test -F -j0 test_slice test_slice test_slice test_slice 
test_slice test_slice test_slice test_slice


I went up to January 1st, 2018 (commit 
e8ed96550c6aa9a1e39c36e67e892994e25e2c41): the test already crashed with my 
patch, so it's not a regression. I reset the priority.

--
priority: release blocker -> 

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

> Do you have an url to an example of crash on Travis?

Travis crash that occurred few days back : 
https://travis-ci.org/python/cpython/jobs/491701299 . I first noticed it on an 
IDLE lib PR where this failure was unrelated but I can remember occurring at 
least few weeks back. I will try get the older one. Sorry I forgot to file an 
issue during that time.

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

On s390x Debian 3.x, it seems like the bug started to show up near:
https://buildbot.python.org/all/#/builders/13/builds/2328

This build contains 2 changes, one doc change and this namedtuple change which 
mentions reference count:

https://github.com/python/cpython/commit/64360ada0f6123a051e9dc6cd04f030ec1322e46

"Complete and neaten-up namedtuple's replacement of builtin function lookups 
with derefs (GH-11794)"

Ok, but I don't see the relationship between namedtupled and this specific 
test!?

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

Lukasz: I'm not sure what is happening here, but such random bugs are always 
scrary. I raise the priority to "release blocker" until we know more about the 
issue.

--
nosy: +lukasz.langa
priority: normal -> release blocker

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

Extract of the crashing test:

def test_cmp(self):
...

class Exc(Exception):
pass

class BadCmp(object):
def __eq__(self, other):
raise Exc

s1 = slice(BadCmp())
s2 = slice(BadCmp())
self.assertEqual(s1, s1)
self.assertRaises(Exc, lambda: s1 == s2)   # < CRASH HERE

...

The latest change in test_slice.py has been made in 2016: 3 years ago.

Latest changes in Objects/sliceobject.c were refactoring related to header 
files (november 2018). The latest "significant" change was done in April 2018: 
"bpo-33012: Fix invalid function cast warnings with gcc 8 for METH_NOARGS".

I bet more on a recent change which is not directly related to slices... like 
the implementation of the PEP 572? It would help to know when the crash started 
to occur exactly (date + time).

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

I'm unable to reproduce the issue on my Fedora 29 (x86-64) laptop. I used two 
terminals:

* ./python -m test -F -j0 test_slice test_slice test_slice test_slice 
test_slice test_slice test_slice test_slice
* ./python -m test -j0 -u all,-gui -r # stress the system to randomize timings 
in test_slice

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

> I am seeing some failures in travis and some buildbots:

Do you have an url to an example of crash on Travis?

Which buildbots are affected? I saw the crash on s390x Debian 3.x.

--

___
Python tracker 

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

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

Change by STINNER Victor :


--
title: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small 
-> test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is 
too small

___
Python tracker 

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

[issue35961] gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

bpo-35977 has been marked as a duplicate, copy of the first message:

s390x Debian 3.x:
https://buildbot.python.org/all/#/builders/13/builds/2344

0:06:26 load avg: 0.92 [291/420/1] test_slice crashed (Exit code -6)
Modules/gcmodule.c:110: gc_decref: Assertion "gc_get_refs(g) > 0" failed: 
refcount is too small
Enable tracemalloc to get the memory block allocation traceback

object  : .BadCmp object at 
0x3ff93967e90>
type: BadCmp
refcount: 1
address : 0x3ff93967e90
Fatal Python error: _PyObject_AssertFailed

Current thread 0x03ff95272700 (most recent call first):
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_slice.py",
 line 107 in 
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", 
line 197 in handle
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", 
line 782 in assertRaises
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_slice.py",
 line 107 in test_cmp
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", 
line 642 in run
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", 
line 702 in __call__
  ...

--
nosy: +vstinner

___
Python tracker 

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

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

Change by STINNER Victor :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is 
too small

___
Python tracker 

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

[issue35976] Enable Windows projects to build with platform ARM32

[Steve Dower]

New submission from Steve Dower :

Just updating the title to reflect what the patch actually does in isolation - 
you probably should update the PR and NEWS items to match.

It's fine (probably preferred) to mention in the issue and PR text that it's 
been split out from another PR. But we have to account for the (very small) 
chance that this part is merged and the rest is not - in that case, having a 
standalone description of the change is much more helpful.

--
title: PCBuild file changes for arm32 should be separated from code changes for 
review -> Enable Windows projects to build with platform ARM32

___
Python tracker 

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

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Sorry, it occurs in Travis too randomly not consistently.

--

___
Python tracker 

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

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Duplicate of issue35961 ? It occurs in Travis too

--
nosy: +xtreak

___
Python tracker 

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

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

I'm unable to reproduce the issue on my Fedora 29 (x86-64) laptop. I used two 
terminals:

* ./python -m test -F -j0 test_slice test_slice test_slice test_slice 
test_slice test_slice test_slice test_slice
* ./python -m test -j0 -u all,-gui -r # stress the system to randomize timings 
in test_slice

--

___
Python tracker 

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

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

New submission from STINNER Victor :

s390x Debian 3.x:
https://buildbot.python.org/all/#/builders/13/builds/2344

0:06:26 load avg: 0.92 [291/420/1] test_slice crashed (Exit code -6)
Modules/gcmodule.c:110: gc_decref: Assertion "gc_get_refs(g) > 0" failed: 
refcount is too small
Enable tracemalloc to get the memory block allocation traceback

object  : .BadCmp object at 
0x3ff93967e90>
type: BadCmp
refcount: 1
address : 0x3ff93967e90
Fatal Python error: _PyObject_AssertFailed

Current thread 0x03ff95272700 (most recent call first):
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_slice.py",
 line 107 in 
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", 
line 197 in handle
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", 
line 782 in assertRaises
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_slice.py",
 line 107 in test_cmp
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", 
line 642 in run
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", 
line 702 in __call__
  ...

--
components: Interpreter Core
messages: 335320
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_slice crashed on s390x Debian 3.x: gc_decref: Assertion 
"gc_get_refs(g) > 0" failed: refcount is too small
versions: Python 3.8

___
Python tracker 

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

[issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

[STINNER Victor]

STINNER Victor  added the comment:

When the test has been ran one more time in verbose mode, it passed.

--

___
Python tracker 

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

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

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

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

[Paul Ganssle]

Paul Ganssle  added the comment:

> @Guido, I recall a while back you explained the value of adding CWD to 
> sys.path.  Would you mind providing some insight here

I think bpo-35971 or bpo-13475 are better places to discuss that, because this 
issue doesn't require CWD to be in the path. You can trigger this by any 
mechanism that would raise an exception in the Python code used to initialize 
the interpreter.

Even if we restrict it to the most common case - shadowing a part of the 
standard library - you would still be able to trigger this as long as you have 
*some* mechanism to manipulate the python path in the environment that allows 
you to put paths on there with higher precedence than the standard library.

I think the core question in this issue is whether errors in the Python code 
run during the interpreter initialization should crash the interpreter or exit 
gracefully with an error code.

--

___
Python tracker 

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

[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

[Eric Snow]

Eric Snow  added the comment:

Thanks, Alexey!

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

[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

[Eric Snow]

Eric Snow  added the comment:


New changeset 16f842da3c862d76a1177bd8ef9579703c24fa5a by Eric Snow (Alexey 
Izbyshev) in branch 'master':
bpo-35972: _xxsubinterpreters: Fix potential integer truncation on 32-bit in 
channel_send() (gh-11822)
https://github.com/python/cpython/commit/16f842da3c862d76a1177bd8ef9579703c24fa5a


--

___
Python tracker 

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

[issue35971] Documentation should warn about code injection from current working directory

[Eric Snow]

Eric Snow  added the comment:

Note that I've asked Guido to comment about CWD in sys.path on issue #35969.

--

___
Python tracker 

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

[issue35971] Documentation should warn about code injection from current working directory

[Eric Snow]

Eric Snow  added the comment:

related: issue #13475

--

___
Python tracker 

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

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

[Eric Snow]

Eric Snow  added the comment:

@Guido, I recall a while back you explained the value of adding CWD to 
sys.path.  Would you mind providing some insight here?

--
nosy: +gvanrossum

___
Python tracker 

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

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

[Eric Snow]

Eric Snow  added the comment:

related: issue #13475

--

___
Python tracker 

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

[issue35971] Documentation should warn about code injection from current working directory

[STINNER Victor]

STINNER Victor  added the comment:

If someone wants to change the Python default behavior, a PEP will be required 
since it would be a major backward incompatible changes. A lot of details and 
use cases must be discussed and documented.

--

___
Python tracker 

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

[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

[Eric Snow]

Eric Snow  added the comment:

On Tue, Feb 12, 2019 at 3:57 AM STINNER Victor  wrote:
> A long term solution would to enable -I behavior by default: don't add the 
> current directory to sys.path when using -c CMD.

>From what I can recall, it was a conscious decision to include CWD in 
>sys.path.  Doing so benefits some scripting use cases.  The downside is the 
>effect when running an app.

--
nosy: +eric.snow

___
Python tracker 

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