Re: [Python-Dev] Why co_names? Wouldn't be simpler to just use co_consts?
On 29 January 2015 at 04:53, Andrea Griffini wrote: > The names stored in op_names are totally unrelated as they can be attribute > names, module names, global names; you basically don't know much about them > unless you also inspect the actual bytecode using them (and the same name > can be used in completely different ways in different parts of the same code > object). In my opinion introspection code telling me that the name `foo` is > used but not knowing if it's about a global, a module name or an attribute > name is not going to be that useful, on the other hand if you do inspect the > bytecode then using co_consts doesn't make things more complicate. It makes more sense once you know there are a couple of related passes over the AST in the compiler, one to build the symbol table (i.e. just looking at what names exist, where they're defined, and what references them), and a second pass to do the actual code generation (already armed with the symbol details from the symbol table pass). So co_names relates to things that come up in the symbol table pass, while co_consts is only relevant to actual code generation and execution. co_names also doesn't get used in isolation - it's combined with co_varnames and various other attributes in a way that's actually structured more for the convenience of the interpreter eval loop than it is for human readers. As a general rule, by the time we get to the code object level, we're well down into the weeds of needing to think about how the underlying Python interpreter *works*, rather than just what it allows a Python programmer to do. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Results of the python 2.x and 3.x use survey, 2014 edition
Hi! Finally, here are the results: http://blog.frite-camembert.net/python-survey-2014.html Here is the auto-generated Google Forms recap: https://docs.google.com/forms/d/1DqxkNi4GvyTCu54usSdE1DjW29zw1tc52iMeH3z4heg/viewanalytics (more elegant than my matplotlib graphs - I'd have no future as a designer). Overall people started writing more python 3: +15 points in "I ever wrote python 3 code", +10 points in "I write more python 3 than 2". Transition is still ongoing and I hope a tipping point will be soon be attained. Users definitely seem to want to switch to python 3, but dependencies keep them with 2.7 (I weep for the few ones still on 2.5). I also posted the results on HN (https://news.ycombinator.com/item?id=8967645) and reddit (http://www.reddit.com/r/Python/comments/2u3oh0/results_of_the_python_2x_and_3x_use_survey_2014/). Have a nice day, and a year full of python 3! Bruno Cauet ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Found a patch for at bugs.python.org addressing a segfault issue for android but even afternapplying it i'm still getting a segfault. I ran a strace with the verbose option and am attaching it to this update. If not helpful, I'll see if I can hook up the debugging bridge to the tablet but as mentioned earlier there was no helpful info in the anr/traces files On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez wrote: > On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum wrote: >> >> What I see in the strace: >> >> ... load libpython3.4m.so.1.0 >> ... load libm >> ... open /dev/__properties__ and do something to it (what?) >> ... get current time >> ... allocate memory >> ... getuid >> ... segfault >> >> That's not a lot to go on, but it doesn't look as if it has started to >> load modules yet. >> >> Does /dev/__properties__ ring a bell? Not to me. >> > > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > is the code that works with that file. > > This explains it a bit (slides 24-29). Looks like something to do with > interprocess communication. Likely has nothing to do with Python itself. > > Maybe this would be useful? > >> >> That stack trace would be really helpful. >> >> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton wrote: >>> >>> Apologies...I'm not sure what a stack track is, but I do have the >>> strace. Nearest I can tell, it happens due to an open call, though I >>> am probably wrong. >>> Attaching the strace output to this email. I'm going to head back to >>> the documentation and to back out of some Android-related changes in >>> _localemodule.c >>> >>> On Wed, Jan 28, 2015 at 9:43 AM, Guido van Rossum >>> wrote: >>> > There could be a million differences relevant (unicode, ints, ...). >>> > Perhaps >>> > the importlib bootstrap is failing. Perhaps the dynamic loading code >>> > changed. Did you get a stack track? (IIRC strace shows a syscall trace >>> > -- >>> > also useful, but doesn't tell you precisely how it segfaulted.) >>> > >>> > On Wed, Jan 28, 2015 at 6:43 AM, Cyd Haselton >>> > wrote: >>> >> >>> >> All, >>> >> I recently ditched my attempts to port Python 2.7.8 to Android in >>> >> favor of Python 3.4.2. Unfortunately, after using the same configure >>> >> options in the same environment, and modifying the setup.py as needed, >>> >> the newly built binary throws a segfault when the generate-posix-vars >>> >> portion of the build is reached...and when it is run as well (i.e. >>> >> ./python --help, ./python -E -S -m sysconfig, or similar) >>> >> >>> >> I took a strace of ./python, however I'm a bit lost when reviewing it. >>> >> Any ideas as to what may be going on...i.e. why Python 2.7 works but >>> >> 3.x throws a segfault? >>> >> >>> >> Thanks in advance, >>> >> Cyd >>> >> ___ >>> >> Python-Dev mailing list >>> >> Python-Dev@python.org >>> >> https://mail.python.org/mailman/listinfo/python-dev >>> >> Unsubscribe: >>> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>> > >>> > >>> > >>> > >>> > -- >>> > --Guido van Rossum (python.org/~guido) >> >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> > > > > -- > Ryan > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > nul-terminated." > Personal reality distortion fields are immune to contradictory evidence. - > srean > Check out my website: http://kirbyfan64.github.io/ sout-1024 Description: Binary data ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pronouncing on PEP 475 - last call
Hello, As BDFL-delegate, I'd like to pronounce soon on PEP 475 - "Retry system calls failing with EINTR". I've just pushed some small rephrasings, which should appear soon (at https://www.python.org/dev/peps/pep-0475/). There is a working implementation by Charles-François at http://bugs.python.org/issue23285. If you have anything to say, please chime in quick :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Managed to get this out of logcat: F(11914) Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 11914 (python) (libc) [ 01-29 19:30:55.855 23373:23373 F/libc ] Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 23373 (python) Less detail than strace but it seems to be that python is segfaulting libc... On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez wrote: > On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum wrote: >> >> What I see in the strace: >> >> ... load libpython3.4m.so.1.0 >> ... load libm >> ... open /dev/__properties__ and do something to it (what?) >> ... get current time >> ... allocate memory >> ... getuid >> ... segfault >> >> That's not a lot to go on, but it doesn't look as if it has started to >> load modules yet. >> >> Does /dev/__properties__ ring a bell? Not to me. >> > > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > is the code that works with that file. > > This explains it a bit (slides 24-29). Looks like something to do with > interprocess communication. Likely has nothing to do with Python itself. > > Maybe this would be useful? > >> >> That stack trace would be really helpful. >> >> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton wrote: >>> >>> Apologies...I'm not sure what a stack track is, but I do have the >>> strace. Nearest I can tell, it happens due to an open call, though I >>> am probably wrong. >>> Attaching the strace output to this email. I'm going to head back to >>> the documentation and to back out of some Android-related changes in >>> _localemodule.c >>> >>> On Wed, Jan 28, 2015 at 9:43 AM, Guido van Rossum >>> wrote: >>> > There could be a million differences relevant (unicode, ints, ...). >>> > Perhaps >>> > the importlib bootstrap is failing. Perhaps the dynamic loading code >>> > changed. Did you get a stack track? (IIRC strace shows a syscall trace >>> > -- >>> > also useful, but doesn't tell you precisely how it segfaulted.) >>> > >>> > On Wed, Jan 28, 2015 at 6:43 AM, Cyd Haselton >>> > wrote: >>> >> >>> >> All, >>> >> I recently ditched my attempts to port Python 2.7.8 to Android in >>> >> favor of Python 3.4.2. Unfortunately, after using the same configure >>> >> options in the same environment, and modifying the setup.py as needed, >>> >> the newly built binary throws a segfault when the generate-posix-vars >>> >> portion of the build is reached...and when it is run as well (i.e. >>> >> ./python --help, ./python -E -S -m sysconfig, or similar) >>> >> >>> >> I took a strace of ./python, however I'm a bit lost when reviewing it. >>> >> Any ideas as to what may be going on...i.e. why Python 2.7 works but >>> >> 3.x throws a segfault? >>> >> >>> >> Thanks in advance, >>> >> Cyd >>> >> ___ >>> >> Python-Dev mailing list >>> >> Python-Dev@python.org >>> >> https://mail.python.org/mailman/listinfo/python-dev >>> >> Unsubscribe: >>> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>> > >>> > >>> > >>> > >>> > -- >>> > --Guido van Rossum (python.org/~guido) >> >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> > > > > -- > Ryan > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > nul-terminated." > Personal reality distortion fields are immune to contradictory evidence. - > srean > Check out my website: http://kirbyfan64.github.io/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Could you try the steps at http://stackoverflow.com/a/11369475/2097780? They allow you to get a better idea of where libc is crashing. Cyd Haselton wrote: >Managed to get this out of logcat: >F(11914) Fatal signal 11 (SIGSEGV) at 0x (code=1), thread >11914 (python) (libc) > >[ 01-29 19:30:55.855 23373:23373 F/libc ] >Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 23373 (python) > >Less detail than strace but it seems to be that python is segfaulting >libc... > >On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez >wrote: >> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >wrote: >>> >>> What I see in the strace: >>> >>> ... load libpython3.4m.so.1.0 >>> ... load libm >>> ... open /dev/__properties__ and do something to it (what?) >>> ... get current time >>> ... allocate memory >>> ... getuid >>> ... segfault >>> >>> That's not a lot to go on, but it doesn't look as if it has started >to >>> load modules yet. >>> >>> Does /dev/__properties__ ring a bell? Not to me. >>> >> >> >https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> is the code that works with that file. >> >> This explains it a bit (slides 24-29). Looks like something to do >with >> interprocess communication. Likely has nothing to do with Python >itself. >> >> Maybe this would be useful? >> >>> >>> That stack trace would be really helpful. >>> >>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >wrote: Apologies...I'm not sure what a stack track is, but I do have the strace. Nearest I can tell, it happens due to an open call, though >I am probably wrong. Attaching the strace output to this email. I'm going to head back >to the documentation and to back out of some Android-related changes >in _localemodule.c On Wed, Jan 28, 2015 at 9:43 AM, Guido van Rossum > wrote: > There could be a million differences relevant (unicode, ints, >...). > Perhaps > the importlib bootstrap is failing. Perhaps the dynamic loading >code > changed. Did you get a stack track? (IIRC strace shows a syscall >trace > -- > also useful, but doesn't tell you precisely how it segfaulted.) > > On Wed, Jan 28, 2015 at 6:43 AM, Cyd Haselton > > wrote: >> >> All, >> I recently ditched my attempts to port Python 2.7.8 to Android >in >> favor of Python 3.4.2. Unfortunately, after using the same >configure >> options in the same environment, and modifying the setup.py as >needed, >> the newly built binary throws a segfault when the >generate-posix-vars >> portion of the build is reached...and when it is run as well >(i.e. >> ./python --help, ./python -E -S -m sysconfig, or similar) >> >> I took a strace of ./python, however I'm a bit lost when >reviewing it. >> Any ideas as to what may be going on...i.e. why Python 2.7 works >but >> 3.x throws a segfault? >> >> Thanks in advance, >> Cyd >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> >https://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > -- > --Guido van Rossum (python.org/~guido) >>> >>> >>> >>> >>> -- >>> --Guido van Rossum (python.org/~guido) >>> >>> ___ >>> Python-Dev mailing list >>> Python-Dev@python.org >>> https://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: >>> >https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >>> >> >> >> >> -- >> Ryan >> If anybody ever asks me why I prefer C++ to C, my answer will be >simple: >> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that >was >> nul-terminated." >> Personal reality distortion fields are immune to contradictory >evidence. - >> srean >> Check out my website: http://kirbyfan64.github.io/ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Check out my website: http://kirbyfan64.github.io/___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
