Re: SIGSEGV and SIGILL inside PyCFunction_Call

Anders Wegge Keller writes: > ... > The trouble with that is that nnrpd is a system daemon, and as such is a > bit difficult to trace in place. That's why I am asking for help Often, you can run a (typical) daemon in non-daemon mode -- specifically to debug problems (a usual requirement during d

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

On Fri, Jul 21, 2017 at 1:20 PM, Steve D'Aprano wrote: > On Fri, 21 Jul 2017 04:05 am, Marko Rauhamaa wrote: > >> If any string code point is 1114112 or greater > > By definition, no Unicode code point can ever have an ordinal value greater > than > 0x10 = 1114111. > > So I don't know what yo

Re: Problem

On Fri, 21 Jul 2017 05:19 am, Hongze Liu wrote: > Hello Python, > > I encountered this problem: Can you tell us *how* you encountered this problem? How were you invoking Python. It makes a BIG difference if you are invoking it by just launching the Python interactive interpreter with no extra c

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

On Fri, 21 Jul 2017 04:05 am, Marko Rauhamaa wrote: > If any string code point is 1114112 or greater By definition, no Unicode code point can ever have an ordinal value greater than 0x10 = 1114111. So I don't know what you're talking about, but it isn't Unicode. If you want to invent your ow

Re: Your feedback on our free Advanced Python tutorial

On 20 Jul 2017 3:03 p.m., "Aude Barral, CodinGame" wrote: Hi everyone, I am co-founder of a startup called CodinGame. A few days ago we've launched a project: Tech.io . It's a free knowledge-sharing platform that allows tech professionals to learn new programming concepts thro

Re: scandir slower than listdir

On 20 July 2017 at 21:43, Skip Montanaro wrote: > scandir returns an iterator of DirEntry objects which contain more > > information than the mere name. > > > > As I recall, the motivation for scandir was to avoid subsequent system > calls, so it will be slower than listdir the way you've tested

Re: Your feedback on our free Advanced Python tutorial

Hi Aude, Unfortunately I don't have time to review or endorse your Python materials. Good luck, --Guido On Wed, Jul 19, 2017 at 9:44 AM, Aude Barral, CodinGame wrote: > Hi everyone, > > I am co-founder of a startup called CodinGame. > > A few days ago we've launched a project: Tech.io

Re: Nesting concurrent.futures.ThreadPoolExecutor

On 07/20/2017 12:44 PM, Andrew McLean wrote: I have a program where I am currently using a concurrent.futures.ThreadPoolExecutor to run multiple tasks concurrently. These tasks are typically I/O bound, involving access to local databases and remote REST APIs. However, these tasks could themsel

Nesting concurrent.futures.ThreadPoolExecutor

I have a program where I am currently using a concurrent.futures.ThreadPoolExecutor to run multiple tasks concurrently. These tasks are typically I/O bound, involving access to local databases and remote REST APIs. However, these tasks could themselves be split into subtasks, which would also b

Re: Problem

On Fri, Jul 21, 2017 at 6:32 AM, Terry Reedy wrote: > Because the problem is with your code. Somewhere in one of the files in > your ok package passes a string or bytes containing \x00 to something that > results in an attempt to compile the string. Start with storage.py, > contains(), line 18 a

Re: Problem

On 7/20/2017 3:19 PM, Hongze Liu wrote: Hello Python, I encountered this problem: File "C:\Users\Hongze\AppData\Local\Programs\python\Python36\lib\runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "C:\Users\Hongze\AppData\Local\Programs\python\Python36\lib\runpy.py

Re: Problem

Hi, Can you post some code? Thank you. On Thu, Jul 20, 2017 at 3:19 PM, Hongze Liu wrote: > Hello Python, > > I encountered this problem: > File "C:\Users\Hongze\AppData\Local\Programs\python\Python36\lib\runpy.py", > line 193, in _run_module_as_main > "__main__", mod_spec) > File "C:\Use

Problem

Hello Python, I encountered this problem: File "C:\Users\Hongze\AppData\Local\Programs\python\Python36\lib\runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "C:\Users\Hongze\AppData\Local\Programs\python\Python36\lib\runpy.py", line 85, in _run_code exec(code, run_g

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

Chris Angelico : > 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. The existing str implementation could be tweaked

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

On Fri, Jul 21, 2017 at 2:10 AM, Random832 wrote: > On Thu, Jul 20, 2017, at 01:15, Steven D'Aprano wrote: >> 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 decom

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

On Fri, Jul 21, 2017 at 2:46 AM, Rhodri James wrote: > On 20/07/17 16:18, Rustom Mody wrote: >> >> So coming to the point: >> Its not whether Einstein or Mencken¹ is right but rather that Mencken >> applies to >> 1 whereas Einstein applies to 3 >> >> And (IMHO) text should be squarely classed in

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

On 20/07/17 16:18, Rustom Mody wrote: So coming to the point: Its not whether Einstein or Mencken¹ is right but rather that Mencken applies to 1 whereas Einstein applies to 3 And (IMHO) text should be squarely classed in 3 not 1 The gmas of this world have made shopping lists, written (and ta

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

On Thu, Jul 20, 2017, at 01:15, Steven D'Aprano wrote: > 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: How a

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

On Thursday, July 20, 2017 at 3:21:52 AM UTC+5:30, Rick Johnson wrote: > 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

Re: SIGSEGV and SIGILL inside PyCFunction_Call

På Thu, 20 Jul 2017 07:44:26 +0200 dieter skrev: > Anders Wegge Keller writes: ... >> 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

Re: scandir slower than listdir

On Thu, 20 Jul 2017 03:33 pm, Torsten Bronger wrote: > 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() - s

Re: scandir slower than listdir

scandir returns an iterator of DirEntry objects which contain more > information than the mere name. > As I recall, the motivation for scandir was to avoid subsequent system calls, so it will be slower than listdir the way you've tested it. If you add in the cost of fetching the other bits Terry m