[issue32846] Deletion of large sets of strings is extra slow

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Random idea:  For some range of array sizes (bigger than L3 cache), there might 
be a net benefit to sorting L1-sized clumps of pointers before making the 
Py_DECREF calls.  Possibly, the cost of sorting would be offset by improved 
memory access patterns.

On the other hand, this might just optimize an artificial benchmark that isn't 
representative of real code where the data is actually being used.  In that 
case, the program is already going to have to hop all over memory just to 
access the referred-to objects.

--

___
Python tracker 

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

[issue29480] Mac OSX Installer SSL Roots

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> I would like to suggest that the OSX installer automatically run "Install 
> Certificates.command", or display a prompt to users saying "Run Now" during 
> installation.

+1 This would be really helpful.  I occasionally get entire rooms full of Mac 
users with a fresh install of Python 3.6 who immediately get stuck with 
something as simple as:

   urllib.request.urlopen('http://www.python.org').read()

The error messages that pop up are decidedly unhelpful.  This is especially 
mystifying because the original request uses "http" and the site itself 
redirects to "https".

--
nosy: +rhettinger

___
Python tracker 

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

[issue32855] Add documention stating supported Platforms

[Ned Deily]

Change by Ned Deily :


--
nosy: +ned.deily

___
Python tracker 

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

[issue32855] Add documention stating supported Platforms

[Jay Yin]

New submission from Jay Yin :

we can probably add a section that includes all supported platforms and 
possibly "partially" supported platforms, and maybe include platforms that 
currently aren't supported but want/plan to be supported.

--
assignee: docs@python
components: Documentation
messages: 312225
nosy: docs@python, jayyin11043
priority: normal
severity: normal
status: open
title: Add documention stating supported Platforms

___
Python tracker 

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

[issue29480] Mac OSX Installer SSL Roots

[Tommy Carstensen]

Tommy Carstensen  added the comment:

I can't user requests, urllib, pandas.read_html(), etc. because of this. I 
don't have root access / sudo rights. I've tried downloading OpenSSL from 
openssl.org and then installing with:
 `./config --prefix=/my/home/dir ; make ; make install`

Then I tried installing Python with:
 `export CFLAGS="-I/my/home/dir/include" ; export LDFLAGS="-L/my/home/dir/lib" 
; ./configure prefix=/my/home/dir ; make ; make install`

But it doesn't work. How can I install Python3.6 without root access / admin 
rights? Thanks!

--
nosy: +Tommy.Carstensen

___
Python tracker 

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

[issue32779] urljoining an empty query string doesn't clear query string

[Paul Fisher]

Paul Fisher  added the comment:

In this case, the RFC is mismatched from the actual behaviour of browsers (as 
described and codified by WhatWG).  It was surprising to me that urljoin() 
didn't do what I percieved as "the right thing" (and I expect other users would 
too).

I would personally expect urljoin to do "the thing that everybody else does".  
Is there a sensible way to reduce this mismatch?

For reference, Java's stdlib does what I would expect here:

URI base = URI.create("https://example.com/?a=b;);
URI rel = base.resolve("?");
System.out.println(rel);

https://example.com/?

--

___
Python tracker 

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

[issue32840] Must install python 3.6.3 when 3.6.4 already installed

[Steve Dower]

Steve Dower  added the comment:

> The problem is independent of word length.

There should be no problem installing 3.6.4 of one architecture and 3.6.3 of 
the other at the same time. I myself do this all the time with every version of 
Python. You can't do it if they are the same architecture.

Please confirm that this particular scenario does not work, and provide log 
files for both the successful and the failed install. There may be an issue 
specific to your environment that we can help diagnose.

--

___
Python tracker 

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

[issue32840] Must install python 3.6.3 when 3.6.4 already installed

[Steve Dower]

Steve Dower  added the comment:

This is a big feature request, as our current installer technology is 
specifically designed for ease of upgrading between minor versions (e.g. 
3.6.3->3.6.4). We would need to completely rewrite our installers.

If you want to avoid the installers completely and have partially isolated 
instances, consider the packages on nuget.org (see 
https://www.nuget.org/packages?q=publisher%3A%22Python+Software+Foundation%22 
). Note that these may break if you have installed a similar (same x.y) version 
of Python using the installer, but won't have any trouble if you have used 
Nuget to install all the versions on your machine.

For fully isolated instances, you can add a "python._pth" file to these after 
they have been extracted (or a pyvenv.cfg with applocal=1 for Python 3.5). This 
will suppress all registry lookups that may be confused by normal installs, as 
well as environment variables and optionally user site packages and .pth files.

--
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.6

___
Python tracker 

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

[issue32854] Add ** Map Unpacking Support for namedtuple

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Concur with Raymond.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32854] Add ** Map Unpacking Support for namedtuple

[Raymond Hettinger]

Raymond Hettinger  added the comment:

The intended way to support **unpacking is the _asdict() method:

t(**a._asdict())

It doesn't really make sense to add direct support for **unpacking because 
named tuples are sequences and not mappings.  To support **unpacking, we would 
have to add a keys() method and modify __getitem__() to handle both integer 
indexing and string key lookup.  Once we have **a and a[k] and a.keys(), people 
would also want a.values() a.items() etc.  The world gets murky when both 
sequence and mapping behaviors become commingled.

--
nosy: +rhettinger

___
Python tracker 

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

[issue32850] Run gc_collect() before complaining about dangling threads

[Nathaniel Smith]

Change by Nathaniel Smith :


--
nosy: +ezio.melotti, njs

___
Python tracker 

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

[issue32854] Add ** Map Unpacking Support for namedtuple

[John Crawford]

New submission from John Crawford :

At present, `collections.namedtuple` does not support `**` map unpacking 
despite being a mapping style data structure.  For example:

>>> from collections import namedtuple
>>> A = namedtuple("A", "a b c")
>>> a = A(10, 20, 30)
>>> def t(*args, **kwargs):
... print(f'args={args!r}, kwargs={kwargs!r}')
...
>>> t(*a)
args=(10, 20, 30), kwargs={}
>>> t(**a)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: t() argument after ** must be a mapping, not A
>>> 

No doubt, the lack of current support is due to namespace conflicts that result 
from trying to provide a `keys` method amidst also supporting attribute-style 
access to the `namedtuple` class.  As we can see, providing a `keys` attribute 
in the `namedtuple` produces an interesting result:

>>> Record = namedtuple("Record", "title keys description")
>>> t(**Record(1, 2, 3))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: attribute of type 'int' is not callable
>>>

To me, this calls out a design flaw in the `**` unpacking operator where it 
depends on a method that uses a non-system naming convention.  It would make 
far more sense for the `**` operator to utilize a `__keys__` method rather than 
the current `keys` method.  After all, the `` naming convention 
was introduced to avoid namespace conflict problems like this one.

--
components: Library (Lib)
messages: 312218
nosy: John Crawford
priority: normal
severity: normal
status: open
title: Add ** Map Unpacking Support for namedtuple
type: enhancement
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

[issue32845] Mac: Local modules can shadow builtins (e.g. a local `math.py` can shadow `math`)

[Ned Deily]

Ned Deily  added the comment:

The example you gave caused problems because of the use of the ambiguous 
unqualified name "math".  If you are careful to use qualified names, and/or 
perhaps use alias names ("as") to increase readability, there shouldn't be any 
problems.

--

___
Python tracker 

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

[issue32846] Deletion of large sets of strings is extra slow

[Raymond Hettinger]

Raymond Hettinger  added the comment:

The 4th graph in this article may be showing the reason for the growth in 
random access times as the size gets bigger:

https://www.extremetech.com/extreme/188776-how-l1-and-l2-cpu-caches-work-and-why-theyre-an-essential-part-of-modern-chips

--

___
Python tracker 

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

[issue32852] trace changes sys.argv from list to tuple

[Kyle Altendorf]

Change by Kyle Altendorf :


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

___
Python tracker 

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

[issue32846] Deletion of large sets of strings is extra slow

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> In former examples (list, ordered dict) objects are iterated and deleted 
>in order of creation. But in the set of strings items are deleted in
> non-predicable random order. I suppose the non-linear effect is 
> related to memory management.

That makes sense.  We're likely seeing an artifact of a favorable 
correspondence between the container pointer order and the order that the 
referred-to objects were created in memory in this somewhat non-representative 
test case.  That is why lists lose the favorable timing when the data is 
shuffled.

If the test bench creates all the referred-to objects in consecutive memory 
locations, then any container accessing those objects consecutively will 
benefit from spatial cache locality.  (i.e. If there is more than one datum per 
cache line, the second read is virtually free.  Likewise, memory controller 
read-ahead makes a long series of consecutive accesses cheaper.)

It would be nice is the timing were run on strings instead of integers.  Ints 
are somewhat weird in that the hashes of consecutive integers are themselves 
consecutive, you can fit two ints in one cache line. 

I'm not sure whether it applies here, but there may also be a branch-prediction 
effect as well:  
https://stackoverflow.com/questions/11227809/why-is-it-faster-to-process-a-sorted-array-than-an-unsorted-array

FWIW, the deallocation routine for sets isn't doing anything special.  It just 
calls Py_DECREF in a loop:

static void
set_dealloc(PySetObject *so)
{
setentry *entry;
Py_ssize_t used = so->used;

/* bpo-31095: UnTrack is needed before calling any callbacks */
PyObject_GC_UnTrack(so);
Py_TRASHCAN_SAFE_BEGIN(so)
if (so->weakreflist != NULL)
PyObject_ClearWeakRefs((PyObject *) so);

for (entry = so->table; used > 0; entry++) {
if (entry->key && entry->key != dummy) {
used--;
Py_DECREF(entry->key);
}
}
if (so->table != so->smalltable)
PyMem_DEL(so->table);
Py_TYPE(so)->tp_free(so);
Py_TRASHCAN_SAFE_END(so)
}

--

___
Python tracker 

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

[issue32853] struct's docstring implies alignment is always performed

[Eli_B]

New submission from Eli_B :

In module struct's docstring, it says:
"...
The optional first format char indicates byte order, size and alignment:\n
  @: native order, size & alignment (default)\n
  =: native order, std. size & alignment\n
  <: little-endian, std. size & alignment\n
  >: big-endian, std. size & alignment\n
  !: same as >\n
..."
The wording sounds like either native or standard alignment is performed, 
regardless of the optional first format char.

In comparison, the table in 
https://docs.python.org/3.8/library/struct.html#byte-order-size-and-alignment 
states that in all modes other than the default, no alignment is performed. 
This is the actual behavior of the module.

--
assignee: docs@python
components: Documentation
messages: 312214
nosy: Eli_B, docs@python
priority: normal
severity: normal
status: open
title: struct's docstring implies alignment is always performed
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

[issue32852] trace changes sys.argv from list to tuple

[Kyle Altendorf via Python-bugs-list]

New submission from Kyle Altendorf :

Normally sys.argv is a list but when using the trace module sys.argv gets 
changed to a tuple.  In my case this caused an issue with running an entry 
point due to the line:

  sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])

When researching I found:
  
https://stackoverflow.com/questions/47688568/trace-sys-argv-args-typeerror-tuple-object-does-not-support-item-assig

They point out where trace assigns a tuple to sys.argv.
  https://github.com/python/cpython/blob/master/Lib/trace.py#L708


I'll see what I can do to put together a quick patch.


$ cat t.py
import sys

print(sys.version)

print(type(sys.argv))
$ /home/altendky/.pyenv/versions/3.7.0a2/bin/python t.py
3.7.0a2 (default, Feb 15 2018, 11:20:36) 
[GCC 6.3.0 20170516]

$ /home/altendky/.pyenv/versions/3.7.0a2/bin/python -m trace --trace t.py
 --- modulename: t, funcname: 
t.py(1): import sys
t.py(3): print(sys.version)
3.7.0a2 (default, Feb 15 2018, 11:20:36) 
[GCC 6.3.0 20170516]
t.py(5): print(type(sys.argv))

 --- modulename: trace, funcname: _unsettrace
trace.py(71): sys.settrace(None)

--
components: Library (Lib)
messages: 312213
nosy: altendky
priority: normal
severity: normal
status: open
title: trace changes sys.argv from list to tuple
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

[issue32851] mistake

[R. David Murray]

Change by R. David Murray :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: Complete your registration to Python tracker -- key  
uxOb1XizINE32OvAnH7tUiKMx4tFqGdK -> mistake

___
Python tracker 

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

[issue32851] Complete your registration to Python tracker -- key uxOb1XizINE32OvAnH7tUiKMx4tFqGdK

[R. David Murray]

Change by R. David Murray :


--
Removed message: https://bugs.python.org/msg312212

___
Python tracker 

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

[issue32851] Complete your registration to Python tracker -- key uxOb1XizINE32OvAnH7tUiKMx4tFqGdK

[TROUVERIE Joachim]

New submission from TROUVERIE Joachim :

Thanks 

Le 15-02-2018 17:08, Python tracker a écrit : 

> To complete your registration of the user "joack" with
> Python tracker, please do one of the following:
> 
> - send a reply to rep...@bugs.python.org and maintain the subject line as is 
> (the
> reply's additional "Re:" is ok),
> 
> - or visit the following URL:
> 
> https://bugs.python.org/?@action=confrego=uxOb1XizINE32OvAnH7tUiKMx4tFqGdK
>  [1]

Links:
--
[1]
https://bugs.python.org/?@action=confregootk=uxOb1XizINE32OvAnH7tUiKMx4tFqGdK

--
messages: 312212
nosy: joack
priority: normal
severity: normal
status: open
title: Complete your registration to Python tracker -- key  
uxOb1XizINE32OvAnH7tUiKMx4tFqGdK

___
Python tracker 

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

[issue32846] Deletion of large sets of strings is extra slow

[Serhiy Storchaka]

Change by Serhiy Storchaka :


Added file: https://bugs.python.org/file47447/bench_del.py

___
Python tracker 

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

[issue32845] Mac: Local modules can shadow builtins (e.g. a local `math.py` can shadow `math`)

[Eric Cousineau]

Eric Cousineau  added the comment:

> P.S. This issue points out once again why it is generally a bad idea to 
> shadow or mix-and-match standard library module names.

Duly noted! And thank y'all for the explanations!

Can I ask if it's bad practice to use a standard library module name as a 
submodule, e.g. `example_module.math`?

TBH, this all arises because we use Bazel and wanted to modularize our tests - 
we place them under `test/{name}.py` neighboring the target (sub)module, and 
Bazel presently generates a wrapper script which is executed in the same 
directory as the (sub)module, which is why this (unintended) shadowing occurs.

I would like still like to have a submodule named `math`, so I can just teach 
our Bazel rules to not run the test in the same directory -- if having 
submodules named `math` is not frowned upon.

--

___
Python tracker 

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

[issue32845] Mac: Local modules can shadow builtins (e.g. a local `math.py` can shadow `math`)

[Ned Deily]

Ned Deily  added the comment:

P.S. This issue points out once again why it is generally a bad idea to shadow 
or mix-and-match standard library module names.

--

___
Python tracker 

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

[issue32846] Deletion of large sets of strings is extra slow

[INADA Naoki]

Change by INADA Naoki :


--
nosy: +inada.naoki

___
Python tracker 

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

[issue32846] Deletion of large sets of strings is extra slow

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

For lists and dicts the time of deletion is virtually linear.

1 int   5.2   9.8
2 int   5.8   9.7
4 int   5.6   9.8
8 int   5.8   10.0
16 int   5.5   9.7
32 int   5.4   9.6
64 int   5.6   9.0
128 int   5.6   8.7
1 str   7.6   13.3
2 str   8.0   13.8
4 str   7.4   14.0
8 str   7.5   14.3
16 str   7.6   14.4
32 str   8.0   14.7
64 str   7.9   14.3
100 str   8.1   14.0

1 int   60.4   10.5
2 int   61.0   11.1
4 int   61.1   10.4
8 int   60.1   11.1
16 int   61.1   10.1
32 int   61.5   9.9
64 int   60.7   9.6
128 int   60.8   9.4
1 str   204.9   15.4
2 str   247.4   15.8
4 str   275.3   16.1
8 str   299.3   14.8
16 str   312.8   14.8
32 str   329.2   14.2
64 str   344.5   14.1
100 str   386.2   14.4

(third and forth columns are time in nanoseconds per item, for creation and 
deletion)

But when shuffle the input data before creating a collection, the deletion time 
becomes superlinear (and much slower).

1 int   17.4   38.9
2 int   19.1   41.3
4 int   24.4   46.3
8 int   28.0   49.5
16 int   28.1   53.4
32 int   29.8   67.2
64 int   35.2   90.6
128 int   42.6   143.1
1 str   21.1   56.3
2 str   24.3   58.2
4 str   27.1   63.6
8 str   27.3   73.9
16 str   29.4   99.2
32 str   34.3   144.8
64 str   41.8   229.5
100 str   46.3   338.4

In former examples (list, ordered dict) objects are iterated and deleted in 
order of creation. But in the set of strings items are deleted in 
non-predicable random order. I suppose the non-linear effect is related to 
memory management.

--
nosy: +lemburg, tim.peters, twouters

___
Python tracker 

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

[issue32848] Valgrind error with python

[Christian Heimes]

Christian Heimes  added the comment:

You are missing some dependencies. You have to install valgrind development 
package.

This is a bug tracker, not a support forum. Please use the Python users mailing 
list or #python IRC channel to get help.

--
nosy: +christian.heimes
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue32850] Run gc_collect() before complaining about dangling threads

[Matthias Urlichs]

Matthias Urlichs  added the comment:

Upon further consideration (and following the observation that my test cases no 
longer block for two seconds each after applying the first version of this 
patch): we do not want to clear the reference to "dangling_threads" since 
that's a weakset. We want to clear the "thread" variable, which holds a 
reference to a random member of that set, which will arbitrarily block the 
cleanup loop from ever succeeding.

Updated patch attached.

--
Added file: https://bugs.python.org/file47446/gc.patch

___
Python tracker 

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

[issue32850] Run gc_collect() before complaining about dangling threads

[Matthias Urlichs]

New submission from Matthias Urlichs :

Lib/test/support/__init__.py::threading_cleanup() complains about dangling 
threads even if the reference in question would be cleaned up by the garbage 
collector.

This is not useful, esp. when the list of referrers to the "dangling" thread 
looks like this:

[, , ]

Thus I propose to check, run gc, check again, and only *then* 
complain-and-wait. Hence the attached patch for your consideration.

--
components: Tests
files: gc.patch
keywords: patch
messages: 312206
nosy: smurfix
priority: normal
severity: normal
status: open
title: Run gc_collect() before complaining about dangling threads
type: resource usage
versions: Python 3.7
Added file: https://bugs.python.org/file47445/gc.patch

___
Python tracker 

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

[issue32848] Valgrind error with python

[Arun Solomon]

Arun Solomon  added the comment:

Hi Stefan,

I tried with two configure options. Both of them, I am getting the same error.

configure: error: Valgrind support requested but headers not available

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

___
Python tracker 

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

[issue32848] Valgrind error with python

[Stefan Krah]

Change by Stefan Krah :


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

___
Python tracker 

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

[issue32848] Valgrind error with python

[Stefan Krah]

Stefan Krah  added the comment:

You have two options:

  a) ./configure CFLAGS="-O0 -g" --without-pymalloc

  b) ./configure CFLAGS="-O0 -g" --with-valgrind


For b) you need the Valgrind headers installed.


--with-pydebug is always wrong when using Valgrind.

--
nosy: +skrah
status: pending -> open

___
Python tracker 

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

[issue32848] Valgrind error with python

[Arun Solomon]

Arun Solomon  added the comment:

Hi,

I ran with the following command to configure python with valgrind:
./configure --without-pymalloc --with-pydebug --with-valgrind

I was getting the following error:
configure: error: Valgrind support requested but headers not available

Python:   2.7.5
Valgrind: 3.12.0

How can i resolve this error?

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

___
Python tracker 

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

[issue32848] Valgrind error with python

[R. David Murray]

R. David Murray  added the comment:

Did you notice that our configure has a --with-valgrind option? 

In any case, there isn't a bug in python here that you are reporting.  If you 
want to continue to learn about our existing support for valgrind and find 
things that can be improved, you are welcome to open a more specific issue in 
the future.  I would suggest seeking help on the python-list mailing list for 
learning about this, and for your second question.

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

___
Python tracker 

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

[issue32846] Deletion of large sets of strings is extra slow

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32779] urljoining an empty query string doesn't clear query string

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Python follows not WhatWG but RFC.
https://tools.ietf.org/html/rfc3986#section-5.2.2 is proper definition for url 
joining algorithm.

--
nosy: +asvetlov

___
Python tracker 

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

[issue29804] test_ctypes test_pass_by_value fails on arm64 (aarch64) architecture

[Iryna Shcherbina]

Iryna Shcherbina  added the comment:

PR 1559 fixes the issue in Fedora builds on arm64. The issue is no longer 
reproducible with Python 3.7.

--

___
Python tracker 

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

[issue32839] Add after_info as a function to tkinter

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I agreed with Cheryl's conclusion that likely after_cancel() had been called 
with None. The comments about 8.4 is wrong, and the solution in issue763637 is 
not correct. The current code code deletes the script for the first event if 
pass None to after_cancel(). Do you ming to open a PR for proper solving 
issue763637 Cheryl?

--

___
Python tracker 

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

[issue32839] Add after_info as a function to tkinter

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> Since events are removed from Tcl once that are invoked, how would the 
> dictionary be cleaned up?  Would after_info need to be polled every once in a 
> while to clean up the dictionary or would it just exist until the object is 
> destroyed?

Good question. Currently the reference to a callable is kept in the dict  until 
the object is destroyed. This can be considered as a bug (see issue1524639).

--

___
Python tracker 

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

[issue32781] lzh_tw is missing in locale.py

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

See also issue20087. It added lzh_tw locale, but later this change was 
reverted. Thus I close this issue as a duplicate.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Mismatch between glibc and X11 locale.alias

___
Python tracker 

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

[issue32781] lzh_tw is missing in locale.py

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I'm not sure that wrong guess is better that exception.

It looks to me that there is something wrong with the way we use the alias 
table. It is glibc centric, but some entries contradict glibc, because the X11 
alias have a precedence. There are known issues on OS X. I think the other way 
for determining the locale encoding should be used.

--
nosy: +benjamin.peterson, lemburg

___
Python tracker 

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

[issue32849] Fatal Python error: Py_Initialize: can't initialize sys standard streams

[Rudolph Froger]

Change by Rudolph Froger :


--
type:  -> crash

___
Python tracker 

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

[issue21258] Add __iter__ support for mock_open

[Lumír Balhar]

Change by Lumír Balhar :


--
nosy: +frenzy

___
Python tracker 

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

[issue32781] lzh_tw is missing in locale.py

[INADA Naoki]

INADA Naoki  added the comment:

lzh_tw was added in this commit:
https://github.com/bminor/glibc/commit/5057e7ce826bb0be3f476408b2ae364042f2a9bb#diff-3d056472e12e5dc464fa44144719b82f

I don't know why Python should have such a large locale alias table.

I added Serhiy to nosy list because he is author of issue20079.

Serhiy, how do you think about making UTF-8 as default charset and
drop all aliases like "xx_YY" -> "xx_YY.UTF-8" ?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32849] Fatal Python error: Py_Initialize: can't initialize sys standard streams

[Rudolph Froger]

New submission from Rudolph Froger :

Sometimes a new Python 3.6.4 process is aborted by the kernel (FreeBSD 11.1) 
(before loading my Python files).

Found in syslog:

kernel: pid 22433 (python3.6), uid 2014: exited on signal 6 (core dumped)
Fatal Python error: Py_Initialize: can't initialize sys standard streams
OSError: [Errno 9] Bad file descriptor

I've been able to run ktrace on such a Python process, see attachment. See 
around line 940: "RET   fstat -1 errno 9 Bad file descriptor"

--
files: alles-23978
messages: 312194
nosy: rudolphf
priority: normal
severity: normal
status: open
title: Fatal Python error: Py_Initialize: can't initialize sys standard streams
versions: Python 3.6
Added file: https://bugs.python.org/file47444/alles-23978

___
Python tracker 

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