Re: SIGSEGV and SIGILL inside PyCFunction_Call

[dieter]

Anders Wegge Keller  writes:
> ...
>  I have an ongoing issue with my usenet setup. I'm that one dude who don't
> want to learn perl. That means that I have to build inn from source, so I
> can enable the python interpreter. That's not so bad, and the errors that
> show up have been something that I have been able to figure out by myself.
> At least up until now. I have an almost 100% repeatable crash, when nnrpd
> performs the user authentication step. Backtracing the core dum gives this:
>
> #0  0x564a864e2d63 in ?? ()
> #1  0x7f9609567091 in call_function (oparg=, 
> pp_stack=0x7ffda2d801b0) at ../Python/ceval.c:4352
>
> Note:   Line 4352 C_TRACE(x, PyCFunction_Call(func,callargs,NULL));
>
> #2  PyEval_EvalFrameEx (
> f=Frame 0x7f9604758050, for file /etc/news/filter/nnrpd_auth.py, 
> line 67, in __init__ (self= description=None, rownumber=None, messages=[], _executed=None, 
>
>  ...
>
>  Weird observation #1: Sometimes the reason is SIGSEGV, sometimes it's
> SIGILL. 

Python tends to be sensitive to the stack size. In previous times,
there have often be problems because the stack size for threads
has not been large enough. Not sure, whether "nnrpd" is multi threaded
and provides a sufficiently large stack for its threads.

A "SIGILL" often occurs because a function call has destroyed part
of the stack content and the return is erroneous (returning in the midst
of an instruction).

> ...
>  I'm not ready to give up yet, but I need some help proceeding from here.
> What do the C_TRACE really do,

The casing (all upper case letters) indicates a C preprocessor macro.
Search the "*.h" files for its definition.

I suppose that with a normal Python build (no debug build), the
macro will just call "PyCFunction_Call".
Alternatively, it might provide support for debugging, tracing
(activated by e.g. "pdb.set_trace()").


> and is there some way of getting a level
> deeper, to see what cause the SEGV. Also, how can the C code end up with an
> illegal instruction_

A likely cause for both "SIGSEGV" and "SIGILL" could be stack corruption
leading to a bad return or badly restored register values.

I would look at the maschine instructions (i.e. look at the assembler
rather than the C level) to find out precisely, which instruction
caused the signal.


Unfortunately, stack corruption is a non local problem (the point
where the problem is caused is usually far away from the point
where it is observed).

If the problem is not "too small stack size", you might need
a tool to analyse memory overrides.

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

Re: Grapheme clusters, a.k.a.real characters

[Steven D'Aprano]

On Thu, 20 Jul 2017 12:40:08 +1000, Chris Angelico wrote:

> On Thu, Jul 20, 2017 at 12:12 PM, Steve D'Aprano
>  wrote:
>> On Thu, 20 Jul 2017 08:12 am, Gregory Ewing wrote:
>>
>>> Chris Angelico wrote:
>> [snip overly complex and complicated string implementation]
>>
>>
> An accurate description, but in my own defense, I had misunderstood
> Marko's idea. Actually, the implementation I detailed was far SIMPLER
> than I thought it would be; I started writing that post trying to prove
> that it was impossible, but it turns out it isn't actually impossible.
> Just highly impractical.

I haven't really been paying attention to Marko's suggestion in detail, 
but if we're talking about a whole new data type, how about a list of 
nodes, where each node's data is a decomposed string object guaranteed to 
be either:

* an array of single-character code points;

* or a single combining character sequence, emoji variation 
  sequence, or other grapheme

* with the appropriate length in "characters".


So a string like "Hello World!" would be a single node:

(12, "Hello World!")


Strings will always be in decomposed form, so a "café au lait" would 
automatically use:

U+0065 LATIN SMALL LETTER E + U+0301 COMBINING ACUTE ACCENT


regardless of your editor, and represented by three nodes:

(3, "caf") (1, "e\N{COMBINING ACUTE ACCENT}") (8, " au lait")


Iterating the string would mean:

for node in nodes:
if node.count = 1:
yield node.string
else:
yield from node.string

Reversing would be:

for node in nodes[::-1]:
if node.count = 1:
yield node.string
else:
yield from node.string[::-1]

Getting the length in graphemes would mean:

sum(node.count for node in nodes)


Indexing and slicing I leave for an exercise.


We lose O(1) indexing and slicing, but the length could be cached. 
Calculate the length on demand, then cache it for next time. (This 
assumes the string is immutable.) Indexing and slicing would be 
proportional to the number of nodes, not the length of the string. So not 
as bad as a naive UTF-8 implementation.

Each substring could use the Flexible String Representation, to minimize 
the total memory. E.g. in the "café au lait" example above, the first and 
last node would use one byte per code point, and the middle node would 
use two bytes per code point.

Of course, this doesn't *completely* solve the question of end user 
expectations. For example, many people would want "ij" to count as a 
single character, or "\r\n". And it would complicate the implementation 
of the various string methods and the regex engine. It will almost 
certainly be much slower than the str type, and use more memory, and it 
would be lossy with regards to certain patterns of code points.

For example, it wouldn't distinguish between composed and decomposed 
strings, since they're always normalised to decomposed form.

But it might be worth doing, for applications that care about giving a 
better user experience when it comes to editing text.



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

scandir slower than listdir

[Torsten Bronger]

Hallöchen!

With a 24,000 files directory on an SSD running Ubuntu,

#!/usr/bin/python3

import os, time


start = time.time()
list(os.listdir("/home/bronger/.saves"))
print("listdir:", time.time() - start)

start = time.time()
list(os.scandir("/home/bronger/.saves"))
print("scandir:", time.time() - start)

yields

listdir: 0.045470237731933594
scandir: 0.08043360710144043

However, scandir is supposed to be faster than listdir.  Why do I
see this?

Tschö,
Torsten.

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

[issue30917] IDLE: Add idlelib.config.IdleConf unittest

[Terry J. Reedy]

Terry J. Reedy added the comment:


New changeset 65c24c846797b93d7adb72fc400f95a570f43fa9 by terryjreedy in branch 
'3.6':
[3.6] bpo-30917: IDLE: Add config.IdleConf unittests (GH-2691) (#2753)
https://github.com/python/cpython/commit/65c24c846797b93d7adb72fc400f95a570f43fa9


--

___
Python tracker 

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

[issue30917] IDLE: Add idlelib.config.IdleConf unittest

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
pull_requests: +2828

___
Python tracker 

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

[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

[Terry J. Reedy]

Terry J. Reedy added the comment:

Fix worked: test_idle passed in build 897.
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/897/steps/test/logs/stdio
I also included the fix of PR2769 in PR2753 (3.6 backport).

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

___
Python tracker 

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

[issue30973] Regular expression "hangs" interpreter

[T Trindad]

New submission from T Trindad:

The following code "hangs" the interpreter:

import re
re.search(r"/\*\*((?:[^*]+|\*[^/])*)\*/", """   /** Copy Constructor **/
private EvaluationContext (EvaluationContext base) {""")



Changing the regex to r"/\*\*((?:[^*]|\*[^/])*)\*/" makes it work normally.

--
components: Regular Expressions
messages: 298705
nosy: T Trindad, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Regular expression "hangs" interpreter
type: crash
versions: Python 2.7

___
Python tracker 

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

[issue30940] Documentation for round() is incorrect.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The documentation should be updated before converting round() to Argument 
Clinic, because this update should be backported to 3.6 and 3.5, while the 
conversion can be made only in 3.7.

--
keywords: +easy
stage:  -> needs patch

___
Python tracker 

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

[issue29144] Implicit namespace packages in Python 3.6

[Nick Coghlan]

Nick Coghlan added the comment:

At the Python level, the rules are simple: the first directory on sys.path that 
contains an __init__.py file is identified as a self-contained package. It is 
then up to that __init__.py file to emulate namespace package behaviour (by 
extending __path__) if that's what the author intended.

Nothing changed in Python 3.6 in terms of that, and it's been that way ever 
since native namespace packages were introduced.

So if there's a behavioural change in the pkg_resources namespace emulation in 
going from Python 3.5 to 3.6 that occurs with both old & new versions of 
setuptools, then I see two main possible candidates for that:

1. Something changed in one of the APIs that setuptools uses to recalculate 
__path__

2. Something changed in importlib where we're not respecting runtime changes to 
__path__ properly, and are instead relying on either 
__spec__.submodule_search_locations or a stale cached version of __path__

Neither of those is something we *intended* to change in 3.6, so I think it's 
reasonable to categorise this as 3.6 regression at the standard library level 
(even though setuptools will likely need to work around it anyway, given the 
earliest we'll be able to fix it is in 3.6.3)

--
keywords: +3.6regression
stage:  -> needs patch

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Chris Angelico]

On Thu, Jul 20, 2017 at 12:12 PM, Steve D'Aprano
 wrote:
> On Thu, 20 Jul 2017 08:12 am, Gregory Ewing wrote:
>
>> Chris Angelico wrote:
> [snip overly complex and complicated string implementation]
>

An accurate description, but in my own defense, I had misunderstood
Marko's idea. Actually, the implementation I detailed was far SIMPLER
than I thought it would be; I started writing that post trying to
prove that it was impossible, but it turns out it isn't actually
impossible. Just highly impractical.

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

Re: Grapheme clusters, a.k.a.real characters

[Steve D'Aprano]

On Thu, 20 Jul 2017 08:12 am, Gregory Ewing wrote:

> Chris Angelico wrote:
[snip overly complex and complicated string implementation]
 
> +1. We should totally do this just to troll the RUE!

You're an evil, wicked man, and I love it.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Users of namedtuple: do you use the _source attribute?

[Rick Johnson]

On Tuesday, July 18, 2017 at 12:59:36 AM UTC-5, Terry Reedy wrote:
> Yes, No.  The developers of the class agree that a trailing
> underscore convention would have been better.  'source_'
> etc.

Which, while encroaching on the "this-is-a-reserved-symbol_"
convention, would relieve the current "_stay-away-from-
volatile-me" fear mongering.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Steve D'Aprano]

On Thu, 20 Jul 2017 01:30 am, Random832 wrote:

> On Tue, Jul 18, 2017, at 22:49, Steve D'Aprano wrote:
>> > What about Emoji?
>> > U+1F469 WOMAN is two columns wide on its own.
>> > U+1F4BB PERSONAL COMPUTER is two columns wide on its own.
>> > U+200D ZERO WIDTH JOINER is zero columns wide on its own.
>> 
>> 
>> What about them? In a monospaced font, they should follow the same rules
>> I used
>> above: either 0, 1 or 2 column wide.
> 
> You snipped the important part - the fact that the whole sequence of
> three code points U+1F469 U+200D U+1F4BB is a single grapheme cluster
> two columns wide.

There's no requirement for rendering engines to display the emoji sequence in
any specific way. Maybe we would like the combined emoji to display in two
columns, but that's not guaranteed, nor is it required by the standard.

http://unicode.org/emoji/charts/emoji-zwj-sequences.html

If the renderer cannot display a "Woman Personal Computer" as a single emoji, it
is permissible to fall back to two glyphs.


> You also ignored all of the other examples in my post. Did you even read
> anything beyond what you snipped?

Yes I did, but I didn't understand it. Maybe that was because I didn't read your
post carefully enough, or maybe it was because you didn't explain what point
you were making carefully enough. Or a little of both.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Combining every pair of list items and creating a new list.

[Rick Johnson]

On Tuesday, July 18, 2017 at 5:19:56 AM UTC-5, Rahul K P wrote:
> You can use a simple logic and list comprehension.
> 
> so it will be like this
> 
> lst = [1, 2, 3, 4, 5, 6, 7, 8]
> print [lst[i:i+2] for i in range(0,len(lst),2)]

No no no. Anybody can write code like that! To wow a
professor and earn a high grade, the OP must prove a
competence in mental gymnastics. Try this one liner:

# BOILER PLATE
>>> import sys
>>> from operator import add, sub, mul
>>> lst = [1, 2, 3, 4, 5, 6, 7, 8]
# MEAT AND TATERS
>>> sys.stdout.write(str(repr([lst[i:add(map(int, tuple([i]))[0], sub(2, 0))] 
>>> for i in range(range(10)[0], mul(len(lst[:]), 1), sub(2, 0))])))
[[1, 2], [3, 4], [5, 6], [7, 8]]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Steve D'Aprano]

On Thu, 20 Jul 2017 04:34 am, Mikhail V wrote:

> It is also pretty obvious that these Caps makes it harder to read in general.
> (more obvious that excessive diacritics, like in French)


No it isn't.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

[Louie Lu]

Louie Lu added the comment:

Yes, Terry's patch fixed this.

--

___
Python tracker 

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

[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

[Terry J. Reedy]

Terry J. Reedy added the comment:


New changeset 9f9192afbb4e45d09f0d3d717b457d157dc46398 by terryjreedy in branch 
'master':
bpo-30968: Fix test_get_font in IDLE's test_config.  (#2769)
https://github.com/python/cpython/commit/9f9192afbb4e45d09f0d3d717b457d157dc46398


--

___
Python tracker 

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

[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
pull_requests: +2827

___
Python tracker 

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

[issue29403] mock's autospec's behavior on method-bound builtin functions is broken

[Berker Peksag]

Changes by Berker Peksag :


--
stage: patch review -> backport needed

___
Python tracker 

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

[issue30883] test_urllib2net failed on s390x Debian 3.6: ftp.debian.org error, too many connections from your internet address

[Berker Peksag]

Berker Peksag added the comment:

Thanks, Ammar!

--
resolution:  -> fixed
stage: backport needed -> resolved
status: open -> closed

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Ben Finney]

Random832  writes:

> On Tue, Jul 18, 2017, at 19:21, Gregory Ewing wrote:
> > Random832 wrote:
> > > What about Emoji?
> > > U+1F469 WOMAN is two columns wide on its own.
> > > U+1F4BB PERSONAL COMPUTER is two columns wide on its own.
>
> Emoji comes from Japanese 絵文字 - 絵(E) picture, 文字(moji)
> character.

Yes. Those (U+1F469 and U+1F4BB) are clearly pictures.

The cell phone industry in East Asia insist that they are characters,
loudly enough to get them into Unicode. I disagree strongly.

-- 
 \“I don't accept the currently fashionable assertion that any |
  `\   view is automatically as worthy of respect as any equal and |
_o__)   opposite view.” —Douglas Adams |
Ben Finney

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

[issue30883] test_urllib2net failed on s390x Debian 3.6: ftp.debian.org error, too many connections from your internet address

[Berker Peksag]

Berker Peksag added the comment:


New changeset ae4dca7701ca77a37aa8c956450ff8e21fe6883e by Berker Peksag (Ammar 
Askar) in branch '3.6':
[3.6] bpo-30883: Use pythontest.net instead of debian.org in test_urllib2net 
(GH-2755)
https://github.com/python/cpython/commit/ae4dca7701ca77a37aa8c956450ff8e21fe6883e


--

___
Python tracker 

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

[issue30883] test_urllib2net failed on s390x Debian 3.6: ftp.debian.org error, too many connections from your internet address

[Berker Peksag]

Berker Peksag added the comment:


New changeset aca493b7a337338fa20395fbc2d1895cb8093826 by Berker Peksag (Ammar 
Askar) in branch '3.5':
[3.5] bpo-30883: Use pythontest.net instead of debian.org in test_urllib2net 
(GH-2755)
https://github.com/python/cpython/commit/aca493b7a337338fa20395fbc2d1895cb8093826


--

___
Python tracker 

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

[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

[Terry J. Reedy]

Terry J. Reedy added the comment:

Louie, I am fixing this (I believe).

--

___
Python tracker 

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

[issue30333] test_multiprocessing_forkserver: poll() failed on AMD64 FreeBSD CURRENT Non-Debug 3.5

[Kubilay Kocak]

Changes by Kubilay Kocak :


--
nosy: +koobs

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Rick Johnson]

On Wednesday, July 19, 2017 at 5:29:23 AM UTC-5, Rhodri James wrote:
> when Acorn were developing their version of extended ASCII
> in the late 80s, they asked three different University
> lecturers in Welsh what extra characters they needed, and
> got three different answers.

And who would have guessed that the wishes of three random
Welshian University lectures would become a microcosm into
the future problems afflicting internationalization and
localization of computer software. 

And perhaps one day there will be fantastical fables written
about the "Three Wise Welshian Lecturers", who traveled
across endless expanses of earth and sea, following at times
strange lights in the sky, and bearing gifts of "me, myself,
and i" upon the new king of encodings.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29403] mock's autospec's behavior on method-bound builtin functions is broken

[Berker Peksag]

Berker Peksag added the comment:


New changeset 856cbcc12f2e4cca93af5dc7ed6bcea4dd942f10 by Berker Peksag (Aaron 
Gallagher) in branch 'master':
bpo-29403: Fix mock's broken autospec behavior on method-bound builtin 
functions (GH-3)
https://github.com/python/cpython/commit/856cbcc12f2e4cca93af5dc7ed6bcea4dd942f10


--

___
Python tracker 

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

[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

[Terry J. Reedy]

Terry J. Reedy added the comment:

I merged pr2754 in pr2753, the 3.6 backport of pr2691.  To avoid breaking 3.6 
buildbots more than one test, I will hold off merging pr2753 until a fix is 
available.

--

___
Python tracker 

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

[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
pull_requests: +2826

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Rick Johnson]

On Wednesday, July 19, 2017 at 1:57:47 AM UTC-5, Steven D'Aprano wrote:
> On Wed, 19 Jul 2017 17:51:49 +1200, Gregory Ewing wrote:
> 
> > Chris Angelico wrote:
> >> Once you NFC or NFD normalize both strings, identical strings will
> >> generally have identical codepoints... You should then be able to use
> >> normal regular expressions to match correctly.
> > 
> > Except that if you want to match a set of characters,
> > you can't reliably use [...], you would have to write them out as
> > alternatives in case some of them take up more than one code point.
> 
> Good point!
> 
> A quibble -- there's no "in case" here, since you, the
> programmer, will always know whether they have a single
> code point form or not. If you're unsure, look it up, or
> call unicodedata.normalize().
> 
> (Yeah, right, like the average coder will remember to do this...)
> 
> Nevertheless, although it might be annoying and tricky,
> regexes *are* flexible enough to deal with this problem.
> After all, you can't use [th] to match "th" as a unit
> either, and regex set character set notation [abcd] is
> logically equivalent to (a|b|c|d).

If the intention is to match the two-character-string "th",
then the obvious solution would be to wrap the substring
into a matching or non-matching group:

pattern = r'(?:th)'

Though i suppose one could abuse the character-set syntax by
doing something like:

pattern = r'[t][h]'

However, even the first example (using a group) is
superfluous if "th" is the only substring to be matched.
Employing the power of grouping is only necessary in more
complex patterns.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: rpy2

[Larry Martell]

On Wed, Jul 19, 2017 at 6:28 PM, Dennis Lee Bieber
 wrote:
> On Wed, 19 Jul 2017 11:15:03 -0400, Larry Martell 
> declaimed the following:
>
>>
>>/usr/bin/ld: cannot find -lr_utils
>>
>>But I could not find how to get libr_utils.
>>
>
> Have you already built/installed R (maybe development packages too) --
> I suspect the library is part of the R utils package.
>
> https://stat.ethz.ch/R-manual/R-devel/library/utils/html/utils-package.html

On RHEL 6 the version of R is 3.0, and rpy2 does not work with that
version. I installed R 3.3.3, but I suspect I do not have the 3.3.3
devel and/or utils package. I don't know where to get them from.

> OTOH -- perhaps it is looking for this third-party package
>
> https://github.com/HenrikBengtsson/R.utils

I first thought that too, but that is entirely something else.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30917] IDLE: Add idlelib.config.IdleConf unittest

[Terry J. Reedy]

Terry J. Reedy added the comment:


New changeset ed014f7e135fe021837208960237d6c37afde5be by terryjreedy (Louie 
Lu) in branch 'master':
bpo-30917: IDLE: Fix mock_config deepcopy to read_string (#2754)
https://github.com/python/cpython/commit/ed014f7e135fe021837208960237d6c37afde5be


--

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Rick Johnson]

On Tuesday, July 18, 2017 at 10:37:18 PM UTC-5, Steve D'Aprano wrote:
> On Wed, 19 Jul 2017 10:34 am, Mikhail V wrote:
> 
> > Ok, in this narrow context I can also agree.
> > But in slightly wider context that phrase may sound almost like:
> > "neither geometrical shape is better than the other as a basis
> > for a wheel. If you have polygonal wheels, they are still called wheels."
> 
> I'm not talking about wheels, I'm talking about writing systems which are
> fundamentally collections of arbitrary shapes. There's nothing about the sound
> of "f" that looks like the letter "f".

He was not talking about wheels either. 

He was making a rhetorical point as to the relationship
between wheels (aka: perfect circles) and "approximations of
wheels" (aka: equilateral and equiangular N-sided polygons).

Here's a free tip: next time you're feeling confused by
metaphors, but _before_ you reply, first do a "toupee check".
If it's missing, then consider that the atmospheric
disturbance created from a fast moving concept that buzzed
your noggin may have flung it off.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Rick Johnson]

On Tuesday, July 18, 2017 at 7:35:13 PM UTC-5, Mikhail V wrote:
> ChrisA wrote:
> >On Wed, Jul 19, 2017 at 6:05 AM, Mikhail V  wrote:
> >> On 2017-07-18, Steve D'Aprano  wrote:

> > > > _Neither system is right or wrong, or better than the
> > > > other._
> > >
> > > If that is said just "not to hurt anybody" then its ok.
> > > Though this statement is pretty absurd, not so many
> > > (intelligent) people will buy this out today.
> >
> > Let me give you one concrete example: [...]
>
> Ok, in this narrow context I can also agree. But in
> slightly wider context that phrase may sound almost like:
> "neither geometrical shape is better than the other as a
> basis for a wheel. If you have polygonal wheels, they are
> still called wheels."

All equilateral and equiangular polygons are approximations
of the wheel (or the circle, to be more general). Of course,
any "polygonal wheel" with a number of sides less than 6
would be very difficult to roll. 5 may be possible (to some
degree). However, 4 and 3 would be more useful as snowplows
than as "wheels". So the distinction between a wheel that is
either an "N-sided polygon" or a "true circle" becomes more
a matter of "levels of practicality" (both in usage _and_
manufacturing) than anything else. Of course -- and it goes
without saying, but this being python-list i feel compelled
to say it *wink* -- the perfect circle is the best wheel.

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

[issue30972] Event loop incorrectly inherited in child processes.

[Elvis Pranskevichus]

New submission from Elvis Pranskevichus:

The attached example shows that `asyncio.get_event_loop` still returns parent 
process' event loop in some cases.  It appears that the fix in issue #29703 was 
incomplete:

PARENT PID: 21947, LOOP: <_UnixSelectorEventLoop running=True closed=False 
debug=False> at 0x7f0fbe7cfd68
WORKER PID: 21948, LOOP: <_UnixSelectorEventLoop running=True closed=False 
debug=False> at 0x7f0fbe7cfd68
concurrent.futures.process._RemoteTraceback:
"""
Traceback (most recent call last):
  File "/usr/lib64/python3.6/concurrent/futures/process.py", line 175, in 
_process_worker
r = call_item.fn(*call_item.args, **call_item.kwargs)
  File "test.py", line 13, in worker
return loop.run_until_complete(worker_coro())
  File "/usr/lib64/python3.6/asyncio/base_events.py", line 454, in 
run_until_complete
self.run_forever()
  File "/usr/lib64/python3.6/asyncio/base_events.py", line 408, in run_forever
raise RuntimeError('This event loop is already running')
RuntimeError: This event loop is already running
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "test.py", line 25, in 
loop.run_until_complete(main())
  File "/usr/lib64/python3.6/asyncio/base_events.py", line 466, in 
run_until_complete
return future.result()
  File "test.py", line 21, in main
return await loop.run_in_executor(executor, worker)
RuntimeError: This event loop is already running

--
components: asyncio
files: test.py
messages: 298693
nosy: Elvis.Pranskevichus, yselivanov
priority: normal
severity: normal
status: open
title: Event loop incorrectly inherited in child processes.
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file47024/test.py

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Rick Johnson]

On Tuesday, July 18, 2017 at 10:24:54 PM UTC-5, Steve D'Aprano wrote:
> On Wed, 19 Jul 2017 10:08 am, Ben Finney wrote:
> 
> > Gregory Ewing  writes:
> > 
> > > The term "emoji" is becoming rather strained these days.
> > > The idea of "woman" and "personal computer" being
> > > emotions is an interesting one...
> > 
> > I think of “emoji” as “not actually a character in any
> > system anyone would use for writing anything, but somehow
> > gets to squat in the Unicode space”.
> 
> Blame the Japanese mobile phone manufacturers. They want to
> include emoji in their SMSes and phone chat software, [...]
> I suppose that having a standard for emoji is good. I'm not
> convinced that Unicode should be that standard, but on the
> other hand if we agree that Unicode should support
> hieroglyphics and pictographs, well, that's exactly what
> emoji are.

Indeed. 

And here are some insightful lyrics by the great R. Waters
(modified slightly) that you might consider:

If you should go skating,
on the thin ice of "modern-string life".
Dragging behind you the giant repos,
of the "million... code-point-strife".
Don't be surprised when a crack in the ice,
appears under your feet.
You step of out your ASCII and out of your mind,
with your pragmatism flowing out behind you,
as you *CLAW* the thin ice!

Yeah. 

It's a cautionary tale.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30971] Improve code readability of json.tool

[Berker Peksag]

Berker Peksag added the comment:

I don't think most of the changes improve readability of json.tool. Everyone 
has their own preferences and it's usually not enough to justify code churn.

Also, we don't need to add comments when the code itself is pretty descriptive:

# Output JSON
with options.outfile as outfile:
json.dump(obj, outfile, sort_keys=options.sort_keys, indent=4)
outfile.write('\n')

IMO, the only acceptable change is the correct use of 'default' parameter for 
'infile' and 'outfile'.

--
nosy: +berker.peksag
stage:  -> patch review
type:  -> enhancement

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Gregory Ewing]

Chris Angelico wrote:

* Strings with all codepoints < 256 are represented as they currently
are (one byte per char). There are no combining characters in the
first 256 codepoints anyway.
* Strings with all codepoints < 65536 and no combining characters,
ditto (two bytes per char).
* Strings with any combining characters in them are stored in four
bytes per char even if all codepoints are <65536.
* Any time a character consists of a single base with no combining, it
is stored in UTF-32.
* Combined characters are stored in the primary array as 0x8000
plus the index into a secondary array where these values are stored.
* The secondary array has a pointer for each combined character
(ignoring single-code-point characters), probably to a Python integer
object for simplicity.


+1. We should totally do this just to troll the RUE!

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

[issue30971] Improve code readability of json.tool

[R. David Murray]

R. David Murray added the comment:

However, our general policy is that we don't make such changes unless we are 
also touching the code for other reasons.  So I think using this PR as a base 
for your feature PRs, and then committing everything together if they are 
accepted, would be the way to go.  I don't know if it would work to actually 
use it as a base for the other PRs in github, or if it would work better to 
just make it the initial commit in a commit series.  The github workflow is too 
new for us to have definite answers to such questions :)

--
nosy: +r.david.murray

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Gregory Ewing]

Grant Edwards wrote:

Maybe it was a mistaken spelling of 'fortuned'?


Most likely. Interestingly, several sites claimed to be able to
tell me things about it. One of them tried to find poetry
related to it (didn't find any, though).

Another one offered to show me how to pronounce it, and it kind
of did, although it sounded suspiciously like it was generated
by a text-to-speech algorithm...

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

Re: Grapheme clusters, a.k.a.real characters

[Rick Johnson]

On Tuesday, July 18, 2017 at 10:07:41 PM UTC-5, Steve D'Aprano wrote:
> On Wed, 19 Jul 2017 12:10 am, Rustom Mody wrote:

[...]

> > Einstein: If you can't explain something to a six-year-
> > old, you really don't understand it yourself.
> >
>
> [...]
>
> Think about it: it simply is nonsense. If this six year old
> test was valid, that would imply that all fields of
> knowledge are capable of being taught to the average six
> year old. Yeah good luck with that.

Again, as was the case with your Toupee Fallacy a few days
ago, you've got it all wrong. The implication of that quote
was _not_ that six year olds are the "final arbiters of
truth". LOL. The implication is that explaining anything to
a six year old is not an easy task. Therefore, a teacher who
lacks a deep understanding of the subject matter could never
hope to properly educate a six year old student. And if you
don't believe me, consider the lesson of this famous quip:
"The blind leading the blind". ;-)

> But even if we accept this, it doesn't contradict the
> Mencken quote. I can explain the birds and the bees to a
> six year, at a level that they will understand. That
> doesn't mean that (1) I am an expert on human reproduction;

Since when is a biology degree prerequisite to informing a
six year old that babies are the product of "mommies and
daddies"? (at least "historically speaking") Of course, in
the not-so-distant-future, babies will be the product of
"science and farming". Hmm. Which, incidentally, is a
wonderful segue into the subject of evolution!
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27099] IDLE: turn builting extensions into regular modules

[Terry J. Reedy]

Terry J. Reedy added the comment:

Either the hard-coding in the config test will have to be changed or it will 
have to be replaced by something adaptive.  I have not quite decided yet.  Once 
the new tests are merged, I expect to do some followup improvements.

Equal important for this issue is minimal testing of each extension converted.  
They do not have to be complete, but should demonstrate that the extension is 
present in the menu and basically runs.  Testing for presence in the menu has 
to be worked out.  There should be one or more separate issues that will be 
dependencies of this.  Does your patch put menu entries in the same place?  I 
will want to move some, but that can be a followup issue, which will require 
change in the test.  Ditto for combining some of the small files into fewer 
files.

--

___
Python tracker 

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

[issue29144] Implicit namespace packages in Python 3.6

[Brett Cannon]

Brett Cannon added the comment:

Without looking into what changed, I say Python 3.6 being more strict in what 
is a namespace package is reasonable and setuptools needs to be better about 
installing pkg_resources-using __init__.py files.

--

___
Python tracker 

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

[issue30490] Allow pass an exception to the Event.set method

[pfreixes]

pfreixes added the comment:

More info about why here 
https://github.com/python/cpython/pull/1824#issuecomment-315903808

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

[issue27099] IDLE: turn builting extensions into regular modules

[Charles Wohlganger]

Charles Wohlganger added the comment:

Changes to master have introduced tests with hardcoded values for what 
extensions are expected to be loaded by IDLE. Given that this patch turn all 
current extensions into mainlined modules, none of them are loaded as 
extensions and all of the related tests fail. What should I do about this?

--

___
Python tracker 

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

[issue30971] Improve code readability of json.tool

[Daniel Himmelstein]

New submission from Daniel Himmelstein:

In https://github.com/python/cpython/pull/2720, I propose code changes to the 
json.tool command line utility. These changes are entirely non-functional and 
instead focus on improving code readability, style, brevity, extensibility, and 
maintainability.

These changes mainly came up during the implementation of two enhancements of 
json.tool:

+ https://github.com/python/cpython/pull/345 to add indentation / whitespace 
options (bpo-29636).

+ https://github.com/python/cpython/pull/201 to display non-ascii characters 
(bpo-27413).

These issues and pull requests are currently awaiting further consensus around 
their design and desirability. Therefore, I wanted to separate the 
non-functional code improvements from these PRs into a distinct PR.

This has the benefit of allowing the future enhancement PRs to focus solely on 
adding features rather than the readability changes.

--
components: Library (Lib)
messages: 298686
nosy: dhimmel
priority: normal
pull_requests: 2824
severity: normal
status: open
title: Improve code readability of json.tool
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

[issue24459] Mention PYTHONFAULTHANDLER in the man page

[Joshua Jay Herman]

Joshua Jay Herman added the comment:

Was this ever merged? I'm not sure whats happening.

--

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Terry Reedy]

On 7/19/2017 4:28 AM, Steven D'Aprano wrote:

On Tue, 18 Jul 2017 10:11:39 -0400, Random832 wrote:


On Fri, Jul 14, 2017, at 04:15, Marko Rauhamaa wrote:

  Consider, for example, a Python source code
editor where you want to limit the length of the line based on the
number of characters more typically than based on the number of pixels.


Even there you need to go based on the width in character cells. Most
characters for East Asian languages occupy two character cells.

It would be nice if there was an easy way to get str.format to use this
width instead of the length in code points for the purpose of padding.


You could always put in a feature request :-)


I believe that there is a request that at least one of the string 
functions be character width aware, using the unicodedatabase.



--
Terry Jan Reedy

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

Re: pyserial and end-of-line specification

[Rob Gaddi]

On 07/18/2017 12:53 PM, FS wrote:

Thank you for your response Andre. I had tried some code like that in the 
document but it did not seem to work. However ever leaving my terminal for a 
time the code eventually wrote out the records so apparently there is some very 
deep buffering going on here. A little more searching on the web revealed the 
following:

https://stackoverflow.com/questions/10222788/line-buffered-serial-input

It is apparent that pySerial, or at least the documentation is falling short of 
my needs. It is very unclear what module in the layer is handling the buffering 
and newlines and so forth. Also unclear is whether the coupled python and OS is 
reading FIFO or LIFO--something important in quasi realtime scientific 
applications.
   This is problematic since the serial port is still so ubiquitous to a lot of 
scientific instrumentation. I probably will patch up some byte oriented code 
for this or perhaps write the module in C.

Thanks again
Fritz



Handling it .read(1) at a time is probably your best bet.  Append them 
into a bytearray and pull it all out when you're done.


It's a serial port; it's not like there is any degree of inefficiently 
that you could write the code that will make it slow with respect to the 
I/O.  I write a LOT of serial instrument I/O and I've definitely had to 
fall back to this plan.  Your code gets a little long, you hide it all 
in a function somewhere and never think on it again.


One paradigm I stick for ASCII serial is to have 3 functions:

def command(msg: str):
"""Sends a command, raises CommError if it doesn't get some
expected OK sort of thing."""

def query(msg: str):
"""Sends a commmand, returns a (trimmed) response line."""

def _communicate(msg: str):

The ugliest stuff, all the str->bytes->str stuff, the line-ending and 
protocols, goes into _communicate.  Query usually just calls 
_communicate.  Command slaps on whatever checks are needed.  It feels a 
bit heavy, but it leads to highly-usable code and makes it easy to 
integrate logging, retries, integrating "*OPC?" handshakes, whatever 
sort of things turn out to be necessary on a given device.


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Grapheme clusters, a.k.a.real characters

[Mikhail V]

Steven D'Aprano wrote:

>On Wed, 19 Jul 2017 10:34 am, Mikhail V wrote:
>> Ok, in this narrow context I can also agree.
>> But in slightly wider context that phrase may sound almost like:
>> "neither geometrical shape is better than the other as a basis
>> for a wheel. If you have polygonal wheels, they are still called wheels."


> I'm not talking about wheels, I'm talking about writing systems which are
> fundamentally collections of arbitrary shapes. There's nothing about the sound
> of "f" that looks like the letter "f".

> But since you mentioned non-circular wheels, such things do exist, and are 
> still
> called "wheels" (or "gears", which is a kind of specialised wheel).

> https://eric.ed.gov/?id=EJ937593
> https://en.wikipedia.org/wiki/Non-circular_gear
> https://en.wikipedia.org/wiki/Square_wheel
> https://www.youtube.com/watch?v=vk7s4PfvCZg


Triangular wheels, sure, why not?
A default "wheel" in a conversation, unless other meaning stated,
is a common wheel of a bike or a car. At least I believe so, but since I'm
non-native speaker I may be wrong.

As well as the default merit of goodness of a writing system is how
easy one can read texts in it (_a healthy person, done with the
learning process_).

Fundamentally, yes, a system in theory can be a set of _any_ shapes.
This means that its goodness, in respect to the shapes alone,
can vary from absolute zero (as e.g. in a hand-written recipe from a doctor :)
and up to the optimum domain.

Even if we take more obvious criteria - the ease of input -
I suppose it is obvious that inputting German text by rules which need initial
Caps in _all_ nouns, is harder than inputting the same text without Caps.
Same for inputting diacritics.
It is also pretty obvious that these Caps makes it harder to read in general.
(more obvious that excessive diacritics, like in French)

Thus, even in a narrow context, "no system is better or worse" sounds very
suspect to me.


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

Re: Best way to assert unit test cases with many conditions

[Rob Gaddi]

On 07/19/2017 03:26 AM, Ganesh Pal wrote:


Yes.  Just assert each thing as it needs asserting.



  Asserting each sub test will fail the entire test,  I want the  to pass
the test if any the sub test passes.  If the sub test fail try all cases
and fail for the last one.

Example :



def test_this(self):

   if Sub_test_1():

 #passes  then  PASS the  Complete test  i.e. test_this() and  If
sub_test_1() fail then run further subtest!)

  elif run sub_test_2() :

  #Then PASS test_this() and  don't run  next test i.e
sub_test_3(),sub_test_4() etc)

  elif run sub_test_3()

  if sub_test_3()

  #  Then pass  test_this() and  don't run next test  i.e. sub_test_4()
,sub_test_5(). etc)



Regards,

Ganesh



So you're saying if test 1 passes you don't even bother to run test 2? 
To be blunt, that sounds convoluted and overcomplicated.  How would you 
ever know that test2 is even doing its job?


Why is this superior to writing five tests, all of which always run? 
Note that "runtime" is not a valid answer unless you're talking about 
multiple minutes of it.


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[MRAB]

On 2017-07-19 09:29, Marko Rauhamaa wrote:

Gregory Ewing :


Marko Rauhamaa wrote:

 * a final "v" receives a superfluous "e" ("love")


It's not superfluous there, it's preventing "love" from looking like
it should rhyme with "of".


I'm pretty sure that wasn't the original motivation. If I had to guess,
the reason was the possible visual confusion with "w".

An interesting tidbit is that the English spelling demonstrates how the
[o] sound regularly shifted into an [ʌ] sound in front of nasals and
"v":

dove
love
hover


In UK English, "hover" has the short-O sound.


cover
shove
above

sponge
come
among
front
done
son
monk
monkey

Again, exceptions abound:

on
wrong
song
gone
long


Also:

cove
stove

and then there's:

move

which is different again.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to assert unit test cases with many conditions

[Terry Reedy]

On 7/19/2017 8:24 AM, Peter Otten wrote:

Ganesh Pal wrote:



(1) I would want my subtest to have  a *Condition* based on which it  that
would pass my entire test  if any of the sub-test passed.


If I understand correctly, you want

assertTrue(subtest1 or subtest2 or subtest3 or subtest4 ...)

or

assertTrue(any(iterable_of_subtests))

Each 'subtestn' can be an assertion or expression or function call.
Peter's code below implements the general idea above in the any form 
with function calls in your particular situation where you also want to 
log subtest failures without failing the overall test.  (The 'any' 
builtin or's together an indefinite number of items.  The 'all' builtin 
and's multiple items.)



Your spec translates to something like:

$ cat stop_on_first_success.py
import logging

import unittest
import sys

log = logging.getLogger()

class T(unittest.TestCase):
 def test_foo(self):
 subtests = sorted(
 name for name in dir(self) if name.startswith("subtest_foo_")
 )
 for name in subtests:
 method = getattr(self, name)
 try:
 method()
 except Exception as err:
 log.error(err)
 else:
 break
 else:
 self.fail("no successful subtest")

 def subtest_foo_01_int(self):
 self.assertTrue(isinstance(x, int))
 def subtest_foo_02_42(self):
 self.assertEqual(x, 42)
 def subtest_foo_03_upper(self):
 self.assertEqual(x.upper(), x)

if __name__ == "__main__":
 logging.basicConfig()

 x = sys.argv.pop(1)
 x = eval(x)
 print("Running tests with x = {!r}".format(x))

 unittest.main()

The x = eval() part is only for demonstration purposes.

Below's the script output for various incantations. The subtests are
executed in alphabetical order of the subtest_foo_xxx method names, failures
are logged, and the loop stops after the first success.

$ python3 stop_on_first_success.py '"foo"'
Running tests with x = 'foo'
ERROR:root:False is not true
ERROR:root:'foo' != 42
ERROR:root:'FOO' != 'foo'
- FOO
+ foo

F
==
FAIL: test_foo (__main__.T)
--
Traceback (most recent call last):
   File "stop_on_first_success.py", line 22, in test_foo
 self.fail("no successful subtest")
AssertionError: no successful subtest

--
Ran 1 test in 0.001s

FAILED (failures=1)
$ python3 stop_on_first_success.py '"FOO"'
Running tests with x = 'FOO'
ERROR:root:False is not true
ERROR:root:'FOO' != 42
.
--
Ran 1 test in 0.001s

OK
$ python3 stop_on_first_success.py '42'
Running tests with x = 42
.
--
Ran 1 test in 0.000s

OK
$ python3 stop_on_first_success.py '42.'
Running tests with x = 42.0
ERROR:root:False is not true
.
--
Ran 1 test in 0.001s

OK

However, for my taste such a test is both too complex and too vague. If you
have code that tries to achieve something in different ways then put these
attempts into functions that you can test individually with specific data
that causes them to succeed or fail.





--
Terry Jan Reedy

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

Re: Grapheme clusters, a.k.a.real characters

[Thomas Jollans]

On 19/07/17 04:19, Rustom Mody wrote:
> On Wednesday, July 19, 2017 at 3:00:21 AM UTC+5:30, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> Let me give you one concrete example: the letter "ö". In English, it
>>> is (very occasionally) used to indicate diaeresis, where a pair of
>>> letters is not a double letter - for example, "coöperate". (You can
>>> also hyphenate, "co-operate".) In German, it is the letter "o" with a
>>> pronunciation mark (umlaut), and is considered the same letter as "o".
>>> In Swedish, it is a distinct letter, alphabetized last (following z,
>>> å, and ä, in that order). But in all these languages, it's represented
>>> the exact same way.
>> The German Wikipedia entry on "ä" calls "ä" a letter ("Buchstabe"):
>>
>>Der Buchstabe Ä (kleingeschrieben ä) ist ein Buchstabe des
>>lateinischen Schriftsystems.
>>
>> Furthermore, it makes a distinction between "ä" the letter and "ä" the
>> "a with a diaeresis:"
>>
>>In guten Druckschriften unterscheiden sich die Umlautpunkte von den
>>zwei Punkten des Tremas: Die Umlautpunkte sind kleiner, stehen näher
>>zusammen und liegen etwas tiefer.
>>
>>In good fonts umlaut dots are different from the two dots of a
>>diaeresis: the umlaut dots are smaller and closer to each other and
>>lie a little lower. [translation mine]
>>
> Very interesting!
> And may I take it that the two different variants — u-umlaut and u-diaresis — 
> of ü are not (yet) given a seat in unicode?
Yes, the tréma/diæresis and the umlaut are two historically distinct
beasts that share appearances and codepoints. (And the question of
whether ÄÖÜẞ are letters in German is rather more subtle than whether
ÅÄÖ are letters in Swedish)

For added confusion there are languages like Dutch which use both the
umlaut (in German loanwords like ‘überhaupt’) and the tréma (in words
like vacuüm).

Other languages, like Turkish, use the umlaut symbol for separate vowels
that are not umlauts (i.e. shifted vowels, like mouse - mice / Maus - Mäuse)

So let's just pretend that characters in general have no meaning?

> Now compare with:
> - hyphen-minus 0x2D
> − minus sign 0x2212
> ‐ hyphen 0x2010
> – en dash 0x2013
> — em dash 0x2014
> ― horizontal bar 0x2015
> … And perhaps another half-dozen

… but then again there's the whole business of Han unification. 


-- Thomas


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

[issue30945] loop.create_server does not detect if the interface is IPv6 enabled

[Yury Selivanov]

Yury Selivanov added the comment:

> Better than trying to detect IPv6 compatibility beforehand would probably to 
> recognize the error and simply ignore it.


+1

--

___
Python tracker 

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

[issue30945] loop.create_server does not detect if the interface is IPv6 enabled

[Antoine Pitrou]

Antoine Pitrou added the comment:

Better than trying to detect IPv6 compatibility beforehand would probably to 
recognize the error and simply ignore it.

Note: errno 99 is EADDRNOTAVAIL.

Something like this could work (untested):

diff --git a/Lib/asyncio/base_events.py b/Lib/asyncio/base_events.py
index 33b8f48..413161a 100644
--- a/Lib/asyncio/base_events.py
+++ b/Lib/asyncio/base_events.py
@@ -1038,6 +1038,11 @@ class BaseEventLoop(events.AbstractEventLoop):
 try:
 sock.bind(sa)
 except OSError as err:
+if err.errno == errno.EADDRNOTAVAIL:
+# See bpo-30945
+sockets.pop()
+sock.close()
+continue
 raise OSError(err.errno, 'error while attempting '
   'to bind on address %r: %s'
   % (sa, err.strerror.lower())) from None

--
nosy: +pitrou
versions: +Python 3.7 -Python 3.4

___
Python tracker 

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

Re: Problem in installing module "pynamical"

[Felipe Bastos Nunes]

Hi! I have no experience on that, but I may ask something that might help:
1- are you aware that it's not safe to use pip directly? It could be safer
to use pip install --user package.
2- Are you able to use virtualenv? This usually let me install packages my
system has problems on working out.

Cya!

Em ter, 18 de jul de 2017 19:00, Saikat Chakraborty 
escreveu:

>   I am using PyCharm Community Edition 2017 with interpreter python 3.6.1.
> I want to install pynamical module.
> But it is showing error. I am posting the error message:
>
> E:\untitled>pip install pynamical
>
>  FileNotFoundError: [WinError 2] The system cannot find the file specified
> error: command
>
> 'c:\\users\\s.chakraborty\\appdata\\local\\programs\\python\\python36\\python.exe'
> failed with exit status 1
>
> Please give me a solutioin.
>
> Thanking you.
> --
>   With Regards
>   Saikat Chakraborty
>  (Doctoral Research Scholar)
>   *Computer Science & Engineering Dept.*
> *NIT Rourkela,Rourkela,Orissa, India*
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: rpy2

[Felipe Bastos Nunes]

Hey, I have no experience on it, but maybe I'm able to help. How are you
tryin to install it? Pip? 2 or 3? Virtualenv?

Cya!

Em qua, 19 de jul de 2017 10:22, Larry Martell 
escreveu:

> Anyone here any experience with the rpy2 package? I am having trouble
> getting it to install, and I have posted to the rpy mailing list, put
> a question on SO, and even emailed the author, but I have received no
> replies. Before I post details I wanted to see if anyone here can
> possibly help me.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30931] Race condition in asyncore may access the wrong dispatcher

[Nir Soffer]

Nir Soffer added the comment:

Adding more info after discussion in github.

After polling readable/writeable dispatchers, asyncore.poll(2) receive a list 
of ready file descriptors, and invoke callbacks on the dispatcher objects.

If a dispatchers is closed and and a new dispatcher is created, the new 
dispatcher may get the same file descriptor. If the file descriptor was in the 
ready list returned from poll()/select(), asyncore may try to invoke one of the 
callbacks (e.g. handle_write) on the new dispatcher.

Here is an example in asycore.poll()

r, w, e = select.select(r, w, e, timeout)

for fd in r:
obj = map.get(fd)
if obj is None:
continue
read(obj)

read close obj, removing fd from map, then creates a new one
getting the same fd...

for fd in w:
obj = map.get(fd)

this get the new object from the map, instead of the closed one.

if obj is None:
continue
write(obj)

invoke write on the wrong socket, which is not writable

for fd in e:
obj = map.get(fd)

same issue here

if obj is None:
continue
_exception(obj)


asyncore.poll2() has same issue:

r = pollster.poll(timeout)
for fd, flags in r:
obj = map.get(fd)
if obj is None:
continue
readwrite(obj, flags)

fd may have been closed and recreated by in a previous iteration of the loop.

This issue is demonstrated in the failing test:
https://github.com/python/cpython/pull/2707/commits/5aeb0098d2347984f3a89cf036c305edd2b8382b

--
title: Race condition in asyncore wrongly closes channel -> Race condition in 
asyncore may access the wrong dispatcher

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Chris Angelico]

On Thu, Jul 20, 2017 at 1:45 AM, Marko Rauhamaa  wrote:
> So let's assume we will expand str to accommodate the requirements of
> grapheme clusters.
>
> All existing code would still produce only traditional strings. The only
> way to introduce the new "super code points" is by invoking the
> str.canonical() method:
>
> text = "hyvää yötä".canonical()
>
> In this case text would still be a fully traditional string because both
> ä and ö are represented by a single code point in NFC. However:
>
> >>> q = unicodedata.normalize("NFC", "aq̈u")
> >>> len(q)
> 4
> >>> text = q.canonical()
> >>> len(text)
> 3
> >>> t[0]
> "a"
> >>> t[1]
> "q̈"
> >>> t[2]
> "u"
> >>> q2 = unicodedata.normalize("NFC", text)
> >>> len(q2)
> 4
> >>> text.encode()
> b'aq\xcc\x88u'
> >>> q.encode()
> b'aq\xcc\x88u'

Ahh, I see what you're looking at. This is fundamentally very similar
to what was suggested a few hundred posts ago: a function in the
unicodedata module which yields a string's combined characters as
units. So you only see this when you actually want it, and the process
of creating it is a form of iterating over the string.

This could easily be done, as a class or function in unicodedata,
without any language-level support. It might even already exist on
PyPI.

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

Re: Grapheme clusters, a.k.a.real characters

[Marko Rauhamaa]

Chris Angelico :

> Now, this is a performance question, and it's not unreasonable to talk
> about semantics first and let performance wait for later. But when you
> consider how many ASCII-only strings Python uses internally (the names
> of basically every global function and every attribute in every stdlib
> module), and how you'll be enlarging those by a factor of 16 *and*
> making every character lookup require two pointer reads, it's pretty
> much a non-starter.

It's not that difficult or costly.

> Also, this system has the nasty implication that the creation of a new
> combining character will fundamentally change the way a string
> behaves.

If you go with a new Text class, you don't face any
backward-compatibility issues.

If you go with expanding str, you can run into some minor issues.

> But if combining characters behave fundamentally differently to
> others, there would be a change in string representation when U+1DF6
> became a combining character. That's going to cause MASSIVE upheaval.
> I don't think there's any solution to that, but if you can find one,
> do please elaborate.

So let's assume we will expand str to accommodate the requirements of
grapheme clusters.

All existing code would still produce only traditional strings. The only
way to introduce the new "super code points" is by invoking the
str.canonical() method:

text = "hyvää yötä".canonical()

In this case text would still be a fully traditional string because both
ä and ö are represented by a single code point in NFC. However:

>>> q = unicodedata.normalize("NFC", "aq̈u")
>>> len(q)
4
>>> text = q.canonical()
>>> len(text)
3
>>> t[0]
"a"
>>> t[1]
"q̈"
>>> t[2]
"u"
>>> q2 = unicodedata.normalize("NFC", text)
>>> len(q2)
4
>>> text.encode()
b'aq\xcc\x88u'
>>> q.encode()
b'aq\xcc\x88u'

We *could* also add a literal notation for canonical strings:

>>> re.match(rc"[qq̈]x", c"q̈x")
...

Of course, str.canonical() could be expressed as:

>>> len(unicode.normalize("Python-Canonical", q))
3

but I think str.canonical() would deserve a place in the, well, canon.


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

[issue30931] Race condition in asyncore wrongly closes channel

[Jaume]

Changes by Jaume :


--
pull_requests: +2823

___
Python tracker 

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

SIGSEGV and SIGILL inside PyCFunction_Call

[Anders Wegge Keller]

 I have an ongoing issue with my usenet setup. I'm that one dude who don't
want to learn perl. That means that I have to build inn from source, so I
can enable the python interpreter. That's not so bad, and the errors that
show up have been something that I have been able to figure out by myself.
At least up until now. I have an almost 100% repeatable crash, when nnrpd
performs the user authentication step. Backtracing the core dum gives this:

#0  0x564a864e2d63 in ?? ()
#1  0x7f9609567091 in call_function (oparg=, 
pp_stack=0x7ffda2d801b0) at ../Python/ceval.c:4352

Note:   Line 4352 C_TRACE(x, PyCFunction_Call(func,callargs,NULL));

#2  PyEval_EvalFrameEx (
f=Frame 0x7f9604758050, for file /etc/news/filter/nnrpd_auth.py, 
line 67, in __init__ (self=

[issue28638] Optimize namedtuple creation

[Guido van Rossum]

Guido van Rossum added the comment:

Yeah, it looks like the standard `_pickle` and `pickle` solution would work
here.

--

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Random832]

On Tue, Jul 18, 2017, at 22:49, Steve D'Aprano wrote:
> > What about Emoji?
> > U+1F469 WOMAN is two columns wide on its own.
> > U+1F4BB PERSONAL COMPUTER is two columns wide on its own.
> > U+200D ZERO WIDTH JOINER is zero columns wide on its own.
> 
> 
> What about them? In a monospaced font, they should follow the same rules
> I used
> above: either 0, 1 or 2 column wide.

You snipped the important part - the fact that the whole sequence of
three code points U+1F469 U+200D U+1F4BB is a single grapheme cluster
two columns wide.

You also ignored all of the other examples in my post. Did you even read
anything beyond what you snipped?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Random832]

On Tue, Jul 18, 2017, at 19:21, Gregory Ewing wrote:
> Random832 wrote:
> > What about Emoji?
> > U+1F469 WOMAN is two columns wide on its own.
> > U+1F4BB PERSONAL COMPUTER is two columns wide on its own.
> 
> The term "emoji" is becoming rather strained these days.
> The idea of "woman" and "personal computer" being emotions
> is an interesting one...

Emoji comes from Japanese 絵文字 - 絵(E) picture, 文字(moji) character. It is
not in fact etymologically related to the native English term
"emoticon", which is no longer in common usage.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: rpy2

[Larry Martell]

On Wed, Jul 19, 2017 at 10:49 AM, Felipe Bastos Nunes
 wrote:
> Hey, I have no experience on it, but maybe I'm able to help. How are you
> tryin to install it? Pip? 2 or 3? Virtualenv?

python2.7, using pip, on Redhat 6, R version 3.3.3:

Collecting rpy2
  Using cached rpy2-2.8.6.tar.gz
Requirement already satisfied (use --upgrade to upgrade): six in
/usr/local/lib/python2.7/site-packages (from rpy2)
Requirement already satisfied (use --upgrade to upgrade):
singledispatch in /usr/local/lib/python2.7/site-packages (from rpy2)
Installing collected packages: rpy2
  Running setup.py install for rpy2 ... error
Complete output from command /usr/local/bin/python2.7 -u -c
"import setuptools,
tokenize;__file__='/tmp/pip-build-eFwk3n/rpy2/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__,
'exec'))" install --record /tmp/pip-w5v7yg-record/install-record.txt
--single-version-externally-managed --compile:
R version 3.3.3 (2017-03-06) -- "Another Canoe"
/usr/local/lib64/R/bin/R CMD config --ldflags
/usr/local/lib64/R/bin/R CMD config --cppflags

Compilation parameters for rpy2's C components:
include_dirs= ['/usr/local/lib64/R/include']
library_dirs= ['/usr/local/lib64/R/lib']
libraries   = ['Rblas', 'gfortran', 'm', 'readline',
'pcre', 'lzma', 'bz2', 'z', 'rt', 'dl', 'm']
extra_link_args = ['-Wl,--export-dynamic', '-fopenmp',
'-Wl,--whole-archive', '/usr/local/lib64/R/lib/libR.a',
'-Wl,--no-whole-archive']

running install
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/rpy2
copying ./rpy/__init__.py -> build/lib.linux-x86_64-2.7/rpy2
copying ./rpy/tests_rpy_classic.py -> build/lib.linux-x86_64-2.7/rpy2
creating build/temp.linux-x86_64-2.7/rpy
creating build/temp.linux-x86_64-2.7/rpy/rinterface
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3
-Wall -Wstrict-prototypes -fPIC -I./rpy/rinterface
-I/usr/local/lib64/R/include -c ./rpy/rinterface/r_utils.c -o
build/temp.linux-x86_64-2.7/./rpy/rinterface/r_utils.o
In file included from /usr/local/lib64/R/include/Rdefines.h:36,
 from ./rpy/rinterface/r_utils.c:23:
/usr/local/lib64/R/include/R_ext/Memory.h:51: warning: function
declaration isn’t a prototype
In file included from /usr/local/lib64/R/include/Rdefines.h:40,
 from ./rpy/rinterface/r_utils.c:23:
/usr/local/lib64/R/include/Rinternals.h:886: warning: function
declaration isn’t a prototype
ar rc build/temp.linux-x86_64-2.7/libr_utils.a
build/temp.linux-x86_64-2.7/./rpy/rinterface/r_utils.o
running build_ext
R version 3.3.3 (2017-03-06) -- "Another Canoe"
building 'rpy2.rinterface._rinterface' extension
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3
-Wall -Wstrict-prototypes -fPIC -DR_INTERFACE_PTRS=1
-DHAVE_POSIX_SIGJMP=1 -DRIF_HAS_RSIGHAND=1 -DCSTACK_DEFNS=1
-DHAS_READLINE=1 -I./rpy/rinterface -I/usr/local/lib64/R/include
-I/usr/local/include/python2.7 -c ./rpy/rinterface/_rinterface.c -o
build/temp.linux-x86_64-2.7/./rpy/rinterface/_rinterface.o
In file included from /usr/local/include/python2.7/Python.h:8,
 from ./rpy/rinterface/_rinterface.c:49:
/usr/local/include/python2.7/pyconfig.h:1188:1: warning:
"_POSIX_C_SOURCE" redefined
In file included from /usr/include/signal.h:29,
 from ./rpy/rinterface/_rinterface.c:45:
/usr/include/features.h:213:1: warning: this is the location of
the previous definition
In file included from /usr/local/lib64/R/include/R.h:80,
 from ./rpy/rinterface/_rinterface.h:8,
 from ./rpy/rinterface/_rinterface.c:52:
/usr/local/lib64/R/include/R_ext/Memory.h:51: warning: function
declaration isn’t a prototype
In file included from ./rpy/rinterface/_rinterface.h:9,
 from ./rpy/rinterface/_rinterface.c:52:
/usr/local/lib64/R/include/Rinternals.h:886: warning: function
declaration isn’t a prototype
In file included from ./rpy/rinterface/_rinterface.c:64:
/usr/local/lib64/R/include/Rinterface.h:149: warning: function
declaration isn’t a prototype
In file included from ./rpy/rinterface/_rinterface.c:73:
/usr/local/lib64/R/include/R_ext/Rdynload.h:36: warning: function
declaration isn’t a prototype
In file included from ./rpy/rinterface/_rinterface.c:116:
./rpy/rinterface/embeddedr.c: In function ‘SexpObject_clear’:
./rpy/rinterface/embeddedr.c:48: warning: unused variable ‘res’
In file included from ./rpy/rinterface/_rinterface.c:119:
./rpy/rinterface/sexp.c: In function ‘Sexp_init’:
./rpy/rinterface/sexp.c:742: warning: unused variable ‘copy’
./rpy/rinterface/_rinterface.c: At top level:
./rpy/rinterface/_rinterface.h:203: warning:

Re: Grapheme clusters, a.k.a.real characters

[Chris Angelico]

On Wed, Jul 19, 2017 at 11:42 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> Perhaps we don't have the same understanding of "constant time". Or
>> are you saying that you actually store and represent this as those
>> arbitrary-precision integers? Every character of every string has to
>> be a multiprecision integer?
>
> Yes, although feel free to optimize. The internal implementation isn't
> important but those "multiprecision" integers are part of an outward
> interface. So you could have:
>
> >>> for c in Text("aq̈u \U0001F64B\U0001F3FF\u200D\u2642\uFE0F"):
> ... print(c)
> ...
> 97
> 1895826184
> 117
> 32
> 5152920508016097895476141586773579
>
> (Note, though, that Python3 only has integers, there's no
> "multiprecision" about them.)

I said "multiprecision" because that's what the low-level
arbitrary-precision-integer library calls them - GNU Multiprecision
Integer [1].

Somehow you're going to have to store those in an indexable way, and
since you can't fit arbitrary-precision data into fixed-width slots,
O(1) addressing is going to require external storage. Basically,
you're representing a string as if it were a tuple of integers. That
makes fine sense semantically, but it's pretty costly:

>>> sys.getsizeof("hello, world")
61
>>> sys.getsizeof(tuple("hello, world"))
144

That's just for the tuple itself; then you need to represent the
actual numbers. Each one will require an addressable memory
allocation, which basically means a minimum of 8 bytes (on my 64-bit
system; you'd save a bit on a 32-bit Python, but most people don't use
those now). So every character in your string requires an 8-byte
pointer plus an 8-byte value. In contrast, current CPython requires
*at most* four bytes per character, and for many strings, requires
only one byte per character - possible only because the data is kept
as an array, not as external references.

Now, this is a performance question, and it's not unreasonable to talk
about semantics first and let performance wait for later. But when you
consider how many ASCII-only strings Python uses internally (the names
of basically every global function and every attribute in every stdlib
module), and how you'll be enlarging those by a factor of 16 *and*
making every character lookup require two pointer reads, it's pretty
much a non-starter.

There MIGHT be something to be done using a sentinel value that
represents "the actual value is somewhere else". However, I'm not sure
how you could do that cleanly in a one-byte-per-char string other than
maintaining some external table. So here's the best I can come up with
for efficiency - and it suffers horrendously from complexity:

* Strings with all codepoints < 256 are represented as they currently
are (one byte per char). There are no combining characters in the
first 256 codepoints anyway.
* Strings with all codepoints < 65536 and no combining characters,
ditto (two bytes per char).
* Strings with any combining characters in them are stored in four
bytes per char even if all codepoints are <65536.
* Any time a character consists of a single base with no combining, it
is stored in UTF-32.
* Combined characters are stored in the primary array as 0x8000
plus the index into a secondary array where these values are stored.
* The secondary array has a pointer for each combined character
(ignoring single-code-point characters), probably to a Python integer
object for simplicity.

This scheme allows a maximum of two billion combined characters in any
string. Worst case, "a\u0303"*0x8000 is a four billion character
string that simply can't be represented; but long before that, you'll
run out of space to allocate all those large integers. (Current
CPython represents that string in 8GB of memory. Enough to push me
into the swapper - I have only 16GB in this system and a lot of it is
in use - but nothing I can't handle.) It also has the advantage that
most strings won't change in representation. However, the complexity
is insane; I don't want to be the one to write all the unit tests to
make sure everything behaves as advertised!

Also, this system has the nasty implication that the creation of a new
combining character will fundamentally change the way a string
behaves. That means that running a slightly older version of Python
could potentially cause, not errors, but subtly different behaviour.
With Python 2.7, 3.4, 3.5, 3.6, and 3.7, I have four different major
Unicode versions, which means plenty of potential for newly-allocated
codepoints in newer Pythons. That's not usually a problem, as it only
affects a few things in the unicodedata module:

rosuav@sikorsky:~$ python3.4 -c "import unicodedata;
print(unicodedata.name('\U0001f917'))"
Traceback (most recent call last):
  File "", line 1, in 
ValueError: no such name
rosuav@sikorsky:~$ python3.5 -c "import unicodedata;
print(unicodedata.name('\U0001f917'))"
HUGGING FACE


rosuav@sikorsky:~$ 

[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

[Louie Lu]

Louie Lu added the comment:

After checking source code, I found that is my fault on the test code. After 
the blocker PR 2754 been merged, I'll fix this issue.

--

___
Python tracker 

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

[issue30965] Unexpected behavior of operator "in"

[Mihai Cara]

Mihai Cara added the comment:

I am sure that some time ago I read that `in` is a comparison operator but I 
forgot it and I was thinking that (x in y) would be equivalent to (replaced 
with) the return value of y.__contains__(x).

--

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Marko Rauhamaa]

Grant Edwards :

> On 2017-07-19, Gregory Ewing  wrote:
>> Grant Edwards wrote:
>>>vacuum, continuum, squush, fortuuned
>>
>> Fortuuned? Where did you find that?
>
> It was in the scowl-7.1 wordlist I had laying around:
>
>   http://wordlist.aspell.net/
>
> However, the scowl website now claims not to know about it:
>
>   http://app.aspell.net/lookup?dict=en_US;words=fortuuned

Finnish is well-endowed in that respect:

   suu
   puu
   kuu
   huuli
   tuuli
   uusi
   uuni
   kaipuu
   ...

In a great irony of fate, though, Finnish completely lacks the "w"!


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

[issue30965] Unexpected behavior of operator "in"

[Mihai Cara]

Mihai Cara added the comment:

Thank you! It was my fault: I was not expecting `in` to be a comparison 
operator.

--

___
Python tracker 

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

[issue30970] return-value of filecmp.dircmp.report_*

[R. David Murray]

R. David Murray added the comment:

Thanks for wanting to improve Python.  However, the purpose of those function 
is to *print* the result.  They intentionally do not have return values.

All of the values that you would have these functions return are accessible via 
attributes already.

--
nosy: +r.david.murray
resolution:  -> rejected
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

Re: Grapheme clusters, a.k.a.real characters

[Grant Edwards]

On 2017-07-19, Gregory Ewing  wrote:
> Grant Edwards wrote:
>>vacuum, continuum, squush, fortuuned
>
> Fortuuned? Where did you find that?

It was in the scowl-7.1 wordlist I had laying around:

  http://wordlist.aspell.net/

However, the scowl website now claims not to know about it:

  http://app.aspell.net/lookup?dict=en_US;words=fortuuned

> Google gives me a bizarre set of results, none of which
> appear to be an English dictionary definition.

Maybe it was a mistaken spelling of 'fortuned'?

-- 
Grant Edwards   grant.b.edwardsYow! PEGGY FLEMMING is
  at   stealing BASKET BALLS to
  gmail.comfeed the babies in VERMONT.

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

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

[Masayuki Yamamoto]

Masayuki Yamamoto added the comment:

oh, I found a mistake.
- replace Py_LIMITED_API with Py_BUILD_CORE on Include/pythread.h Py_tss_t 
definition

--

___
Python tracker 

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

[issue30969] Docs should say that `x is z or x == z` is used for `x in y` in containers that do not implement `__contains__`

[R. David Murray]

R. David Murray added the comment:

I think you change is appropriate given that the "equivalent to" for the built 
in iterators contains the 'is' expression.

However, I also think we should drop that second whole paragraph, and in the 
previous paragraph say "...but are :term:`iterable`...".  Because conceptually 
what we do is iterate whatever we're given if iter doesn't return a TypeError, 
and it is iter that handles the fallback to the older __getitem__ protocol.  I 
don't see why we should re-explain the iteration protocol in the docs for 'in'. 
 (I haven't looked at how this is actually implemented, but the implementation 
ought to be equivalent to that or we will eventually run into bugs.)  I don't 
think this would result in any loss of precision or understandability, and in 
fact I think it would make it easier to understand.

See also issue 27605, which also wants to edit this section slightly.

--
nosy: +r.david.murray, rhettinger

___
Python tracker 

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

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

[Masayuki Yamamoto]

Masayuki Yamamoto added the comment:

Nick and Erik, thank you for the comments! I merged proposal into the PR.

Well, I'm interested in the hide implementation detail for TSS API (lately, 
I've read the python-ideas thread "PEP: Hide implementation details in the C 
API" which Victor opened [1]).

Present, the draft of new API has given two methods for thread key 
initialization for the non-limited API (i.e. Py_tss_NEEDS_INIT for statically, 
PyThread_tss_alloc for dynamic). The static initialization needs implementation 
detail for thread key, but Py_tss_t is designed as an opaque data type based on 
the stable ABI and we don't feel like to open the implementation detail to the 
API client. On the other hand, we'd provide newly thread key (de-)allocation 
functions for the limited API, the API client is able to get an initialized 
value without knowing thread key detail. And also the functions can be used on 
the non-limited API.

Therefore, I think it makes more sense that all API clients use 
PyThread_tss_(alloc|free) regardless of the limited API. The reason is which 
are (1) Py_tss_t behaves as an opaque data type as expected for any API client 
(cannot read and write directly the fields in any case), (2) the API gets more 
consistency (just one method for key initialization on the API client).

TL;DR: I'd suggest to make key type strict, what do you think about below 
changes?

- replace Py_LIMITED_API with Py_BUILD_CORE on Python/pythread.h Py_tss_t 
definition
- use PyThread_tss_(alloc|free) in Modules/_tracemalloc.c
- also use in Modules/_testcapimodule.c

[1] https://mail.python.org/pipermail/python-ideas/2017-July/046399.html

--

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Marko Rauhamaa]

Chris Angelico :

> Perhaps we don't have the same understanding of "constant time". Or
> are you saying that you actually store and represent this as those
> arbitrary-precision integers? Every character of every string has to
> be a multiprecision integer?

Yes, although feel free to optimize. The internal implementation isn't
important but those "multiprecision" integers are part of an outward
interface. So you could have:

>>> for c in Text("aq̈u \U0001F64B\U0001F3FF\u200D\u2642\uFE0F"):
... print(c)
...
97
1895826184
117
32
5152920508016097895476141586773579

(Note, though, that Python3 only has integers, there's no
"multiprecision" about them.)


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

rpy2

[Larry Martell]

Anyone here any experience with the rpy2 package? I am having trouble
getting it to install, and I have posted to the rpy mailing list, put
a question on SO, and even emailed the author, but I have received no
replies. Before I post details I wanted to see if anyone here can
possibly help me.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Chris Angelico]

On Wed, Jul 19, 2017 at 10:13 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Wed, Jul 19, 2017 at 7:53 PM, Marko Rauhamaa  wrote:
>>> Here's a proposal:
>>>
>>>* introduce a building (predefined) class Text
>>>
>>>* conceptually, a Text object is a sequence of "real" characters
>>>
>>>* you can access each "real" character by its position in O(1)
>>>
>>>* the "real" character is defined to be a integer computed as follows
>>>  (in pseudo-Python):
>>>
>>>   string = the NFC normal form of the real character as a string
>>>   rc = 0
>>>   shift = 0
>>>   for codepoint in string:
>>>   rc |= ord(codepoing) << shift
>>>   shift += 6
>>>   return rc
>>>
>>> * t[n] evaluates to an integer
>>
>> A string could consist of 1 base character and N-1 combining
>> characters. Can you still access those combined characters in constant
>> time?
>
> Yes.

Perhaps we don't have the same understanding of "constant time". Or
are you saying that you actually store and represent this as those
arbitrary-precision integers? Every character of every string has to
be a multiprecision integer?

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

[issue30970] return-value of filecmp.dircmp.report_*

[Mihály Mirk]

New submission from Mihály Mirk:

The functions: 
filecmp.dircmp.report()
filecmp.dircmp.report_partial_closure()
filecmp.dircmp.report_full_closure()

do not have return values

--
messages: 298673
nosy: Mihály Mirk
priority: normal
pull_requests: 2822
severity: normal
status: open
title: return-value of filecmp.dircmp.report_*
type: enhancement
versions: Python 3.4, Python 3.5, 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

[issue30576] http.server should support HTTP compression (gzip)

[R. David Murray]

R. David Murray added the comment:

Getting input from python ideas is a great idea :)

--

___
Python tracker 

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

Re: Best way to assert unit test cases with many conditions

[Peter Otten]

Ganesh Pal wrote:

> On Tue, Jul 18, 2017 at 11:02 PM, Dan Strohl  wrote:
> 
>>
>> Like this:
>>
>> Def test_this(self):
>> For i in range(10):
>> with self.subTest('test number %s) % i):
>> self.assertTrue(I <= 5)
>>
>> With the subTest() method, if anything within that subTest fails, it
>> won't stop the process and will continue with the next step.

> Thanks for reading my email and yes you got it right , I am adding bunch
> of
> same subtest and all are similar and sub test that change only  differ in
> parameter.


> But I can’t use the loop that you have mentioned because I want to achieve
> (1) and (2)

> (1) I would want my subtest to have  a *Condition* based on which it  that
> would pass my entire test  if any of the sub-test passed.

Your spec translates to something like:

$ cat stop_on_first_success.py  
import logging

import unittest
import sys

log = logging.getLogger()

class T(unittest.TestCase):
def test_foo(self):
subtests = sorted(
name for name in dir(self) if name.startswith("subtest_foo_")
)
for name in subtests:
method = getattr(self, name)
try:
method()
except Exception as err:
log.error(err)
else:
break
else:
self.fail("no successful subtest")

def subtest_foo_01_int(self):
self.assertTrue(isinstance(x, int))
def subtest_foo_02_42(self):
self.assertEqual(x, 42)
def subtest_foo_03_upper(self):
self.assertEqual(x.upper(), x)

if __name__ == "__main__":
logging.basicConfig()

x = sys.argv.pop(1)
x = eval(x)
print("Running tests with x = {!r}".format(x))

unittest.main()

The x = eval() part is only for demonstration purposes. 

Below's the script output for various incantations. The subtests are 
executed in alphabetical order of the subtest_foo_xxx method names, failures 
are logged, and the loop stops after the first success.

$ python3 stop_on_first_success.py '"foo"'
Running tests with x = 'foo'
ERROR:root:False is not true
ERROR:root:'foo' != 42
ERROR:root:'FOO' != 'foo'
- FOO
+ foo

F
==
FAIL: test_foo (__main__.T)
--
Traceback (most recent call last):
  File "stop_on_first_success.py", line 22, in test_foo
self.fail("no successful subtest")
AssertionError: no successful subtest

--
Ran 1 test in 0.001s

FAILED (failures=1)
$ python3 stop_on_first_success.py '"FOO"'
Running tests with x = 'FOO'
ERROR:root:False is not true
ERROR:root:'FOO' != 42
.
--
Ran 1 test in 0.001s

OK
$ python3 stop_on_first_success.py '42'
Running tests with x = 42
.
--
Ran 1 test in 0.000s

OK
$ python3 stop_on_first_success.py '42.'
Running tests with x = 42.0
ERROR:root:False is not true
.
--
Ran 1 test in 0.001s

OK

However, for my taste such a test is both too complex and too vague. If you 
have code that tries to achieve something in different ways then put these 
attempts into functions that you can test individually with specific data 
that causes them to succeed or fail.


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

Re: Grapheme clusters, a.k.a.real characters

[Marko Rauhamaa]

Chris Angelico :

> On Wed, Jul 19, 2017 at 7:53 PM, Marko Rauhamaa  wrote:
>> Here's a proposal:
>>
>>* introduce a building (predefined) class Text
>>
>>* conceptually, a Text object is a sequence of "real" characters
>>
>>* you can access each "real" character by its position in O(1)
>>
>>* the "real" character is defined to be a integer computed as follows
>>  (in pseudo-Python):
>>
>>   string = the NFC normal form of the real character as a string
>>   rc = 0
>>   shift = 0
>>   for codepoint in string:
>>   rc |= ord(codepoing) << shift
>>   shift += 6
>>   return rc
>>
>> * t[n] evaluates to an integer
>
> A string could consist of 1 base character and N-1 combining
> characters. Can you still access those combined characters in constant
> time?

Yes.


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

[issue30969] Docs should say that `x is z or x == z` is used for `x in y` in containers that do not implement `__contains__`

[Antti Haapala]

Changes by Antti Haapala :


--
pull_requests: +2820

___
Python tracker 

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

[issue30969] Docs should say that `x is z or x == z` is used for `x in y` in containers that do not implement `__contains__`

[Antti Haapala]

New submission from Antti Haapala:

The doc reference/expressions.srt says that

> For user-defined classes which do not define __contains__() but do 
> define __iter__(), x in y is True if some value z with x == z is 
> produced while iterating over y. If an exception is raised during the 
> iteration, it is as if in raised that exception.

and

> Lastly, the old-style iteration protocol is tried: if a class defines 
> __getitem__(), x in y is True if and only if there is a non-negative 
> integer index i such that x == y[i], and all lower integer indices do 
> not raise IndexError exception. (If any other exception is raised, it 
> is as if in raised that exception).

The documentation doesn't match the implementation, which clearly does `x is y 
or x == y` to check if `x` is the element `y` from a container. Both the 
`__iter__` and the index-iteration method test the elements using `is` first. 
While the document says that `x is x` means that `x == x` should be true, it is 
not true for example in the case of `nan`:

--
assignee: docs@python
components: Documentation
messages: 298671
nosy: docs@python, ztane
priority: normal
severity: normal
status: open
title: Docs should say that `x is z or x == z` is used for `x in y` in 
containers that do not implement `__contains__`
type: enhancement

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[STINNER Victor]

STINNER Victor added the comment:

General note about this issue: while the issie title is "Optimize namedtuple 
creation", it would be *nice* to not only optimization the creation but also 
attribute access by name:
http://bugs.python.org/issue28638#msg298499

Maybe we can have a very fast C implementation using structseq, and a fast 
Python implementation (faster than the current Python implementation) fallback 
for non-CPython.

--

___
Python tracker 

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

[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

[STINNER Victor]

Changes by STINNER Victor :


--
assignee:  -> terry.reedy
components: +IDLE
nosy: +louielu, terry.reedy

___
Python tracker 

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

[issue30917] IDLE: Add idlelib.config.IdleConf unittest

[STINNER Victor]

STINNER Victor added the comment:

Please see bpo-30968: "test_get_font 
(idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x".

--
nosy: +haypo

___
Python tracker 

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

[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

[STINNER Victor]

Changes by STINNER Victor :


--
components: +Tests, Windows
keywords: +buildbot
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
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

[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

[STINNER Victor]

New submission from STINNER Victor:

The build only contains one change:

commit f776eb0f0e046f2fa3a96540bb42d8cf970f6c55

bpo-30917: IDLE: Add config.IdleConf unittests (#2691) Patch by Louie Lu.

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/893/steps/test/logs/stdio

==
FAIL: test_get_font (idlelib.idle_test.test_config.IdleConfTest)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\idlelib\idle_test\test_config.py",
 line 605, in test_get_font
(f['family'], 10 if f['size'] < 10 else f['size'], f['weight']))
AssertionError: Tuples differ: ('Courier New', 9, 'normal') != ('Courier New', 
10, 'normal')

First differing element 1:
9
10

- ('Courier New', 9, 'normal')
? ^

+ ('Courier New', 10, 'normal')
? ^^

--
messages: 298668
nosy: haypo
priority: normal
severity: normal
status: open
title: test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on 
x86 Windows7 3.x

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Chris Angelico]

On Wed, Jul 19, 2017 at 7:53 PM, Marko Rauhamaa  wrote:
> Here's a proposal:
>
>* introduce a building (predefined) class Text
>
>* conceptually, a Text object is a sequence of "real" characters
>
>* you can access each "real" character by its position in O(1)
>
>* the "real" character is defined to be a integer computed as follows
>  (in pseudo-Python):
>
>   string = the NFC normal form of the real character as a string
>   rc = 0
>   shift = 0
>   for codepoint in string:
>   rc |= ord(codepoing) << shift
>   shift += 6
>   return rc
>
> * t[n] evaluates to an integer

A string could consist of 1 base character and N-1 combining
characters. Can you still access those combined characters in constant
time?

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

[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

[STINNER Victor]

STINNER Victor added the comment:

> Anyone who thinks those objects stay alive too long can submit a PR for 
> SimpleQueue and Pool to close them eagerly.

I started with SimpleQueue for the master branch:
https://github.com/python/cpython/pull/2760

--

___
Python tracker 

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

[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +2819

___
Python tracker 

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

Re: Grapheme clusters, a.k.a.real characters

[Rhodri James]

On 19/07/17 09:17, Steven D'Aprano wrote:

On Tue, 18 Jul 2017 16:37:37 +0100, Rhodri James wrote:


(For the record, one of my grandmothers would have been baffled by this
conversation, and the other one would have had definite opinions on
whether accents were distinct characters or not, followed by a
digression into whether "ŵ" and "ŷ" should be suppressed vigorously :-)



Can I ask what nationality your grandmother was, given that she had an
opinion on the suppression of ŵ and ŷ.

And was she for it or against it?


She was a Welsh schoolteacher who went to Australia with her husband. 
As to what her opinion on ŵ and ŷ was, I'm afraid I don't know.  It does 
seem to be one of those things that divides Welsh-speakers; when Acorn 
were developing their version of extended ASCII in the late 80s, they 
asked three different University lecturers in Welsh what extra 
characters they needed, and got three different answers.


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

Re: Best way to assert unit test cases with many conditions

[Ganesh Pal]

>
> Yes.  Just assert each thing as it needs asserting.
>
>
 Asserting each sub test will fail the entire test,  I want the  to pass
the test if any the sub test passes.  If the sub test fail try all cases
and fail for the last one.

Example :



def test_this(self):

  if Sub_test_1():

#passes  then  PASS the  Complete test  i.e. test_this() and  If
sub_test_1() fail then run further subtest!)

 elif run sub_test_2() :

 #Then PASS test_this() and  don't run  next test i.e
sub_test_3(),sub_test_4() etc)

 elif run sub_test_3()

 if sub_test_3()

 #  Then pass  test_this() and  don't run next test  i.e. sub_test_4()
,sub_test_5(). etc)



Regards,

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

[issue29225] distutils.command.install_lib.get_outputs() wrong with extensions built inplace

[Elvis Stansvik]

Elvis Stansvik added the comment:

So feel free to close this issue. The use case was quite marginal anyway, and 
we can always instruct developers to run `build_ext --inplace` when they intend 
to use the distribution out of the source directory (and not have inplace=1 in 
setup.cfg, to allow for installation as well).

If anyone should want to try to remove the limitation wrt installation with 
inplace extensions, I think they're in for quite a bit of work.

--

___
Python tracker 

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

[issue30967] Crash in PyThread_ReInitTLS() in the child process after os.fork() on CentOS 6.5 (Python 2.7.13)

[Thomas Mortensson]

Thomas Mortensson added the comment:

Indeed, #29640 seems remarkably similar. Will attempt to run attached POC code. 
Thank you very much for your help.

--

___
Python tracker 

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

[issue30822] Python implementation of datetime module is not being tested correctly.

[Utkarsh Upadhyay]

Utkarsh Upadhyay added the comment:

So it seems that running the experiments without `-utzdata` would be an 
acceptable fix (assuming that there are no other interesting time-zones worthy 
of explicit testing)?

Can I help in the resolution of this issue, since resolution of 
http://bugs.python.org/issue30302 is tangentially conditioned on it. (-:

--

___
Python tracker 

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

[issue23267] multiprocessing pool.py doesn't close inqueue and outqueue pipes on termination

[Antoine Pitrou]

Antoine Pitrou added the comment:

I think this issue is mistaken.  The reader and writer objects are closed 
automatically when they are destroyed (see Connection.__del__).  The only thing 
that may lack is a way to close them more eagerly.

In any case, I'm closing as a duplicate of issue 30966.

--
dependencies:  -multiprocessing.queues.SimpleQueue leaks 2 fds
nosy: +pitrou
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> multiprocessing.queues.SimpleQueue leaks 2 fds

___
Python tracker 

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