Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator
+1 for scandir. -1 for iterdir(scandir sounds fancier). - for windows_wildcard. Tim Delaney wrote: >On 27 June 2014 09:28, MRAB wrote: > >> Personally, I'd prefer the name 'iterdir' because it emphasises that >> it's an iterator. > > >Exactly what I was going to post (with the added note that thee's an >obvious symmetry with listdir). > >+1 for iterdir rather than scandir > >Other than that: > >+1 for adding scandir to the stdlib >-1 for windows_wildcard (it would be an attractive nuisance to write >windows-only code) > >Tim Delaney > > > > >___ >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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ 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] Move selected documentation repos to PSF BitBucket account?
I can agree with most of these points. Some more things to consider: - Git is 20x faster than Hg (that's 99% of the reason I switched and hate using Darcs) - People attached to Hg can use Hg-Git; I've used it several times with nice results. It can also be used to easily convert Hg repos to Git (I was using it to maintain a Pygments mirror, but got bored) - GitHub is much nicer than BitBucket. I usually look for a git mirror of a BitBucket repo since I hate browsing on BB - Even Plan9Port moved from Hg to GitHub a few days ago - Some Google devs even host their projects on GitHub (not Google Code) Thank goodness no one has mentioned CodePlex. BTW, I frown on projects that choose something largely inferior over a better choice just because "one is written in X language." Now, if python.org was written in Ruby, that would just be sad, but certain things just don't matter. Like DVCS's. Guido van Rossum wrote: >On Sat, Nov 22, 2014 at 10:49 PM, Nick Coghlan >wrote: > >> More generally, I'm very, very disappointed to see folks so willing >to >> abandon fellow community members for the sake of following the crowd. >> Perhaps we should all just abandon Python and learn Ruby or >JavaScript >> because they're better at getting press in Silicon Valley? > > >That's a really low blow, Nick. > >I think these are the facts: > >- Hg/Git are equivalent in functionality (at least to the extent that >the >difference can't be used to force a decision), and ditto for >BitBucket/GitHub, with one crucial exception (see below) > >- We're currently using Hg for most projects under the PSF umbrella >(however, there's https://github.com/python/pythondotorg) > >- Moving from Hg to Git is a fair amount of one-time work (converting >repos) and is inconvenient to core devs who aren't already used to Git >(learning a new workflow) > >- Most newer third-party projects are already on GitHub > >- GitHub is way more popular than BitBucket and slated for long-term >success > >But here's the kicker for me: **A DVCS repo is a social network, so it >matters in a functional way what everyone else is using.** > >So I give you that if you want a quick move into the modern world, >while >keeping the older generation of core devs happy (not counting myself >:-), >BitBucket has the lowest cost of entry. But I strongly believe that if >we >want to do the right thing for the long term, we should switch to >GitHub. I >promise you that once the pain of the switch is over you will feel much >better about it. I am also convinced that we'll get more contributions >this >way. > >Note: I am not (yet) proposing we switch CPython itself. Switching it >would >be a lot of work, and it is specifically out of scope for this >discussion. > >-- >--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 -- 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
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
Georg Brandl wrote: >On 11/23/2014 07:03 PM, Ryan wrote: >> I can agree with most of these points. Some more things to consider: >> >> - Git is 20x faster than Hg (that's 99% of the reason I switched and >hate using >> Darcs) > >You won't get much traction with this argument around here. As long as >there >aren't specific complaints about slowness (which probably could be >fixed by a >discussion on mercurial-devel), Hg is "fast enough", just like Python >is "fast >enough" compared to C. (Otherwise, why bother.) I know, but, when checking out large repos, it stings a little. > >> - GitHub is much nicer than BitBucket. I usually look for a git >mirror of a >> BitBucket repo since I hate browsing on BB > >I agree, Github's UI is nicer than BB. It is also true that most >features >that are introduced on BB are "inspired" by GH. > >> - Even Plan9Port moved from Hg to GitHub a few days ago > >Projects move all the time. Why is this one special? Because, for ages, everything related to Rob Pike used Google Code and Mercurial, largely because he works at Google. > >> - Some Google devs even host their projects on GitHub (not Google >Code) >> >> Thank goodness no one has mentioned CodePlex. >> >> BTW, I frown on projects that choose something largely inferior over >a better >> choice just because "one is written in X language." Now, if >python.org >> <http://python.org> was written in Ruby, that would just be sad, but >certain >> things just don't matter. Like DVCS's. > >You can read up PEP 374 for the reasons for Hg. The main reasons >against git >were lacking Windows support (which probably is good enough now) and >developer >preference. > >Georg > > >___ >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 -- 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
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
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
No; I was looking for all uses of _PyRaw_Strdup. Surprisingly, it's used only a few times. Cyd Haselton wrote: >Question: >When you said earlier that you found the problem by using grep...were >you looking for places where strdup called locale? > >On January 30, 2015 7:52:47 PM CST, Ryan Gonzalez >wrote: >>Regardless, if you're looking to toy more with stuff like this, I'd >>highly >>recommend dual-booting with Ubuntu, which is what I'm doing now. (Now >I >>rarely ever boot into Windows!) >> >>On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez >>wrote: >> >>> Do you have just the SDK (which doesn't require Cygwin) or a rooted >>phone? >>> If so, I can upload instructions that don't use the NDK. >>> >>> On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton >>wrote: >>> >>>> This is going to take some time...here's why: >>>> >>>> Downloading and installing the NDK/SDK won't be too hard...I have >to >>>> clear some space...but my primary machine is running Windows 7 and >>I'd >>>> rather swallow hot coals than install Cygwin. I've got next to no >>>> experience with it, other than knowing that the NDK recommends >>against >>>> it. >>>> >>>> I've got a CentOS VM...but it's currently in tarball form on an >>>> external drive for space reasons...and it only has the NDK >>installed. >>>> If I am able to get it back up and running, there's still the task >>of >>>> getting adb connected to my device. from the VM. >>>> >>>> Not saying it's impossible...just that it'll take time...and I'll >>>> probably have to tackle it tomorrow (earliest) or Sunday (latest). >>In >>>> the meantime I'll also check to see if there's anything that can a) >>>> run in an Android terminal and b) can take a stack trace; it would >>be >>>> far, far, far easier than either option above. >>>> >>>> >>>> >>>> On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez >>wrote: >>>> > Do you have the Android SDK and NDK installed? If so... >>>> > >>>> > Using Google, I've created this series of steps, which may (or >may >>not) >>>> > work: >>>> > >>>> > 1. Make sure you have a copy of Python on your computer and make >>sure >>>> that >>>> > it's built with debug symbols. >>>> > >>>> > 2. Run the following commands from a shell with your phone >plugged >>in: >>>> > >>>> > adb forward tcp:5039 tcp:5039 >>>> > adb shell /system/bin/gdbserver tcp:5039 >executable> >>>> > /arm-linux-androideabi-gdb >>>> > >>>> > Now, GDB should have opened, so type the following commands: >>>> > >>>> > set solib-search-path >>>> > file >>>> > target remote :5055 >>>> > run >>>> > >>>> > Now, wait for the program to crash and type: >>>> > >>>> > backtrace >>>> > >>>> > You should now see a complete backtrace in your terminal. To GDB, >>type: >>>> > >>>> > quit >>>> > >>>> > *crosses fingers* >>>> > >>>> > On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton >> >>>> wrote: >>>> >> >>>> >> Unfortunately it is still reporting the same function :-/. >>>> >> >>>> >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez > >>>> wrote: >>>> >> > Yes... >>>> >> > >>>> >> > Can you check if it's crashing in a different function now? >>>> >> > >>>> >> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton >> >>>> >> > wrote: >>>> >> >> >>>> >> >> Yes I did. I did have to enter all the information in >>>> manually...I'm >>>> >> >> not familiar with automated patch application tools and even >>if I >>>> >> >> were, I'm pretty sure I wouldn't have them on my device. >>>> >> >> >>>> >> >> Just so that I'm absolutely sure I got everythin
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Ok...try this (based on http://dan.drown.org/android/howto/gdb.html): - Install BusyBox and a Terminal Emulator - Inside the Terminal Emulator, run: su cd /data/local/tmp wget http://dan.drown.org/android/gdb- static.tar.gz tar zxf gdb-static.tar.gz ./gdb Now, inside gdb, type: set logging file /mnt/sdcard/bt.txt set logging on run Wait for Python to crash, then type: backtrace A backtrace should be printed to the screen and saved to a file named bt.txt on the SD card. After that, type: quit to quit GDB. Send the list the bt.txt file on your SD card. chasel...@gmail.com wrote: >I don't have the SDK either...but my device is rooted. > >Dual-booting is not an option unfortunately...space reasons. I'll do >my best to figure out a way to get the instuctions you sent >implemented, but this may be a deal-breaker for porting Python 3.4.x >for me...I may go back to working on 2.7.x > >Sent from my android device. > >-Original Message- >From: Ryan Gonzalez >To: Cyd Haselton >Cc: Python-Dev >Sent: Fri, 30 Jan 2015 7:53 PM >Subject: Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault > >Regardless, if you're looking to toy more with stuff like this, I'd >highly >recommend dual-booting with Ubuntu, which is what I'm doing now. (Now I >rarely ever boot into Windows!) > >On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez >wrote: > >> Do you have just the SDK (which doesn't require Cygwin) or a rooted >phone? >> If so, I can upload instructions that don't use the NDK. >> >> On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton >wrote: >> >>> This is going to take some time...here's why: >>> >>> Downloading and installing the NDK/SDK won't be too hard...I have to >>> clear some space...but my primary machine is running Windows 7 and >I'd >>> rather swallow hot coals than install Cygwin. I've got next to no >>> experience with it, other than knowing that the NDK recommends >against >>> it. >>> >>> I've got a CentOS VM...but it's currently in tarball form on an >>> external drive for space reasons...and it only has the NDK >installed. >>> If I am able to get it back up and running, there's still the task >of >>> getting adb connected to my device. from the VM. >>> >>> Not saying it's impossible...just that it'll take time...and I'll >>> probably have to tackle it tomorrow (earliest) or Sunday (latest). >In >>> the meantime I'll also check to see if there's anything that can a) >>> run in an Android terminal and b) can take a stack trace; it would >be >>> far, far, far easier than either option above. >>> >>> >>> >>> On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez >wrote: >>> > Do you have the Android SDK and NDK installed? If so... >>> > >>> > Using Google, I've created this series of steps, which may (or may >not) >>> > work: >>> > >>> > 1. Make sure you have a copy of Python on your computer and make >sure >>> that >>> > it's built with debug symbols. >>> > >>> > 2. Run the following commands from a shell with your phone plugged >in: >>> > >>> > adb forward tcp:5039 tcp:5039 >>> > adb shell /system/bin/gdbserver tcp:5039 executable> >>> > /arm-linux-androideabi-gdb >>> > >>> > Now, GDB should have opened, so type the following commands: >>> > >>> > set solib-search-path >>> > file >>> > target remote :5055 >>> > run >>> > >>> > Now, wait for the program to crash and type: >>> > >>> > backtrace >>> > >>> > You should now see a complete backtrace in your terminal. To GDB, >type: >>> > >>> > quit >>> > >>> > *crosses fingers* >>> > >>> > On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton > >>> wrote: >>> >> >>> >> Unfortunately it is still reporting the same function :-/. >>> >> >>> >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez >>> wrote: >>> >> > Yes... >>> >> > >>> >> > Can you check if it's crashing in a different function now? >>> >> > >>> >> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton > >>> >> > wrote: >>> >> >
Re: [Python-Dev] Working on issue 23496: should I use a macro test or an edit to configure.ac?
Thank you so much! Ryan Smith-Roberts wrote: >On Thu, Feb 26, 2015 at 5:13 PM, Ryan Smith-Roberts >wrote: >> I'm not an official cpython developer but ifdef __ANDROID__ is quite >in line >> with other per-platform support (__FreeBSD__, __linux__, etc), as >well as >> already being in use in Modules/_posixsubprocess.c. Is __ANDROID__ >not being >> defined when it should be? > >Might as well spend the time to answer my own question: > >Some Googling indicates that __ANDROID__ is baked into the NDK >toolchain, so it's definitely what one would use to wrap >Android-specific code. > >"__ANDROID__ shall always be defined by the toolchain, without a need >for special flags though, so please rely on that instead in your >code." - David Turner, Android NDK Lead, 2010. >___ >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 -- 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
Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication
Ooooh...that stings. Victor Stinner wrote: >2014-04-08 3:04 GMT+02:00 Steven D'Aprano : >>> > >Python used to have an alias <> for != and I for one miss <> in >3.x. I >>> > >don't think TOOWTDI should be the last word in this debate. >>> > >>> > PEP 401 to the rescue: >>> >>> It occurs to me that since that Aprils' Fools joke is many years old >>> now, we should remove it. >> >> -1 on removal. >> >> It makes a nice Easter Egg, especially now that "import this" has >become >> less of an Easter Egg and more of a standard Python module :-) > >I'm also against the removal of jokes! Removing the antigravity module >would break the backward compatibility! from __futures__ import >braces! > >Ten years ago, we asked me to add the "IPv6" feature in a firewall. I >started to implement the RFC 1924 to have a full support. In the C >language, handling the base 85 is not simple because you need >arithmetic operations on large integers (128 bits). >https://tools.ietf.org/html/rfc1924 > >3 days later, when my code was working, I saw the date of the RFC... I >was young and naive :-) > >Victor >___ >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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ 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] subprocess shell=True on Windows doesn't escape ^ character
Of course! And, why not escape everything else, too? abc -> ^a^b^c echo %PATH% -> ^e^c^h^o^ ^%^P^A^T^H^% In all seriousness, to me this is obvious. When you pass a command to the shell, naturally, certain details are shell-specific. -1. Bad idea. Very bad idea. If you want the ^ to be escaped, do it yourself. Or better yet, don't pass shell=True. anatoly techtonik wrote: >I am banned from tracker, so I post the bug here: > >Normal Windows behavior: > > >hg status --rev ".^1" > M mercurial\commands.py > ? pysptest.py > > >hg status --rev .^1 > abort: unknown revision '.1'! > >So, ^ is an escape character. See >http://www.tomshardware.co.uk/forum/35565-45-when-special-command-line > > >But subprocess doesn't escape it, making cross-platform command fail on >Windows. > >---[cut pysptest.py]-- >import subprocess as sp > ># this fails with ># abort: unknown revision '.1'! >cmd = ['hg', 'status', '--rev', '.^1'] ># this works >#cmd = 'hg status --rev ".^1"' ># this works too >#cmd = ['hg', 'status', '--rev', '.^^1'] > >try: > print sp.check_output(cmd, stderr=sp.STDOUT, shell=True) >except Exception as e: > print e.output >-- > >-- >anatoly t. > > > > >___ >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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ 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] Make extension module initialisation more like Python module initialisation
Nice idea, but some of those may break 3rd party libraries like Boost. Python that have their own equilavent of the Python/C API. Or Even SWIG might experience trouble in one or two of those. Stefan Behnel wrote: >Hi, > >let me revive and summarize this old thread. > >Stefan Behnel, 08.11.2012 13:47: >> I suspect that this will be put into a proper PEP at some point, but >I'd >> like to bring this up for discussion first. This came out of issues >13429 >> and 16392. >> >> http://bugs.python.org/issue13429 >> >> http://bugs.python.org/issue16392 >> >> >> The problem >> === >> >> Python modules and extension modules are not being set up in the same >way. >> For Python modules, the module is created and set up first, then the >module >> code is being executed. For extensions, i.e. shared libraries, the >module >> init function is executed straight away and does both the creation >and >> initialisation. This means that it knows neither the __file__ it is >being >> loaded from nor its package (i.e. its FQMN). This hinders relative >imports >> and resource loading. In Py3, it's also not being added to >sys.modules, >> which means that a (potentially transitive) re-import of the module >will >> really try to reimport it and thus run into an infinite loop when it >> executes the module init function again. And without the FQMN, it's >not >> trivial to correctly add the module to sys.modules either. >> >> We specifically run into this for Cython generated modules, for which >it's >> not uncommon that the module init code has the same level of >complexity as >> that of any 'regular' Python module. Also, the lack of a FQMN and >correct >> file path hinders the compilation of __init__.py modules, i.e. >packages, >> especially when relative imports are being used at module init time. > >The outcome of this discussion was that the extension module import >protocol needs to change in order to provide all necessary information >to >the module init function. > >Brett Cannon proposed to move the module object creation into the >extension >module importer, i.e. outside of the user provided module init >function. >CPython would then load the extension module, create and initialise the >module object (set __file__, __name__, etc.) and pass it into the >module >init function. > >I proposed to make the PyModuleDef struct the new entry point instead >of >just a generic C function, as that would give the module importer all >necessary information about the module to create the module object. The >only missing bit is the entry point for the new module init function. > >Nick Coghlan objected to the proposal of simply extending PyModuleDef >with >an initialiser function, as the struct is part of the stable ABI. > >Alternatives I see: > >1) Expose a struct that points to the extension module's PyModuleDef >struct >and the init function and expose that struct instead. > >2) Expose both the PyModuleDef and the init function as public symbols. > >3) Provide a public C function as entry point that returns both a >PyModuleDef pointer and a module init function pointer. > >4) Change the m_init function pointer in PyModuleDef_base from >func(void) >to func(PyObject*) iff the PyModuleDef struct is exposed as a public >symbol. > >5) Duplicate PyModuleDef and adapt the new one as in 4). > >Alternatives 1) and 2) only differ marginally by the number of public >symbols being exposed. 3) has the advantage of supporting more advanced >setups, e.g. heap allocation for the PyModuleDef struct. 4) is a hack >and >has the disadvantage that the signature of the module init function >cannot >be stored across reinitialisations (PyModuleDef has no "flags" or >"state" >field to remember it). 5) would fix that, i.e. we could add a proper >pointer to the new module init function as well as a flags field for >future >extensions. A similar effect could be achieved by carefully designing >the >struct in 1). > >I think 1-3 are all reasonable ways to do this, although I don't think >3) >will be necessary. 5) would be a clean fix, but has the disadvantage of >duplicating an entire struct just to change one field in it. > >I'm currently leaning towards 1), with a struct that points to >PyModuleDef, >module init function and a flags field for future extensions. I >understand >that this would need to become part of the stable ABI, so explicit >extensibility is important to keep up backwards compatibility. > >Opinions? > >Stefan > > >___ >Python-Dev mailing list >Python-Dev@python.org >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail
Re: [Python-Dev] Deprecating the formatter module
I never realized it existed till now. Considering the usually erratic projects I like do, I can see that coming in use in several in which I had to do odd workarounds. Keep it, but put better documentation. It's needed. Brett Cannon wrote: >At the PyCon CA sprint someone discovered the formatter module had >somewhat >low code coverage. We discovered this is because it's tested by >test_sundry, i.e. it's tested by importing it and that's it. > >We then realized that it isn't really used by anyone (pydoc uses it but >it >should have been using textwrap). Looking at the history of the module >it >has just been a magnet for cleanup revisions and not actual usage or >development since Guido added it back in 1995. > >I have created http://bugs.python.org/issue18716 to deprecate the >formatter >module for removal in Python 3.6 unless someone convinces me otherwise >that >deprecation and removal is the wrong move. > > > > >___ >Python-Dev mailing list >Python-Dev@python.org >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 450 adding statistics module
For the naming, how about changing median(callable) to median.regular? That
way, we don't have to deal with a callable namespace.
Steven D'Aprano wrote:
>On 15/08/13 21:42, Mark Dickinson wrote:
>> The PEP and code look generally good to me.
>>
>> I think the API for median and its variants deserves some wider
>discussion:
>> the reference implementation has a callable 'median', and variant
>callables
>> 'median.low', 'median.high', 'median.grouped'. The pattern of
>attaching
>> the variant callables as attributes on the main callable is unusual,
>and
>> isn't something I've seen elsewhere in the standard library. I'd
>like to
>> see some explanation in the PEP for why it's done this way. (There
>was
>> already some discussion of this on the issue, but that was more
>centered
>> around the implementation than the API.)
>>
>> I'd propose two alternatives for this: either have separate
>functions
>> 'median', 'median_low', 'median_high', etc., or have a single
>function
>> 'median' with a "method" argument that takes a string specifying
>> computation using a particular method. I don't see a really good
>reason to
>> deviate from standard patterns here, and fear that users would find
>the
>> current API surprising.
>
>Alexander Belopolsky has convinced me (off-list) that my current
>implementation is better changed to a more conservative one of a
>callable singleton instance with methods implementing the alternative
>computations. I'll have something like:
>
>
>def _singleton(cls):
> return cls()
>
>
>@_singleton
>class median:
> def __call__(self, data):
> ...
> def low(self, data):
> ...
> ...
>
>
>In my earlier stats module, I had a single median function that took a
>argument to choose between alternatives. I called it "scheme":
>
>median(data, scheme="low")
>
>R uses parameter called "type" to choose between alternate
>calculations, not for median as we are discussing, but for quantiles:
>
>quantile(x, probs ... type = 7, ...).
>
>SAS also uses a similar system, but with different numeric codes. I
>rejected both "type" and "method" as the parameter name since it would
>cause confusion with the usual meanings of those words. I eventually
>decided against this system for two reasons:
>
>- Each scheme ended up needing to be a separate function, for ease of
>both implementation and testing. So I had four private median
>functions, which I put inside a class to act as namespace and avoid
>polluting the main namespace. Then I needed a "master function" to
>select which of the methods should be called, with all the additional
>testing and documentation that entailed.
>
>- The API doesn't really feel very Pythonic to me. For example, we
>write:
>
>mystring.rjust(width)
>dict.items()
>
>rather than mystring.justify(width, "right") or dict.iterate("items").
>So I think individual methods is a better API, and one which is more
>familiar to most Python users. The only innovation (if that's what it
>is) is to have median a callable object.
>
>
>As far as having four separate functions, median, median_low, etc., it
>just doesn't feel right to me. It puts four slight variations of the
>same function into the main namespace, instead of keeping them together
>in a namespace. Names like median_low merely simulates a namespace with
>pseudo-methods separated with underscores instead of dots, only without
>the advantages of a real namespace.
>
>(I treat variance and std dev differently, and make the sample and
>population forms separate top-level functions rather than methods,
>simply because they are so well-known from scientific calculators that
>it is unthinkable to me to do differently. Whenever I use numpy, I am
>surprised all over again that it has only a single variance function.)
>
>
>
>--
>Steven
>___
>Python-Dev mailing list
>Python-Dev@python.org
>http://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>http://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2
How about StreamParser? I mean, even if it isn't quite the same, that name would still make sense. Eli Bendersky wrote: >On Mon, Aug 26, 2013 at 8:57 AM, Antoine Pitrou >wrote: > >> Le Mon, 26 Aug 2013 17:44:41 +0200, >> Simon Cross a écrit : >> > On Mon, Aug 26, 2013 at 2:51 PM, Antoine Pitrou > >> > wrote: >> > > Because this API is mostly useful when the data is received (*) >at a >> > > slow enough speed - which usually means from the network, not >from a >> > > hard drive. >> > >> > It looks like all the events have to be ready before one can start >> > iterating over .events() in the new API? That doesn't seem that >useful >> > from an asynchronous programming perspective and .data_received() >and >> > .eof_received() appear to be thin wrappers over .feed() and >.close()? >> >> What do you mean, "all events have to be ready"? >> If you look at the unit tests, the events are generated on-the-fly, >> not at the end of the document. >> (exactly the same as iterparse(), except that iterparse() is >blocking) >> >> Implementation-wise, data_received() and eof_received() are not thin >> wrappers over feed() and close(), they rely on an internal API to get >> at the generated events (which justifies putting the functionality >> inside the etree module, by the way). >> > >Antoine, you opted out of the tracker issue but I feel it's fair to let >you >know that after a lot of discussion with Nick and Stefan (*), we've >settled >on renaming the input methods to feed & close, and the output method to >read_events. We are also considering a different name for the class. > >I've posted with more detail and rationale in >http://bugs.python.org/issue17741, but to summarize: > >The input-side of IncrementalParser is the same as the plain XMLParser. >The >latter can also be given data incrementally by means of "feed". By >default >it would collect the whole tree and return it in close(), but in >reality >you can rig a custom target that does something more fluid (though not >to >the full extent of IncrementalParser). Therefore it was deemed >confusing to >have different names for this. Another reason is consistency with >xml.sax.xmlreader.IncrementalParser, which also has feed() and close(). > >As for the output method name, Nick suggested that read_events conveys >the >destructive nature of the method better (by analogy to file/stream >APIs), >and others agreed. > >As for the class name, IncrementalParser is ambiguous because it's not >immediately clear which side is incremental. Input or output? For the >input, it's no more incremental than XMLParser itself, as stated above. >The >output is what's different here, so we're considering a few candidates >for >a better name that conveys the meaning more precisely. > >And to reiterate, I realize that it's unpleasant for you to have this >dug >up after it has already been committed. I assume the blame for not >reviewing it in more detail originally. However, I feel it would still >be >better to revise this now than just leave it be. APIs added to stdlib >are >cooked in there for a *long time*. Alternatively, Nick suggested >granting >this API a "provisional" status (PEP 411), and that's an option if we >don't >manage to reach some sort of consensus. > >Eli > >(*) Well, to be completely precise, Stefan is still opposed to the >whole >idea. > > > > >___ >Python-Dev mailing list >Python-Dev@python.org >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2
Nonblocking sounds too Internet-related. How about...flow? Ah, I'll probably still end up using Expat regardless. Eli Bendersky wrote: >On Mon, Aug 26, 2013 at 10:40 AM, Paul Moore >wrote: > >> On 26 August 2013 17:40, Eli Bendersky wrote: >> >>> Yes, exactly :-) "Incremental", though, seems to support the >conjecture >>> that it's the input. Which is true, but, since XMLParser is also >>> "incremental" in this sense, slightly confusing. >> >> >> As a data point, until you explained the difference between the two >> classes earlier in this thread, I too had been completely confused as >both >> the existing and the new classes are "incremental" (on the input side >- >> that's what I interpret "incremental" as meaning). It never even >occurred >> to me that the difference was in the *output* side. Maybe >"NonBlocking" >> would imply that to me. Or maybe "Generator". But regardless, I think >the >> changes you've made sound good, and I'm certainly less concerned with >the >> new version(as someone who will likely never use the new API, and >therefore >> doesn't really have a vote). >> > >Thanks for the data point; it is useful. > >> How about StreamParser? > >The problem with StreamParser is similar to IncrementalParser. "Stream" >carries the impression that it refers to the input. But the input of ET >parsers is *always* streaming, in a way (the feed/close interface). I >want >a name that conveys that the *output* is also >nonblocking/streaming/yielding/generating/etc. Therefore Nonblocking >(I'll >let better English experts to decide whether B should be capitalized) >sounds better to me, because it helps convey that both sides of the >parser >are asynchronous. > >Eli > > > > >___ >Python-Dev mailing list >Python-Dev@python.org >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 to end support with 2.6.9 in October 2013
I'm still waiting on Python 2.7 for Android! Stuck on 2.6 for now...ugh! Wonder if I can build it myself... Barry Warsaw wrote: >Hello Pythonistas, > >Python 2.6.9 is the last planned release of the 2.6.x series. This >will be a >security-only source-only release. It is currently scheduled for >October >2013, and after this Python 2.6 will have reached its end-of-life and >the >branch will be retired. > >http://www.python.org/dev/peps/pep-0361/ > >I would like to release 2.6.9rc1 on Monday, September 30th, and 2.6.9 >final on >Monday, October 28th. I've added both dates to the Python calendar. > >Here are the list of candidates still to be fixed for 2.6.9: > >- 18747 - Re-seed OpenSSL's PRNG after fork >- 16037 - httplib: header parsing is not delimited >- 16038 - ftplib: unlimited readline() from connection >- 16039 - imaplib: unlimited readline() from connection >- 16040 - nntplib: unlimited readline() from connection >- 16041 - poplib: unlimited readline() from connection >- 16042 - smtplib: unlimited readline() from connection >- 16043 - xmlrpc: gzip_decode has unlimited read() > >These were the ones I previously had on my list, and I've now marked >these all >as release blockers for 2.6.9... for now. > >If you know of any others that I should be aware of, please let me >know. > >If you can contribute to 2.6.9 by reviewing, testing, developing, or >commenting, that would be greatly appreciated. I will be spending some >time >triaging these and any other issues that get identified as possible >2.6.9 >candidates. > >If you have any questions regarding 2.6.9, please contact me via >mailing list >or IRC. > >Cheers, >-Barry > > > > >___ >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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ 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] PEP 450 adding statistics module
...what's a PEP dictator? Steven D'Aprano wrote: > > >I'd like to get some attention for this please. > > >On Sat, Aug 31, 2013 at 12:58:39PM +1000, Steven D'Aprano wrote: >> Hi all, >> >> >> I think that PEP 450 is now ready for a PEP dictator. There have been >a >> number of code reviews, and feedback has been taken into account. The >test >> suite passes. I'm not aware of any unanswered issues with the code. >At >> least two people other than myself think that the implementation is >ready >> for a dictator, and nobody has objected. >> >> There is still on-going work on speeding up the implementation for >the >> statistics.sum function, but that will not effect the interface or >the >> substantially change the test suite. >> >> http://bugs.python.org/issue18606 >> http://www.python.org/dev/peps/pep-0450/ >> >> >> >> >> -- >> Steven >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> >http://mail.python.org/mailman/options/python-dev/steve%40pearwood.info >> >___ >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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ 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] [RELEASED] Python 3.4.0a2
HALLELUJAH!!! Ned Deily wrote: >In article <522db8d3.1030...@hastings.org>, > Larry Hastings wrote: > >> On behalf of the Python development team, I'm chuffed to announce the >> second alpha release of Python 3.4. > >Yay! 3.4.0a2 also contains a new batteries-included feature for OS X >users. The python.org 64-bit/32-bit installer now includes its own >private version of Tcl/Tk 8.5.14 so it is finally no longer necessary >to >install a third-party version of Tcl/Tk 8.5 to workaround the >problematic system versions shipped in OS X 10.6+. More improvements >to >come. > >-- > Ned Deily, > n...@acm.org > >___ >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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ 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] Compiler for the Mac OS X version of Python 3.4
+1. A 10.6-only build makes sense. If you aren't having problems with GCC 4.8, then Clang shouldn't give any trouble. Honestly, I still think Clang should be a compiler option in Windows distutils... Raymond Hettinger wrote: > >On Sep 14, 2013, at 1:32 PM, Ned Deily wrote: >> The >> most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, >have >> a mature clang but do not provide a 10.6 SDK. Even with using an >SDK, >> it's still possible to end up inadvertently linking with the wrong >> versions of system libraries. We have been burned by that in the >past. > >I think we should offer a separate Mac build just for 10.6 >(much like we do for the 32-bit PPC option for 10.5). > >Otherwise, were trapped in an old world and using the same >reasoning as companies that still mandate Internet Explorer 6; >forgoing the benefits of newer browsers just to make sure >a few pieces of legacy code can be supported. > >> >> I'd like to move to Apple's latest clang, as well. (Apple is >dropping >> gcc totally from the next release of Xcode.) > >That is an excellent reason for us to move as well. >Otherwise, we risk getting out of sync with the rest of the ecosystem. > >> I've opened a bug tracker issue for this (Issue19019). > >Thank you. > >One thing that can be done is to take advantage of the 3.4 alphas >and betas to experiment with having both a legacy version and >fresh build with better tools. That would let us find out early >whether >the worries and fears are real and will manifest themselves in >practice. > >I've been building under GCC 4.8.1 for months and have encountered >no problems at all with the popular third-party modules or with linking >to existing SO files. > > >Raymond >___ >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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ 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] Use an empty def as a lambda
Change def to func? That's the worst idea I've heard yet. Def is already there; why break all existing code just for a word? "Westley Martínez" wrote: >'def' is no more ambiguous than 'lambda', and is in fact more >ambiguous, >for 'def' doesn't lend itself to anything other than the word define, >whilst 'lambda' can only mean lambda function. Calling def explicit is >silly. It only makes sense because def arbitrarily means a function in >Python (I'm proposing def become func or proc in Python 4000). > >To call lambda too 'computer sciencey' is equally ridiculous, for pro- >gramming is a key spawn of computer science. A programmer needs to >have >some knowledge of computer science to program, just like a physicist >needs knowledge of calculus to understand mechanics. > >> -Original Message- >> From: Python-Dev >[mailto:python-dev-bounces+anikom15=gmail@python.org] On >> Behalf Of Ben Gift >> Sent: Thursday, September 19, 2013 1:54 PM >> To: python-dev@python.org >> Subject: [Python-Dev] Use an empty def as a lambda >> >> I think the lambda keyword is difficult to understand for many >people. It >> would be more pythonic to use an empty def call instead. >> >> >> For instance this: >> >> >> words.sort(key = lambda x: x[2]) >> >> >> could look like this: >> >> words.sort(key = def (x): x[2]) >> >> >> It's obvious and explicit that we're creating an unnamed, anonymous >function >> this way. > > >___ >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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ 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] https:bugs.python.org -- Untrusted Connection (Firefox)
> On Aug 21, 2014, at 11:29 AM, Martin v. Löwis wrote: > > Am 21.08.14 17:44, schrieb Nick Coghlan: >> I've now raised this issue with the infrastructure team. The current >> hosting arrangements for bugs.python.org were put in place when the >> PSF didn't have any on-call system administrators of its own, but now >> that we do, it may be time to migrate that service to a location where >> we can switch to a more appropriate SSL certificate. > > Just to relay Noah's response: it's actually not the hosting that > prevents installation of a proper certificate, it's the limitation > that the certificate we could deploy would include "python.org" as > a server name, which is considered risky regardless of where the > service is hosted. There are solutions to that as well, of course. That sounds like a limitation I’ve seen with StartSSL. Perhaps there’s a certificate authority that would be willing to sponsor a certificate for Python without this annoying limitation? ___ 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] Microsoft Visual C++ Compiler for Python 2.7
At long last! Building C extensions on Windows will no longer be a pain in the rear! On Fri, Sep 26, 2014 at 1:01 PM, Steve Dower wrote: > Hi all, > > (This is advance notice since people on this list will be interested. > Official announcements are coming when setuptools makes their next release.) > > Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). > We've produced this package to help library developers build wheels for > Windows, but also to help users unblock themselves when they need to build > C extensions themselves. > > The Microsoft Visual C++ Compiler for Python 2.7 is available from: > http://aka.ms/vcpython27 > > This package contains all the tools and headers required to build C > extension modules for Python 2.7 32-bit and 64-bit (note that some > extension modules require 3rd party dependencies such as OpenSSL or libxml2 > that are not included). Other versions of Python built with Visual C++ 2008 > are also supported. > > You can install the package without requiring administrative privileges > and, with the latest version of setuptools (when it releases), use tools > such as pip, wheel, or a setup.py file to produce binaries on Windows. > > Unfortunately, this package isn't necessarily going to help with building > CPython 2.7 itself, as the build process is complicated and Visual Studio > 2008 is practically required. However, as most people aren't building > CPython on Windows, this isn't a huge issue. This compiler package should > be sufficient for most extension modules. > > I should also point out that VC9 is no longer supported by Microsoft. This > means there won't be any improvements or bug fixes coming, and there's no > official support offered. Feel free to contact me directly < > steve.do...@microsoft.com> if there are issues with the package. > > Cheers, > Steve > > ___ > 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] [OFF-TOPIC] It is true that is impossible write in binary code, the lowest level of programming that you can write is in hex code?
Wait...you sent this to 9fans AND Python Dev??? Why not ask on StackExchange Programmers <http://programmers.stackexchange.com/> or something? On Mon, Nov 3, 2014 at 5:19 PM, françai s wrote: > I intend to write in lowest level of computer programming as a hobby. > > It is true that is impossible write in binary code, the lowest level of > programming that you can write is in hex code? > > What is the lowest level of programming computers that you can write ? > > Is binary code? > > Is hex code? > > Is another machine code? Honestly do not know if it is true that there is > another machine code beyond the binary and hex code. > > Is Assembly? > > ___ > 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] Improvements for Pathlib
+1 for the context manager ideas. Anything that is like a resource should be available as a context manager. On Sat, Nov 8, 2014 at 9:46 AM, Ionel Cristian Mărieș wrote: > Hello, > > In the current incarnation Pathlib is missing some key features I need in > my usecases. I want to contribute them but i'd like a bit of feedback on > the new api before jumping to implementation. > > The four things I need are: > > #1. A context manager for temporary files and dirs (that cleans everything > up on exit). Eg: > > with pathlib.TmpDir(suffix='', prefix='') as tmp: > assert isinstance(tmp, pathlib.Path) > > with pathlib.TmpFile(suffix='', prefix='') as tmp: > assert isinstance(tmp, pathlib.Path) > > #2. A context manager for changing working directory (that switches to the > old cwd on exit). Eg: > > with path.cd(): > assert os.getcwd() == path > > # > 3 > . Shutil-like features: > > - copy_file > - copy_dir (or copy_tree?) > - copy (does copy_dir or copy_file depending on what the source is. How to > handle symlinks?) > - rm_dir (or rm_tree? Also, this would be required for the TmpDir path). > > #4. Zip files support. A specialised Path subclass that works inside a zip > file. I'm ok having this as an external package but some discussion would > be useful as I'd have to rely on pathlib internals. > > After some brief looking in the pathlib code it would appear the wise > thing would be to have the zip path as the "drive" for the ZipPaths that > refer to files inside the zip. > > I'm not sure where the best place is to store the internal zipfile object. > Perhaps the accessor? > > Ideally the ZipFiles would work with the shtuil-like api just fine (or at > least the readonly operations). > > Thanks, > -- Ionel M. > > ___ > 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] Windows Dedicated Mailing List
I agree completely (although I use multibooting instead of a VM). On Fri, Nov 14, 2014 at 11:46 AM, Antoine Pitrou wrote: > On Fri, 14 Nov 2014 16:35:12 + > Steve Dower wrote: > > I'd like to keep development *of* Python here, regardless of platform. > Otherwise all the Linux and Mac people might forget about us :) > > +1 from a Linux developer. I find it useful to know what happens on > other platforms (also I occasionally fire a Windows VM to do some > development). > > 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/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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 1:41 PM, Ethan Furman wrote: > On 11/23/2014 10:14 AM, Brett Cannon wrote: > > On Sun Nov 23 2014 at 1:08:58 PM Ethan Furman > wrote: > >> > >> Dous GitHub support hg? If not, I am strongly opposed. > >> > > > > Depends on what you mean by "support". If you mean natively, then no. If > > you mean "I want more of a hg CLI" then you can get that with > > http://hg-git.github.io/ . > > Well, if somebody documents it, I suppose I can follow along. ;). I haven't used it in a while, but it was something like this (after it's installed): - Put the git repo url in .hgrc: [paths] default=git+https://github.com/my_user/my_repo.git [auth] github.prefix = git+https://github.com/my_user/my_repo.git github.username = my_user github.password = my_password Unless you put the login info there, it won't work (for some reason). Then, whenever you're going to push, first do: hg bookmark -r default master I'd love to test this right now, but I'm on Chrome OS... > > > And can I just say this is all bringing back "wonderful" flashbacks of > the > > SourceForge to our own infrastructure move as well as the svn to hg > move. =/ > > My apologies. Change can be hard. > > My concern is that we will end up with multiple different workflows > depending on which part of Python we're working on, > which will lead to more time spent learning more about how to do it > instead of doing it, and more time spent recovering > from errors because of the differences. > > -- > ~Ethan~ > > > ___ > 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
[Python-Dev] Google search labels Python 2.7 docs as Python 3.4
Not sure if this is something to post here...but... [image: Inline image 1] -- 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] python 2.7.9 regression in argparse?
I thought of this exact comment when I read the "bug fix considered a regression." On Tue, Jan 6, 2015 at 2:41 PM, Guido van Rossum wrote: > There's an obligatory XKCD reference for this: http://xkcd.com/1172/ > > On Tue, Jan 6, 2015 at 12:25 PM, Terry Reedy wrote: > >> On 1/6/2015 7:39 AM, Victor Stinner wrote: >> >>> More context: >>> >>> 2014-12-19 12:43 GMT+01:00 anatoly techtonik : >>> >>>> https://github.com/nickstenning/honcho/pull/121 >>>> >>> >>> The link mentions the following changeset: >>> --- >>> changeset: 93122:1a3143752db2 >>> branch: 2.7 >>> parent: 93112:927cca0b9337 >>> user:R David Murray >>> date:Fri Oct 17 20:07:08 2014 -0400 >>> files: Lib/argparse.py Lib/test/test_argparse.py Misc/NEWS >>> description: >>> #9351: set_defaults on subparser is no longer ignored if set on parent. >>> >>> Before, if a default was set on the parent parser, any default for that >>> variable set via set_defaults on a subparser would be ignored. Now >>> the subparser set_defaults is honored. >>> >>> Patch by Jyrki Pullianinen. >>> >>> >>> diff -r 927cca0b9337 -r 1a3143752db2 Lib/argparse.py >>> --- a/Lib/argparse.py Fri Oct 17 16:20:15 2014 -0500 >>> +++ b/Lib/argparse.py Fri Oct 17 20:07:08 2014 -0400 >>> @@ -1089,7 +1089,14 @@ class _SubParsersAction(Action): >>> # parse all the remaining options into the namespace >>> # store any unrecognized options on the object, so that the top >>> # level parser can decide what to do with them >>> -namespace, arg_strings = parser.parse_known_args(arg_strings, >>> namespace) >>> + >>> +# In case this subparser defines new defaults, we parse them >>> +# in a new namespace object and then update the original >>> +# namespace for the relevant parts. >>> +subnamespace, arg_strings = parser.parse_known_args(arg_strings, >>> None) >>> +for key, value in vars(subnamespace).items(): >>> +setattr(namespace, key, value) >>> + >>> if arg_strings: >>> vars(namespace).setdefault(_UNRECOGNIZED_ARGS_ATTR, []) >>> getattr(namespace, _UNRECOGNIZED_ARGS_ATTR). >>> extend(arg_strings) >>> --- >>> >>> Which is related to http://bugs.python.org/issue9351 >>> >>> Maybe argparse just became more strict? I don't understand the issue. >>> >> >> Steven Bethard, the argparse maintainer, defined the old behavior of >> ignoring subparser defaults (where there are also top level defaults) as a >> bug "counter to what people probably expect". If the old behavior had been >> documented, changing it in a bug-fix release would have been a mistake. >> But looking at the patch, the doc seems to have been silent on the issue. >> >> This is not the first time someone considered a 'bug fix' to be a >> 'regression', which it might be from their viewpoint. The last comment on >> the github thread suggests that an easy fix was found. >> >> -- >> Terry Jan Reedy >> >> >> ___ >> 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) > > ___ > 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] Compile Python on Windows (OpenSSL)
On Thu, Jan 15, 2015 at 3:30 PM, Victor Stinner wrote: > Hi, > > I installed the SP1 for Visual Studio 2010, and it looks like that it > broke my Windows SDK 7.1 (setenv was missing, cl.exe was also > missing). I uninstalled the SDK 7.1, and then I saw that a patch is > required to use Windows SDK 7.1 with Visual Studio 2010 SP1. Ah. Too > late. > > I don't understand the link between the SDK and Visual Studio. There > are not separated directories? > > And now I cannot find Windows SDK 7.1 anymore. It looks like it > disappeared from microsoft.com. The SDK 7.1 was released in 2010, so > it's now quite old, but it worked well! > http://www.mathworks.com/matlabcentral/answers/101105-how-do-i-install-microsoft-windows-sdk-7-1 http://www.microsoft.com/en-us/download/details.aspx?id=8279 Both are about Windows SDK 7.1. The latter is a download link; the former says what to do if you have VS 2010 installed. > > Can I use the SDK 8.0 or 8.1 to build Python extensions for Python 3.3 and > 3.4? > > It took me several hours to have a working platform to build my Python > extensions for Python 2.7, 3.3 and 3.4, in 32 and 64 bits with > automated scripts to run all commands. And now it doesn't work anymore > :-( > > Victor > > 2015-01-13 23:46 GMT+01:00 M.-A. Lemburg : > > On 13.01.2015 23:42, Brian Curtin wrote: > >> On Tue, Jan 13, 2015 at 4:36 PM, Victor Stinner > >> wrote: > >>> 2015-01-13 23:18 GMT+01:00 Steve Dower : > >>>> Technically, Python 3.5 requires Visual Studio 2015 > >>> > >>> For me, it's *very* difficult to find how to install Visual Studio. > >>> There are many different websites and web pages which mention Visual > >>> Studio with a lot of versions and "flavors" (Express, Community, > >>> Ultimate, etc.). > >>> > >>> Visual Studio 2015 was not released yet :-/ > >>> > >>> My VM has only a disk of 40 GB. Only 12 GB are free. I already have VS > >>> 2008 Express and VS 2010 Express installed. I understood that > >>> "Ultimate" includes a *lot* of things, not only a C compiler. > >>> > >>> I found a "free" Visual Studio which is in fact Visual Studio 2013 > >>> Community and I read that it's not free. > >>> > >>> I sent an email to Brian Curtin to ask to renew my MSDN account. He > >>> didn't reply yet. > >> > >> I saw that and will send it on, but it's still going to take some time > >> to process - usually a week or so. > >> > >> In the meantime, the first result searching for Visual Studio 2015 > >> came up with > http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs.aspx > , > >> which seems to give you VS2015. I haven't tried to run it since I'm > >> not on Windows at the moment, but it looks correct. > > > > Just a note of caution: for older preview releases of VS the > > only way to get back to a clean system was to reinstall > > Windows. > > > > I don't know whether this will be different with VS 2015, > > but if you care for your VM, you should probably create > > a snapshot before installing VS 2015 preview to make it > > easy to revert back, e.g. to install the final VS 2015 > > version. > > > > -- > > Marc-Andre Lemburg > > eGenix.com > > > > Professional Python Services directly from the Source (#1, Jan 13 2015) > >>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ > >>>> mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ > >>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ > > > > 2015-01-09: Released eGenix pyOpenSSL 0.13.7 ... http://egenix.com/go68 > > 2015-01-20: Python Meeting Duesseldorf ...http://egenix.com/go69 > > > > : Try our mxODBC.Connect Python Database Interface for free ! :: > > > >eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > >Registered at Amtsgericht Duesseldorf: HRB 46611 > >http://www.egenix.com/company/contact/ > ___ > 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] Compile Python on Windows (OpenSSL)
If you expand the Details section, it says the version is 7.1. On Thu, Jan 15, 2015 at 3:58 PM, Victor Stinner wrote: > 2015-01-15 22:39 GMT+01:00 Ryan Gonzalez : > > http://www.microsoft.com/en-us/download/details.aspx?id=8279 > > "Microsoft Windows SDK for Windows 7 and .NET Framework 4" > > Are you sure that it is SDK 7.1, and not 7.0? > > -- > > The SDK 7.0 works for Python 2.7 which is compiled with Visual Studio 2008. > > I used the SDK 7.1 for Python 3.3 and 3.4 which are compiled with > Visual Studio 2010. > > It looks likt SDK 8 is more for Visual Studio 2012. > > If you use the wrong SDK, you will depend on a "MSVCRxxx.dll" which is > not provided by Python x.x (ex: MSVCR100.dll for SDK 7.1/Python 3.3 & > 3.4). > > Victor > -- 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] Pydoc Replacement for Python's help()?
Looking at pydoc.py, it looks like the Tk is purely optional...and isn't called from the interpreter. (I'm not a core dev, though, so take that with a grain of salt.) However, can't you just strip out the gui function and the one place in the file where it's called? Again, not a main Python developer, so don't take this too seriously! On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton wrote: > Hello, > I've finally managed to build a (somewhat) working Python port for the > Android tablet I'm using. Unfortunately, as I quickly found out, > Python's built-in help function requires tkinter, which requires > tcl/tk. > > I did download the sources for tcl/tk and built tcl, but found out > that tk requires XWindows libraries and includes. > > Long story short: Is there an alternative documentation system (i.e. > epydoc) that does not have tkinter dependencies? If so, is there a > parameter or env variable that would allow me to use it instead of > pydoc? > > 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/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
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 <http://lide.com/www.slideshare.net/tetsu.koba/interprocess-communication-of-android> 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 <http://www.andrew-kirkpatrick.com/2013/01/get-android-stack-trace-from-device-using-debug-bridge/> 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
Is it possible at all to get a stack trace of the crash using gdb? Try the steps here <http://stackoverflow.com/a/10539883/2097780>. That way we can see where Python's own strdup function is getting called. On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton wrote: > Absolutely. Good thing I have addr2line on device > > /bld/python/Python-3.4.2 $ addr2line -C -f -e /lib/libpython3.4m.so.1.0 > 0008bbc8 > _PyMem_RawStrdup > /bld/python/Python-3.4.2/Objects/obmalloc.c:323 > /bld/python/Python-3.4.2 $ > > > > On Thu, Jan 29, 2015 at 8:26 PM, Ryan wrote: > > 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 > >&g
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
I seriously doubt the issue is in that file; _PyMem_RawStrdup crashes when calling strlen. It's that whatever is calling it is likely asking it to duplicate a null pointer. Basically, it's probably the caller's fault. You could always try modifying _PyMem_RawStrdup to return NULL when given a null pointer and see where it then segfaults. On Fri, Jan 30, 2015 at 11:53 AM, Cyd Haselton wrote: > Alternatively, is there a hassle-free way to find out what changed in > obmalloc.c between 2.7.x and 3.4.x? > > > On Fri, Jan 30, 2015 at 9:29 AM, Cyd Haselton wrote: > > There's a related strdup patch for readline.c, mentioned > > here:http://bugs.python.org/issue21390 and here > > https://github.com/rave-engine/python3-android/issues/2. > > There's a patch, but I'm not sure how to modify it for obmalloc.c, as > > (I think) the functions all belong to Python...they're all prefixed > > with _PyXx > > > > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton > wrote: > >> Absolutely. Good thing I have addr2line on device > >> > >> /bld/python/Python-3.4.2 $ addr2line -C -f -e /lib/libpython3.4m.so.1.0 > 0008bbc8 > >> _PyMem_RawStrdup > >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323 > >> /bld/python/Python-3.4.2 $ > >> > >> > >> > >> On Thu, Jan 29, 2015 at 8:26 PM, Ryan wrote: > >>> 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 < > gu...@python.org> > >>>>> 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 > >>>>>>> > >>>>>&
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
No... ...but I think I found the issue with grep. Try applying the attached patch to the Python/frozenmain.c. It comments out the locale handling. It seems that Python always calls its strdup function on the locale string. On Android, this can apparently be null (as seen in the bug report you linked to). On Fri, Jan 30, 2015 at 12:00 PM, Cyd Haselton wrote: > I don't have gdb on device; does the following tell you where Python's > strdup is called? > > >> _PyMem_RawStrdup > >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323 > > On Fri, Jan 30, 2015 at 11:52 AM, Ryan Gonzalez wrote: > > Is it possible at all to get a stack trace of the crash using gdb? Try > the > > steps here. > > > > That way we can see where Python's own strdup function is getting called. > > > > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton > wrote: > >> > >> Absolutely. Good thing I have addr2line on device > >> > >> /bld/python/Python-3.4.2 $ addr2line -C -f -e /lib/libpython3.4m.so.1.0 > >> 0008bbc8 > >> _PyMem_RawStrdup > >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323 > >> /bld/python/Python-3.4.2 $ > >> > >> > >> > >> On Thu, Jan 29, 2015 at 8:26 PM, Ryan wrote: > >> > 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 < > gu...@python.org> > >> >>> 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 < > chasel...@gmail.com> > >> >>>> 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 s
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
No, it returns NULL if malloc gives it a raw pointer. It unconditionally
checks the length of the (possibly null) string argument first.
Please try the patch I attached in the last email. It *might* fix the
issue. Android has crappy locale handling.
On Fri, Jan 30, 2015 at 12:09 PM, Cyd Haselton wrote:
> Unless i'm reading something incorrectly, _PyMem_RawStrdup is
> currently returning NULL when given a null pointer.
>
> From obmalloc.c
>
> _PyMem_RawStrdup(const char *str)
> {
> size_t size;
> char *copy;
> size = strlen(str) + 1;
> copy = PyMem_RawMalloc(size);
> if (copy == NULL)
> return NULL;
> memcpy(copy, str, size);
> return copy;
> }
>
> On Fri, Jan 30, 2015 at 11:56 AM, Ryan Gonzalez wrote:
> > I seriously doubt the issue is in that file; _PyMem_RawStrdup crashes
> when
> > calling strlen. It's that whatever is calling it is likely asking it to
> > duplicate a null pointer. Basically, it's probably the caller's fault.
> >
> > You could always try modifying _PyMem_RawStrdup to return NULL when
> given a
> > null pointer and see where it then segfaults.
> >
> > On Fri, Jan 30, 2015 at 11:53 AM, Cyd Haselton
> wrote:
> >>
> >> Alternatively, is there a hassle-free way to find out what changed in
> >> obmalloc.c between 2.7.x and 3.4.x?
> >>
> >>
> >> On Fri, Jan 30, 2015 at 9:29 AM, Cyd Haselton
> wrote:
> >> > There's a related strdup patch for readline.c, mentioned
> >> > here:http://bugs.python.org/issue21390 and here
> >> > https://github.com/rave-engine/python3-android/issues/2.
> >> > There's a patch, but I'm not sure how to modify it for obmalloc.c, as
> >> > (I think) the functions all belong to Python...they're all prefixed
> >> > with _PyXx
> >> >
> >> > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton
> >> > wrote:
> >> >> Absolutely. Good thing I have addr2line on device
> >> >>
> >> >> /bld/python/Python-3.4.2 $ addr2line -C -f -e
> /lib/libpython3.4m.so.1.0
> >> >> 0008bbc8
> >> >> _PyMem_RawStrdup
> >> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323
> >> >> /bld/python/Python-3.4.2 $
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Jan 29, 2015 at 8:26 PM, Ryan wrote:
> >> >>> 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/__prope
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Are you sure the patch was applied correctly? I was SO sure it would work!
FYI, you tried the patch I attached to the email message, right?
On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton wrote:
> Update: I did try the patch after getting it installed correctly, but
> I'm still getting a segfault on the newly built binary.
> Will post info this afternoon.
>
> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez wrote:
> > No, it returns NULL if malloc gives it a raw pointer. It unconditionally
> > checks the length of the (possibly null) string argument first.
> >
> > Please try the patch I attached in the last email. It *might* fix the
> issue.
> > Android has crappy locale handling.
> >
> > On Fri, Jan 30, 2015 at 12:09 PM, Cyd Haselton
> wrote:
> >>
> >> Unless i'm reading something incorrectly, _PyMem_RawStrdup is
> >> currently returning NULL when given a null pointer.
> >>
> >> From obmalloc.c
> >>
> >> _PyMem_RawStrdup(const char *str)
> >> {
> >> size_t size;
> >> char *copy;
> >> size = strlen(str) + 1;
> >> copy = PyMem_RawMalloc(size);
> >> if (copy == NULL)
> >> return NULL;
> >> memcpy(copy, str, size);
> >> return copy;
> >> }
> >>
> >> On Fri, Jan 30, 2015 at 11:56 AM, Ryan Gonzalez
> wrote:
> >> > I seriously doubt the issue is in that file; _PyMem_RawStrdup crashes
> >> > when
> >> > calling strlen. It's that whatever is calling it is likely asking it
> to
> >> > duplicate a null pointer. Basically, it's probably the caller's fault.
> >> >
> >> > You could always try modifying _PyMem_RawStrdup to return NULL when
> >> > given a
> >> > null pointer and see where it then segfaults.
> >> >
> >> > On Fri, Jan 30, 2015 at 11:53 AM, Cyd Haselton
> >> > wrote:
> >> >>
> >> >> Alternatively, is there a hassle-free way to find out what changed in
> >> >> obmalloc.c between 2.7.x and 3.4.x?
> >> >>
> >> >>
> >> >> On Fri, Jan 30, 2015 at 9:29 AM, Cyd Haselton
> >> >> wrote:
> >> >> > There's a related strdup patch for readline.c, mentioned
> >> >> > here:http://bugs.python.org/issue21390 and here
> >> >> > https://github.com/rave-engine/python3-android/issues/2.
> >> >> > There's a patch, but I'm not sure how to modify it for obmalloc.c,
> as
> >> >> > (I think) the functions all belong to Python...they're all prefixed
> >> >> > with _PyXx
> >> >> >
> >> >> > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton >
> >> >> > wrote:
> >> >> >> Absolutely. Good thing I have addr2line on device
> >> >> >>
> >> >> >> /bld/python/Python-3.4.2 $ addr2line -C -f -e
> >> >> >> /lib/libpython3.4m.so.1.0
> >> >> >> 0008bbc8
> >> >> >> _PyMem_RawStrdup
> >> >> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323
> >> >> >> /bld/python/Python-3.4.2 $
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Thu, Jan 29, 2015 at 8:26 PM, Ryan wrote:
> >> >> >>> 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...
> >> >> >>>>
> >> >> >>>
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or may not)
work:
1. Make sure you have a copy of Python on your computer and make sure that
it's built with debug symbols.
2. Run the following commands from a shell with your phone plugged in:
adb forward tcp:5039 tcp:5039
adb shell /system/bin/gdbserver tcp:5039
/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path
file
target remote :5055
run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To GDB, type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton wrote:
> Unfortunately it is still reporting the same function :-/.
>
> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez wrote:
> > Yes...
> >
> > Can you check if it's crashing in a different function now?
> >
> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton
> wrote:
> >>
> >> Yes I did. I did have to enter all the information in manually...I'm
> >> not familiar with automated patch application tools and even if I
> >> were, I'm pretty sure I wouldn't have them on my device.
> >>
> >> Just so that I'm absolutely sure I got everything correct...you wanted
> >> all of the lines in the patch commented out, correct? Basically
> >> everything referencing oldloc?
> >>
> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez
> wrote:
> >> > Are you sure the patch was applied correctly? I was SO sure it would
> >> > work!
> >> >
> >> > FYI, you tried the patch I attached to the email message, right?
> >> >
> >> > On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton
> >> > wrote:
> >> >>
> >> >> Update: I did try the patch after getting it installed correctly,
> but
> >> >> I'm still getting a segfault on the newly built binary.
> >> >> Will post info this afternoon.
> >> >>
> >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez
> >> >> wrote:
> >> >> > No, it returns NULL if malloc gives it a raw pointer. It
> >> >> > unconditionally
> >> >> > checks the length of the (possibly null) string argument first.
> >> >> >
> >> >> > Please try the patch I attached in the last email. It *might* fix
> the
> >> >> > issue.
> >> >> > Android has crappy locale handling.
> >> >> >
> >> >> > On Fri, Jan 30, 2015 at 12:09 PM, Cyd Haselton <
> chasel...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Unless i'm reading something incorrectly, _PyMem_RawStrdup is
> >> >> >> currently returning NULL when given a null pointer.
> >> >> >>
> >> >> >> From obmalloc.c
> >> >> >>
> >> >> >> _PyMem_RawStrdup(const char *str)
> >> >> >> {
> >> >> >> size_t size;
> >> >> >> char *copy;
> >> >> >> size = strlen(str) + 1;
> >> >> >> copy = PyMem_RawMalloc(size);
> >> >> >> if (copy == NULL)
> >> >> >> return NULL;
> >> >> >> memcpy(copy, str, size);
> >> >> >> return copy;
> >> >> >> }
> >> >> >>
> >> >> >> On Fri, Jan 30, 2015 at 11:56 AM, Ryan Gonzalez >
> >> >> >> wrote:
> >> >> >> > I seriously doubt the issue is in that file; _PyMem_RawStrdup
> >> >> >> > crashes
> >> >> >> > when
> >> >> >> > calling strlen. It's that whatever is calling it is likely
> asking
> >> >> >> > it
> >> >> >> > to
> >> >> >> > duplicate a null pointer. Basically, it's probably the caller's
> >> >> >> > fault.
> >> >> >> >
> >> >> >> > You could always try modifying _PyMem_RawStrdup to return NULL
> >> >> >> > when
> >> >> >> > given a
> >> >> >> > null pointer and see where it then segfaults.
> >> >> >> >
> >> >> >> > On Fri, Jan 30, 2015 at 11:5
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Do you have just the SDK (which doesn't require Cygwin) or a rooted phone? If so, I can upload instructions that don't use the NDK. On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton wrote: > This is going to take some time...here's why: > > Downloading and installing the NDK/SDK won't be too hard...I have to > clear some space...but my primary machine is running Windows 7 and I'd > rather swallow hot coals than install Cygwin. I've got next to no > experience with it, other than knowing that the NDK recommends against > it. > > I've got a CentOS VM...but it's currently in tarball form on an > external drive for space reasons...and it only has the NDK installed. > If I am able to get it back up and running, there's still the task of > getting adb connected to my device. from the VM. > > Not saying it's impossible...just that it'll take time...and I'll > probably have to tackle it tomorrow (earliest) or Sunday (latest). In > the meantime I'll also check to see if there's anything that can a) > run in an Android terminal and b) can take a stack trace; it would be > far, far, far easier than either option above. > > > > On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez wrote: > > Do you have the Android SDK and NDK installed? If so... > > > > Using Google, I've created this series of steps, which may (or may not) > > work: > > > > 1. Make sure you have a copy of Python on your computer and make sure > that > > it's built with debug symbols. > > > > 2. Run the following commands from a shell with your phone plugged in: > > > > adb forward tcp:5039 tcp:5039 > > adb shell /system/bin/gdbserver tcp:5039 > > /arm-linux-androideabi-gdb > > > > Now, GDB should have opened, so type the following commands: > > > > set solib-search-path > > file > > target remote :5055 > > run > > > > Now, wait for the program to crash and type: > > > > backtrace > > > > You should now see a complete backtrace in your terminal. To GDB, type: > > > > quit > > > > *crosses fingers* > > > > On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton > wrote: > >> > >> Unfortunately it is still reporting the same function :-/. > >> > >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez > wrote: > >> > Yes... > >> > > >> > Can you check if it's crashing in a different function now? > >> > > >> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton > >> > wrote: > >> >> > >> >> Yes I did. I did have to enter all the information in manually...I'm > >> >> not familiar with automated patch application tools and even if I > >> >> were, I'm pretty sure I wouldn't have them on my device. > >> >> > >> >> Just so that I'm absolutely sure I got everything correct...you > wanted > >> >> all of the lines in the patch commented out, correct? Basically > >> >> everything referencing oldloc? > >> >> > >> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez > >> >> wrote: > >> >> > Are you sure the patch was applied correctly? I was SO sure it > would > >> >> > work! > >> >> > > >> >> > FYI, you tried the patch I attached to the email message, right? > >> >> > > >> >> > On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton < > chasel...@gmail.com> > >> >> > wrote: > >> >> >> > >> >> >> Update: I did try the patch after getting it installed correctly, > >> >> >> but > >> >> >> I'm still getting a segfault on the newly built binary. > >> >> >> Will post info this afternoon. > >> >> >> > >> >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez > > >> >> >> wrote: > >> >> >> > No, it returns NULL if malloc gives it a raw pointer. It > >> >> >> > unconditionally > >> >> >> > checks the length of the (possibly null) string argument first. > >> >> >> > > >> >> >> > Please try the patch I attached in the last email. It *might* > fix > >> >> >> > the > >> >> >> > issue. > >> >> >> > Android has crappy locale handling. > >> >
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Regardless, if you're looking to toy more with stuff like this, I'd highly recommend dual-booting with Ubuntu, which is what I'm doing now. (Now I rarely ever boot into Windows!) On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez wrote: > Do you have just the SDK (which doesn't require Cygwin) or a rooted phone? > If so, I can upload instructions that don't use the NDK. > > On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton wrote: > >> This is going to take some time...here's why: >> >> Downloading and installing the NDK/SDK won't be too hard...I have to >> clear some space...but my primary machine is running Windows 7 and I'd >> rather swallow hot coals than install Cygwin. I've got next to no >> experience with it, other than knowing that the NDK recommends against >> it. >> >> I've got a CentOS VM...but it's currently in tarball form on an >> external drive for space reasons...and it only has the NDK installed. >> If I am able to get it back up and running, there's still the task of >> getting adb connected to my device. from the VM. >> >> Not saying it's impossible...just that it'll take time...and I'll >> probably have to tackle it tomorrow (earliest) or Sunday (latest). In >> the meantime I'll also check to see if there's anything that can a) >> run in an Android terminal and b) can take a stack trace; it would be >> far, far, far easier than either option above. >> >> >> >> On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez wrote: >> > Do you have the Android SDK and NDK installed? If so... >> > >> > Using Google, I've created this series of steps, which may (or may not) >> > work: >> > >> > 1. Make sure you have a copy of Python on your computer and make sure >> that >> > it's built with debug symbols. >> > >> > 2. Run the following commands from a shell with your phone plugged in: >> > >> > adb forward tcp:5039 tcp:5039 >> > adb shell /system/bin/gdbserver tcp:5039 >> > /arm-linux-androideabi-gdb >> > >> > Now, GDB should have opened, so type the following commands: >> > >> > set solib-search-path >> > file >> > target remote :5055 >> > run >> > >> > Now, wait for the program to crash and type: >> > >> > backtrace >> > >> > You should now see a complete backtrace in your terminal. To GDB, type: >> > >> > quit >> > >> > *crosses fingers* >> > >> > On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton >> wrote: >> >> >> >> Unfortunately it is still reporting the same function :-/. >> >> >> >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez >> wrote: >> >> > Yes... >> >> > >> >> > Can you check if it's crashing in a different function now? >> >> > >> >> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton >> >> > wrote: >> >> >> >> >> >> Yes I did. I did have to enter all the information in >> manually...I'm >> >> >> not familiar with automated patch application tools and even if I >> >> >> were, I'm pretty sure I wouldn't have them on my device. >> >> >> >> >> >> Just so that I'm absolutely sure I got everything correct...you >> wanted >> >> >> all of the lines in the patch commented out, correct? Basically >> >> >> everything referencing oldloc? >> >> >> >> >> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez >> >> >> wrote: >> >> >> > Are you sure the patch was applied correctly? I was SO sure it >> would >> >> >> > work! >> >> >> > >> >> >> > FYI, you tried the patch I attached to the email message, right? >> >> >> > >> >> >> > On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton < >> chasel...@gmail.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> Update: I did try the patch after getting it installed >> correctly, >> >> >> >> but >> >> >> >> I'm still getting a segfault on the newly built binary. >> >> >> >> Will post info this afternoon. >> >> >> >> >> >> >>
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
That looks better! Looks like now the real encoding issues are coming up. Try going to line 269 of pythonrun.c and changing: PyErr_SetNone(PyExc_NotImplementedError); return NULL; to: char* m = malloc(6); strcpy(m, "ascii"); return m; This just sets a default encoding. On Sat, Jan 31, 2015 at 1:21 PM, Cyd Haselton wrote: > Very interesting. I got this error > > Fatal Python error: Py_Initialize: Unable to get the locale encoding > NotImplementedError > Aborted > generate-posix-vars failed > make: *** [pybuilddir.txt] Error 1 > > ...but it didn't (of course) segfault. I'll pull gdb, get the results and > send them. > > On January 31, 2015 1:10:18 PM CST, Ryan wrote: > >> No; I was looking for all uses of _PyRaw_Strdup. Surprisingly, it's used >> only a few times. >> >> Cyd Haselton wrote: >>> >>> Question: >>> When you said earlier that you found the problem by using grep...were >>> you looking for places where strdup called locale? >>> >>> On January 30, 2015 7:52:47 PM CST, Ryan Gonzalez >>> wrote: >>>> >>>> Regardless, if you're looking to toy more with stuff like this, I'd >>>> highly recommend dual-booting with Ubuntu, which is what I'm doing now. >>>> (Now I rarely ever boot into Windows!) >>>> >>>> On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez >>>> wrote: >>>> >>>>> Do you have just the SDK (which doesn't require Cygwin) or a rooted >>>>> phone? If so, I can upload instructions that don't use the NDK. >>>>> >>>>> On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton >>>>> wrote: >>>>> >>>>>> This is going to take some time...here's why: >>>>>> >>>>>> Downloading and installing the NDK/SDK won't be too hard...I have to >>>>>> clear some space...but my primary machine is running Windows 7 and I'd >>>>>> rather swallow hot coals than install Cygwin. I've got next to no >>>>>> experience with it, other than knowing that the NDK recommends against >>>>>> it. >>>>>> >>>>>> I've got a CentOS VM...but it's currently in tarball form on an >>>>>> external drive for space reasons...and it only has the NDK installed. >>>>>> If I am able to get it back up and running, there's still the task of >>>>>> getting adb connected to my device. from the VM. >>>>>> >>>>>> Not saying it's impossible...just that it'll take time...and I'll >>>>>> probably have to tackle it tomorrow (earliest) or Sunday (latest). In >>>>>> the meantime I'll also check to see if there's anything that can a) >>>>>> run in an Android terminal and b) can take a stack trace; it would be >>>>>> far, far, far easier than either option above. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez >>>>>> wrote: >>>>>> > Do you have the Android SDK and NDK installed? If so... >>>>>> > >>>>>> > Using Google, I've created this series of steps, which may (or may >>>>>> not) >>>>>> > work: >>>>>> > >>>>>> > 1. Make sure you have a copy of Python on your computer and make >>>>>> sure that >>>>>> > it's built with debug symbols. >>>>>> > >>>>>> > 2. Run the following commands from a shell with your phone plugged >>>>>> in: >>>>>> > >>>>>> > adb forward tcp:5039 tcp:5039 >>>>>> > adb shell /system/bin/gdbserver tcp:5039 >>>>> executable> >>>>>> > /arm-linux-androideabi-gdb >>>>>> > >>>>>> > Now, GDB should have opened, so type the following commands: >>>>>> > >>>>>> > set solib-search-path >>>>>> > file >>>>>> > target remote :5055 >>>>>> > run >>>>>> > >>>>>> > Now, wait for the program to crash and type: >>>>>> > >>>>>> > backtrace >>>>>> > >>>>>> > You should now see a com
Re: [Python-Dev] Import Fails in setup.py On Android
In reality, things just got broken even more. I don't know when that patch was created, but it's now very out of date: importlib._bootstrap has no load function. That's what the error you're getting is telling you. Since it isn't getting to load anything, the issue seems "solved". Not really. What's the full traceback for the undefined reference exception? On Mon, Feb 2, 2015 at 2:04 PM, Cyd Haselton wrote: > Update: While waiting for replies I made the change referenced here: > https://bugs.python.org/review/5309/diff2/12811:12826/setup.py?context=3&column_width=80 > > specifically changing > importlib. _bootstrap._SpecMethods(spec).load() > to > importlib._bootstrap.load(spec) > > I no longer get a terminating 'undefined reference to dlopen' error, but I > do get 'importing extensions failed' errors for each extension...like this: > > *** WARNING: importing extension "_pickle" failed with 'AttributeError'>: 'module' object has no attribute 'load' > > > On February 2, 2015 1:36:29 PM CST, Cyd Haselton > wrote: >> >> After fixing a segfault issue (many thanks Ryan) I'm back to the same >> issue I was having with Python 2.7.8; the newly built python throws an >> undefined reference to dlopen when running setup.py...specifically when >> importing just-built extensions >> >> I've managed to narrow the problem down to the following line: >> >> importlib._bootstrap._SpecMethods(spec).load() >> >> Googling this brings up a few hits from bugs.python.org and not much >> else. I'm new to Python; any ideas what this does...or where I can read up >> on it for troubleshooting purposes? >> > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > ___ > 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] Import Fails in setup.py On Android
Unfortunately, I have no idea. You might want to ask someone who's more familiar with the Python source than I am. What exactly appears? Does it say anything about the source of the error? On Mon, Feb 2, 2015 at 3:24 PM, Cyd Haselton wrote: > No traceback unfortunately...the fakechroot in the environment throws the > error and setup.py fails. > > I'll roll back that change...any idea where I could find info about the > original method? > > > On February 2, 2015 3:17:54 PM CST, Ryan Gonzalez > wrote: >> >> In reality, things just got broken even more. I don't know when that >> patch was created, but it's now very out of date: importlib._bootstrap has >> no load function. That's what the error you're getting is telling you. >> Since it isn't getting to load anything, the issue seems "solved". Not >> really. >> >> What's the full traceback for the undefined reference exception? >> >> On Mon, Feb 2, 2015 at 2:04 PM, Cyd Haselton wrote: >> >>> Update: While waiting for replies I made the change referenced here: >>> https://bugs.python.org/review/5309/diff2/12811:12826/setup.py?context=3&column_width=80 >>> >>> specifically changing >>> importlib. _bootstrap._SpecMethods(spec).load() >>> to >>> importlib._bootstrap.load(spec) >>> >>> I no longer get a terminating 'undefined reference to dlopen' error, but >>> I do get 'importing extensions failed' errors for each extension...like >>> this: >>> >>> *** WARNING: importing extension "_pickle" failed with >> 'AttributeError'>: 'module' object has no attribute 'load' >>> >>> >>> On February 2, 2015 1:36:29 PM CST, Cyd Haselton >>> wrote: >>>> >>>> After fixing a segfault issue (many thanks Ryan) I'm back to the same >>>> issue I was having with Python 2.7.8; the newly built python throws an >>>> undefined reference to dlopen when running setup.py...specifically >>>> when importing just-built extensions >>>> >>>> I've managed to narrow the problem down to the following line: >>>> >>>> importlib._bootstrap._SpecMethods(spec).load() >>>> >>>> Googling this brings up a few hits from bugs.python.org and not much >>>> else. I'm new to Python; any ideas what this does...or where I can read up >>>> on it for troubleshooting purposes? >>>> >>> >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. >>> >>> ___ >>> 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 device with K-9 Mail. Please excuse my brevity. > -- 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] ?s re documentation of Python features
Ask on python-list <https://mail.python.org/mailman/listinfo/python-list>.
Also check out the FAQ <https://docs.python.org/3/faq/index.html> and the Help
page <https://www.python.org/about/help/>. Not sure what your problem is;
Python is EXTREMELY well documented.
On Tue, Feb 24, 2015 at 7:15 PM, GARRY M CRANE wrote:
> I am trying to learn Python for use in computational biology. I am using
> the interesting book: "*Computing for Biologists; Python Programming and
> Principles*" (by Ran Libeskind-Hadas and Eliot Bush). It has an
> interesting and useful set of programming exercises at www.cs.hmc.edu/CFB.
> I am actually enjoying solving (doing) the example problems. However, I
> find some of the instructions non-functional for me. For example the *import
> *function does not work, nor *f=open("filename.txt")*. I have saved
> files per instructions in the programming exercise inside the Python34
> folder (I am using Python 3.4 in Windows 7). But use of the *f=open()*
> command produces an error message that the requested file does not exist. I
> assume I have chosen a wrong location for the saved file within that
> Python34 folder, but trial and error has not led to a successful use of
> these functions. *import* simply leaves a blank line .. no suggestion
> about the problem.
>
> Asking questions in Google and Ask about where to save Python-related
> files that can be used subsequently have not led to answers - just details
> about structuring or formatting things to be written/saved/use of the \n at
> end of each line, etc. Important details, but of no help. I am finding
> Python to be very handy at many biologic things such as working with DNA
> strings, etc. but I find the documentation and indexing for finding how to
> use many Python features exasperating. I am writing to you based on a READ
> ME file in my Python folder - generated when I installed Python.
>
> FYI, I asked a few questions of one of the authors of the interesting book
> - who politely replied he was too busy to answer right now - the book and
> problems were meant for a class ... though neither the book nor problems
> say so. The professor hopes to get around to issues of use by non-students
> sometime - but not now.
>
> Another feature I have come across so far that does not work is
> importation of *matplotlib*. I copy computed results (that otherwise
> would go to your plotting routine) then go to Excel and with manipulation
> produce a usable chart there - but at a cost of time and energy.
>
> Your Python tool has many intriguing features - but some of the most
> basic functions do not work for me (even though many features do, e.g.,
> import random does work). The failure of these features - so far as I can
> tell - is because of lack of description (for the general non-expert
> public) about where/how to install various features. Perhaps I need to
> reinstall from the ground up??? If so, just what should I do? If there is
> a less drastic solution, can you tell me about it?
>
> Thank you for any help ... and if you could provide me a lead regarding
> WHERE to ask subsequent questions I would be most grateful. Sometimes,
> Google or Ask or a U Tube tutorial does a good job - but if one does not
> know the 'proper' name or term for something, it often is frustrating or
> impossible to get an answer. I have not heard about any comprehensive
> handbook for Python34 aimed at one who wants to use Python for creating
> programs (functions) that work - and is not an expert at back-room
> structure of files and folders have I simply missed it? So far, I have
> not found a local Python expert to ask for help. I am sure some are in the
> greater Seattle area where I live- but I don't know how to find even one at
> this time.
>
> Garry Crane
> gandkcr...@msn.com
>
> ___
> 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
[Python-Dev] Working on issue 23496: should I use a macro test or an edit to configure.ac?
So... There was a recent discussion here on porting Python to Android. Well, for those of you who saw too many unread messages and marked the whole thread as read like I usually do, I helped Cyd figure out some patches that make it work. Cyd then opened Issue 23496 <http://bugs.python.org/issue23496>. Now, I'm going to try to redo the patches against HEAD (or tip in Mercurial language). Which leads me to the question. See, of course, the patches should only be enabled if Python is being built targeting Android, but I'm not sure how that should be detected. I know that the Android target triple is arm-linux-androideabi. Should I test for the __ANDROID__ macro in the source file, or should I modify configure.ac to detect Android and define its own macro? Also, if a configure.ac edit is preferred, where should it be? It's slightly painful to scan through all 4000 lines of Python's configure script. ;) -- 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] Working on issue 23496: should I use a macro test or an edit to configure.ac?
DOES NOBODY HAVE AN ANSWER TO THIS??? I'm REALLY relying on someone who works on Python to answer this. PLEASE?? On Wed, Feb 25, 2015 at 12:17 PM, Ryan Gonzalez wrote: > So... > > There was a recent discussion here on porting Python to Android. Well, for > those of you who saw too many unread messages and marked the whole thread > as read like I usually do, I helped Cyd figure out some patches that make > it work. Cyd then opened Issue 23496 <http://bugs.python.org/issue23496>. > Now, I'm going to try to redo the patches against HEAD (or tip in Mercurial > language). > > Which leads me to the question. See, of course, the patches should only be > enabled if Python is being built targeting Android, but I'm not sure how > that should be detected. > > I know that the Android target triple is arm-linux-androideabi. Should I > test for the __ANDROID__ macro in the source file, or should I modify > configure.ac to detect Android and define its own macro? Also, if a > configure.ac edit is preferred, where should it be? It's slightly painful > to scan through all 4000 lines of Python's configure script. ;) > > -- > 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/ > -- 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] PEP 471 Final: os.scandir() merged into Python 3.5
Hi, On Sun, 8 Mar 2015 at 12:33 Ben Hoyt wrote: > Others: if you want to benchmark this, the simplest way is to use my > os.walk() benchmark.py test program here: > https://github.com/benhoyt/scandir -- it compares the built-in os.walk() > implemented with os.listdir() with a version of walk() implemented with > os.scandir(). I see huge gains on Windows (12-50x) and modest gains on my > Linux VM (3-5x). > I have a MacBook Pro Laptop running OS X 10.10.2. I did the following: - hg update -r 8ef4f75a8018 - patch -p1 < scandir-8.patch - ./configure --with-pydebug && make -j7 I then ran ./python.exe ~/Workspace/python/scandir/benchmark.py and I got: *Creating tree at /Users/rstuart/Workspace/python/scandir/benchtree: depth=4, num_dirs=5, num_files=50* *Using slower ctypes version of scandir* *Comparing against builtin version of os.walk()* *Priming the system's cache...* *Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 1/3...* *Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 2/3...* *Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 3/3...* *os.walk took 0.184s, scandir.walk took 0.158s -- 1.2x as fast* I then did ./python.exe ~/Workspace/python/scandir/benchmark.py -s and got: *Using slower ctypes version of scandir* *Comparing against builtin version of os.walk()* *Priming the system's cache...* *Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 1/3...* *Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 2/3...* *Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 3/3...* *os.walk size 23400, scandir.walk size 23400 -- equal* *os.walk took 0.483s, scandir.walk took 0.463s -- 1.0x as fast* Hope this helps. Cheers Note that the actual CPython version of os.walk() doesn't yet use > os.scandir(). I intend to open a separate issue for that shortly (or Victor > can). But that part should be fairly straight-forward, as I already have a > version available in my GitHub project. > > -Ben > > > On Sat, Mar 7, 2015 at 9:13 PM, Victor Stinner > wrote: > >> Hi, >> >> FYI I commited the implementation of os.scandir() written by Ben Hoyt. >> I hope that it will be part of Python 3.5 alpha 2 (Ben just sent the >> final patch today). >> >> Please test this new feature. You may benchmark here. >> http://bugs.python.org/issue22524 contains some benchmark tools and >> benchmark results of older versions of the patch. >> >> The implementation was tested on Windows and Linux. I'm now watching >> for buildbots to see how other platforms like os.scandir(). >> >> Bad news: OpenIndiana doesn't support d_type: the dirent structure has >> no d_type field. I already fixed the implementation to support this >> case. os.scandir() is still useful on OpenIndiana, because the stat >> result is cached in a DirEntry, so only one syscall is required, >> instead of multiple, when multiple DirEntry methods are called (ex: >> entry.is_dir() and not entry.is_symlink()). >> >> Victor >> ___ >> 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/benhoyt%40gmail.com >> > > ___ > 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/ > ryan.stuart.85%40gmail.com > ___ 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] PEP 471 Final: os.scandir() merged into Python 3.5
Hi Ben, On Mon, 9 Mar 2015 at 21:58 Ben Hoyt wrote: > Note that this benchmark is invalid for a couple of reasons. (...) > Thanks a lot for the guidance Ben, greatly appreciated. Just starting to take an interest in the development of CPython and so something like running a benchmark seemed like a good a place as any to start. Since I want to get comfortable with compiling from source I tried this again. Instead of applying the patch, since the issue is now closed, I just compiled from the tip of the default branch which at the time was 94920:0469af231d22. I also didn't configure with --with-pydebug. Here are the new results: *Ryans-MacBook-Pro:cpython rstuart$ ./python.exe ~/Workspace/python/scandir/benchmark.py* Using Python 3.5's builtin os.scandir() Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 1/3... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 2/3... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 3/3... os.walk took 0.061s, scandir.walk took 0.012s -- 5.2x as fast *Ryans-MacBook-Pro:cpython rstuart$ ./python.exe ~/Workspace/python/scandir/benchmark.py -s* Using Python 3.5's builtin os.scandir() Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 1/3... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 2/3... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 3/3... os.walk size 23400, scandir.walk size 23400 -- equal os.walk took 0.109s, scandir.walk took 0.049s -- 2.2x as fast This is on a Retina Mid 2012 MacBook Pro with an SSD. Cheers > you're compiling Python in debug mode (--with-pydebug), which produces > significantly slower code in my tests -- for example, on Windows > benchmark.py is about twice as slow when Python is compiled in debug > mode. > > Second, as the output above shows, benchmark.py is "Using slower > ctypes version of scandir" and not a C version at all. If os.scandir() > is available, benchmark.py should use that, so there's something wrong > here -- maybe the patch didn't apply correctly or maybe you're testing > with a different version of Python than the one you built? > > In any case, the easiest way to test it now is to download Python 3.5 > alpha 2 which just came out: > https://www.python.org/downloads/release/python-350a2/ > > I just tried this on my Mac Mini (i5 2.3GHz, 2 GB RAM, HFS+ on > rotational drive) and got the following results: > > Using Python 3.5's builtin os.scandir() > Comparing against builtin version of os.walk() > Priming the system's cache... > Benchmarking walks on benchtree, repeat 1/3... > Benchmarking walks on benchtree, repeat 2/3... > Benchmarking walks on benchtree, repeat 3/3... > os.walk took 0.074s, scandir.walk took 0.016s -- 4.7x as fast > > > I then did ./python.exe ~/Workspace/python/scandir/benchmark.py -s and > got: > > Also note that "benchmark.py -s" tests the system os.walk() against a > get_tree_size() function using scandir's DirEntry.stat().st_size, > which provides huge gains on Windows (because stat().st_size doesn't > require on OS call) but only modest gains on POSIX systems, which > still require an OS stat call to get the size (though not the file > type, so at least it's only one stat call). I get "2.2x as fast" on my > Mac for "benchmark.py -s". > > -Ben > ___ 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] importante!!
I think this was meant for python-list. On Tue, Mar 31, 2015 at 10:13 AM, Alan Armour wrote: > its french! lol > > I just wanted to see if you could, as well as making python able to have > assembly written, you should totally use blender as your main IDE it would > be so epic > > and do pyjackd, and i think pyaudio will write some stuff, and like > pycoreaudio and like directpy for windows direct x > > oh having blender as the main ide would just be epic > > ___ > 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 [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. 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] Status on PEP-431 Timezones
On Apr 8, 2015, at 12:37, Carl Meyer wrote: >> Anyone interested in a session on this, mail me and we'll set up a >> time and place! > > I'm interested in the topic, and would probably attend a BoF at PyCon. I'm of a similar mind. ___ 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] Type hints -- a mediocre programmer's reaction
Only if you want Java users burning all written copies of the PEP... On Mon, Apr 20, 2015 at 2:37 PM, Isaac Morland wrote: > On Mon, 20 Apr 2015, Paul Moore wrote: > > On 20 April 2015 at 19:41, Barry Warsaw wrote: >> >>> tldr; type hints in python source are scary. Would reserving them for >>>> stub >>>> files be better? >>>> >>> >>> I think so. I think PEP 8 should require stub files for stdlib modules >>> and >>> strongly encourage them for 3rd party code. >>> >> >> Agreed. I have many of the same concerns as Harry, but I wouldn't have >> expressed them quite as well. I'm not too worried about actually >> removing annotations from the core language, but I agree that we >> should create a strong culture of "type hints go in stub files" to >> keep source files readable and clean. >> >> On that note, I'm not sure "stub" files is a particularly good name. >> Maybe "type files" would be better? Something that emphasises that >> they are the correct place to put type hints, not a workaround. >> > > How about "header" files? > > (ducks...) > > Isaac Morland CSCF Web Guru > DC 2619, x36650 WWW Software Specialist > > ___ > 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 [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. 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] Type hints -- a mediocre programmer's reaction
Although I like the concept of type annotations and the PEP, I have to agree with this. If I saw these type annotations when learning Python (I'm self-taught), there's a 99% chance I would've freaked. It's the same issue as with teaching C++: it's wrong to say, "Hey, I taught you the basics, but there's other stuff that's going to confuse you to a ridiculous extent when you read it." People can't ignore it. It'll become a normal part of Python programs. At least now you can say, "I'm using the mypy type checker." Don't get me wrong; I like mypy. I helped with their documentation and am watching the GitHub repo. But this is dead-on. On Mon, Apr 20, 2015 at 6:41 PM, Jack Diederich wrote: > Twelve years ago a wise man said to me "I suggest that you also propose a > new name for the resulting language" > > I talked with many of you at PyCon about the costs of PEP 484. There are > plenty of people who have done a fine job promoting the benefits. > > * It is not optional. Please stop saying that. The people promoting it > would prefer that everyone use it. If it is approved it will be optional in > the way that PEP8 is optional. If I'm reading your annotated code it is > certainly /not/ optional that I understand the annotations. > > * Uploading stubs for other people's code is a terrible idea. Who do I > contact when I update the interface to my library? The random Joe who > "helped" by uploading annotations three months ago and then quit the > internet? I don't even want to think about people maliciously adding stubs > to PyPI. > > * The cognitive load is very high. The average function signature will > double in length. This is not a small cost and telling me it is "optional" > to pretend that every other word on the line doesn't exist is a farce. > > * Every company's style guide is about to get much longer. That in itself > is an indicator that this is a MAJOR language change and not just some > "optional" add-on. > > * People will screw it up. The same people who can't be trusted to program > without type annotations are also going to be *writing* those type > annotations. > > * Teaching python is about to get much less attractive. It will not be > optional for teachers to say "just pretend all this stuff over here doesn't > exist" > > * "No new syntax" is a lie. Or rather a red herring. There are lots of new > things it will be required to know and just because the compiler doesn't > have to change doesn't mean the language isn't undergoing a major change. > > If this wasn't in a PEP and it wasn't going to ship in the stdlib very few > people would use it. If you told everyone they had to install a different > python implementation they wouldn't. This is much worse than that - it is > Python4 hidden away inside a PEP. > > There are many fine languages that have sophisticated type systems. And > many bondage & discipline languages that make you type things three times > to make really really sure you meant to type that. If you find those other > languages appealing I invite you to go use them instead. > > -Jack > > https://mail.python.org/pipermail/python-dev/2003-February/033291.html > > ___ > 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 [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. 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] async/await PEP
On Apr 21, 2015, at 3:23 AM, Martin Teichmann wrote: > > Hi Yury, Hi List, > > I do certainly like the idea of PEP 492, just some small comments: > > why do we need two keywords? To me it is not necessarily intuitive > when to use async and when to use await (why is it async for and not > await for?), so wouldn't it be much simpler, and more symmetric, to > just have one keyword? I personally prefer await for that, then it is > "await def", and "await for" (and "await with", etc.). Based on my understanding, you use ``async`` for blocks that can _use_ ``await``, and ``await`` to wait on an asynchronous action, such as calling an ``async`` function. ___ 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] PEP 3152 and yield from Future()
Then blow it up like Duck Dynasty does. On April 23, 2015 12:07:46 PM CDT, Antoine Pitrou wrote: >On Thu, 23 Apr 2015 09:58:33 -0700 >Guido van Rossum wrote: >> I think this is the nail in PEP 3152's coffin. > >If you only put one nail, it might manage to get out. > >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/rymg19%40gmail.com -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ 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] Sub-claasing pathlib.Path seems impossible
http://stackoverflow.com/a/29880095/2097780
My favorite thing about Python is that it's so easy to be evil. ;)
On Fri, May 1, 2015 at 2:30 PM, Christophe Bal wrote:
> Hello.
>
> In this post
> <http://stackoverflow.com/questions/29850801/simple-subclassing-pathlib-path-does-not-work/29854141#29854141>,
> I have noticed a problem with the following code.
>
> from pathlib import Path
>> class PPath(Path):
>> def __init__(self, *args, **kwargs):
>> super().__init__(*args, **kwargs)
>>
>> test = PPath("dir", "test.txt")
>>
>>
> This gives the following error message.
>
>
>
>> Traceback (most recent call last):
>> File "/Users/projetmbc/test.py", line 14, in
>> test = PPath("dir", "test.txt")
>> File "/anaconda/lib/python3.4/pathlib.py", line 907, in __new__
>> self = cls._from_parts(args, init=False)
>> File "/anaconda/lib/python3.4/pathlib.py", line 589, in _from_parts
>> drv, root, parts = self._parse_args(args)
>> File "/anaconda/lib/python3.4/pathlib.py", line 582, in _parse_args
>> return cls._flavour.parse_parts(parts)AttributeError: type object
>> 'PPath' has no attribute '_flavour'
>>
>>
> This breaks the sub-classing from Python point of view. In the post
> <http://stackoverflow.com/questions/29850801/simple-subclassing-pathlib-path-does-not-work/29854141#29854141>,
> I give a hack to sub-class Path but it's a bit Unpythonic.
>
> *Christophe BAL*
> *Enseignant de mathématiques en Lycée **et développeur Python amateur*
> *---*
> *French math teacher in a "Lycée" **and **Python **amateur developer*
>
> ___
> 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
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
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] PEP 492: async/await in Python; version 5
This draft proposal for async generators in ECMAScript 7 may be interesting reading to those who haven’t already: https://github.com/jhusain/asyncgenerator <https://github.com/jhusain/asyncgenerator> This talk also has some good ideas about them, though the interesting stuff about using async generator syntax is all on the last slide, and not really explained: https://www.youtube.com/watch?v=gawmdhCNy-A <https://www.youtube.com/watch?v=gawmdhCNy-A> > On May 5, 2015, at 3:55 PM, Guido van Rossum wrote: > > One small clarification: > > On Tue, May 5, 2015 at 12:40 PM, Jim J. Jewett <mailto:jimjjew...@gmail.com>> wrote: > [...] but I don't understand how this limitation works with things like a > per-line file iterator that might need to wait for the file to > be initially opened. > > Note that PEP 492 makes it syntactically impossible to use a coroutine > function to implement an iterator using yield; this is because the generator > machinery is needed to implement the coroutine machinery. However, the PEP > allows the creation of asynchronous iterators using classes that implement > __aiter__ and __anext__. Any blocking you need to do can happen in either of > those. You just use `async for` to iterate over such an "asynchronous stream". > > (There's an issue with actually implementing an asynchronous stream mapped to > a disk file, because I/O multiplexing primitives like select() don't actually > support waiting for disk files -- but this is an unrelated problem, and > asynchronous streams are useful to handle I/O to/from network connections, > subprocesses (pipes) or local RPC connections. Checkout the streams > <https://docs.python.org/3/library/asyncio-stream.html> and subprocess > <https://docs.python.org/3/library/asyncio-subprocess.html> submodules of the > asyncio package. These streams would be great candidates for adding > __aiter__/__anext__ to support async for-loops, so the idiom for iterating > over them can once again closely resemble the idiom for iterating over > regular (synchronous) streams using for-loops.) > > -- > --Guido van Rossum (python.org/~guido <http://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/ryan%40ryanhiebert.com ___ 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] Interesting what version of python should I start with
This list is for development of Python itself, not development with Python. You want python-list: https://mail.python.org/mailman/listinfo/python-list That being said: use the latest version (3.6 as of right now). On Thu, Nov 2, 2017 at 12:52 PM, Bob Woolsey wrote: > > > Sent from my iPhone > ___ > 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 (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ ___ 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] Removing files from the repository
Doesn't Git make this rather easy, though? e.g. you can find all deleted files with: git log --diff-filter=D --summary and find a specific file with (showing glob patterns): git log --all --full-history -- **/thefile.* and then show it: git show -- or restore it: git checkout ^ -- https://stackoverflow.com/questions/7203515/git-how-to-search-for-a-deleted-file-in-the-project-commit-history On Wednesday, November 29, 2017 12:26:01 PM CST, Serhiy Storchaka wrote: After removing files from the repository they disappear from the source tree, and it is even hard to notice this if you don't use it regularly. It is hard to track the history of the removed file even if you know it exact path. If you know it only approximate this is harder. I think that any file removals from the repository should pass some PEP-like process. Declaring the intention with the rationale, taking a feedback, discussing, and finally documenting the removal. Perhaps it is worth to track all removals in a special file, so if later you will find that the removed file can be useful you could restore it instead of recreating its functionality from zero in the case if you even don't know that similar file existed. -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ ___ 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] Mostly Official Python Development Container Image
Question: why is this using GitLab while CPython itself is using GitHub + Travis? On December 10, 2017 6:13:53 PM CST, Barry Warsaw wrote: >As part of our work on importlib_resources, and with some fantastic >help from Abhilash Raj, we now have a mostly official Python >development container image that you can use for CI testing and other >development purposes. > >This image is based on Ubuntu 16.04 LTS and provides the latest stable >releases of Python 2.7, and 3.4-3.6, along with a mostly up-to-date git >checkout of master, currently Python 3.7 of course. Once 3.7 is >released to beta, we intend to track its release tarballs too. Note >that these are pristine builds of upstream releases, so they don’t have >any of the Ubuntu or Debian platform changes. > >We also install a few other commonly needed tools, like pip, git, >unzip, wget, mypy, and tox. > >We do *not* recommend this image for application deployment purposes; >use this for development and testing only, please. > >Here’s the project repo: > >https://gitlab.com/python-devs/ci-images > >We’re publishing this image automatically to quay.io, so you can pull >the image in a .gitlab-ci.yml file to run tests against all these >versions of Python. Here’s an example from the importlib_resources >project: > >https://gitlab.com/python-devs/importlib_resources/blob/master/.gitlab-ci.yml > >We welcome contributors on the ci-images GitLab project! > >Cheers, >-Barry -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/___ 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] Trying to build from source, test-poplib fails
Do you have ca-certificates installed? On April 7, 2018 5:33:35 PM Skip Montanaro wrote: It's been a long while since I rebuilt Python from the Git source. I tried for the first time the other day. Everything passed except test_poplib and test_asyncio. The former just runs and runs and runs. Here's the first traceback I encounter when executing ./python Lib/test/test_poplib.py: test_stls_context (__main__.TestPOP3Class) ... Exception in thread Thread-16: Traceback (most recent call last): File "/home/skip/src/python/cpython/Lib/threading.py", line 917, in _bootstrap_inner self.run() File "Lib/test/test_poplib.py", line 227, in run asyncore.loop(timeout=0.1, count=1) File "/home/skip/src/python/cpython/Lib/asyncore.py", line 207, in loop poll_fun(timeout, map) File "/home/skip/src/python/cpython/Lib/asyncore.py", line 150, in poll read(obj) File "/home/skip/src/python/cpython/Lib/asyncore.py", line 87, in read obj.handle_error() File "/home/skip/src/python/cpython/Lib/asyncore.py", line 83, in read obj.handle_read_event() File "/home/skip/src/python/cpython/Lib/asyncore.py", line 422, in handle_read_event self.handle_read() File "Lib/test/test_poplib.py", line 194, in handle_read self._do_tls_handshake() File "Lib/test/test_poplib.py", line 174, in _do_tls_handshake self.socket.do_handshake() File "/home/skip/src/python/cpython/Lib/ssl.py", line 1108, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown (_ssl.c:1049) I thought perhaps I was missing something, but _ssl built just fine. I believe I have a recent enough version of libssl (1.0.2g), and I'm on a pretty vanilla system (up-to-date Ubuntu 17.10). SSL-wise: % apt search ssl | grep installed | egrep '^lib' | egrep ssl libgnutls-openssl27/artful,now 3.5.8-6ubuntu3 amd64 [installed] libio-socket-ssl-perl/artful,artful,now 2.050-1 all [installed] libnet-smtp-ssl-perl/artful,artful,now 1.04-1 all [installed] libnet-ssleay-perl/artful,now 1.80-1build1 amd64 [installed] libssl-dev/artful-updates,artful-security,now 1.0.2g-1ubuntu13.4 amd64 [installed] libssl-doc/artful-updates,artful-updates,artful-security,artful-security,now 1.0.2g-1ubuntu13.4 all [installed,automatic] libssl1.0.0/artful-updates,artful-security,now 1.0.2g-1ubuntu13.4 amd64 [installed] Any clues about what I might be missing from my setup would be appreciated. Not sure what was wrong with test_asyncio. I ran it in isolation and it passed. Thx, Skip ___ 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 (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ ___ 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] Is PEP 572 really the most effective way to solve the problems it's targeting?
I have to say I'm not overly thrilled with PEP 572...it's almost odd,
because if you asked me back when I first joined this list when I was 13, I
would've no doubt said *YES*. But, since then, I've gone across many
projects and languages, and fundamentally *I have never felt hurt by the
lack of assignment in an expression*, and I always regretted every time I
tried it in C or Crystal. I understand this experience is pretty
insignificant in comparison to many of the wizards here, but I thought I'd
still share it as an opener for what I'm about to say.
With this being said, I'd encourage everyone to take a bit of a step back:
what exactly are people looking for in PEP 572?
I see two main goals:
- Assignment in a conditional structure.
- Assignment in a list comprehension.
Most other use cases would significantly hurt readability and seem pretty rare.
Now let's break down the top one:
- Assignment in an if condition.
- Assignment in a while condition.
So there are roughly three main goals here overall. Now, are there better
ways to solve these?
(FWIW C solved the while condition one with the C-style for loop, but I'm
pretty sure few people here would really go for that.)
C++ has recently solved the if condition by allowing declarations inside
the conditions:
if (auto a = 123; a != 456) {
Many languages have a 'let' expression (using Felix as my example):
if let a = 1, b = 2 in a == b then
Swift has taken a bit of a hybrid between the above two:
if let a = 1, b = 2, a == b {
Now, what's the common theme here? **Declarations should be separate from
expressions.** We've got languages that range from baggage-filled to
functional to a bit of all of the above, and none of them have added
assignment *inside* an expression.
The argument is roughly the same across all boards: you're putting major
but easy-to-miss side effects in the midst of expressions that *seem* pure.
All this is to say: I'd really encourage everyone here to think a bit more
about *why* exactly you want this feature, and then think if there's really
no better way. Any solution that separates declarations would be far more
readable, (arguably) more Pythonic, and play more nicely with the new-ish
typing features to boot
I understand reluctance to add a syntax exception like this, but I really
feel it'd be worth it.
As a side note, I was a strong supporter of comprehension generalizations,
f-strings, *and* dataclasses. However, this proposal seems a bit ugly and
excessive for what it's trying to accomplish.
P.S. Yes, the unmatched curly braces were intentional to drive you crazy
for a few hours. I blame Randall Monroe. You're welcome.
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
___
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] Is PEP 572 really the most effective way to solve the problems it's targeting?
On April 25, 2018 11:05:04 PM Steven D'Aprano wrote: On Wed, Apr 25, 2018 at 09:36:31PM -0500, Ryan Gonzalez wrote: I have to say I'm not overly thrilled with PEP 572...it's almost odd, because if you asked me back when I first joined this list when I was 13, I would've no doubt said *YES*. I have the opposite experience: I've warmed to it the more I have read it. Before Chris had even written this PEP, there was a Python-Ideas thread asking for dedicated syntax in comprehensions alone that would have been equivalent to a binding-expression. I was rather negative about the whole thing (but no where near as negative as I've been in the past when this has come up before), until Chris pointed out that such binding-expressions have value outside of comprehensions. [...] Now, what's the common theme here? **Declarations should be separate from expressions.** Declarations and assignments are not the same thing. Yeah, this is what happens when I write these things when tired... I meant to also mention assignments here, and anywhere else I may have used "declaration". We've got languages that range from baggage-filled to functional to a bit of all of the above, and none of them have added assignment *inside* an expression. And your claim about assignment inside expressions is only true if you ignore the languages where assignment is an expression with a return value. You know, strange and exotic languages with hardly any users or influence, like C, C++, C#, Java, Javascript, Ruby, Perl, PHP, Lisp ... In the majority of these, however, mixing assignments into expressions is considered bad practice. For instance: - C++ core guidelines: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-complicated - MediaWiki style guide: https://m.mediawiki.org/wiki/Manual:Coding_conventions/PHP Some of the other languages (e.g. Perl) aren't some I'd regard as positive influences... -- Steve ___ 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 (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ ___ 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] Is PEP 572 really the most effective way to solve the problems it's targeting?
On April 27, 2018 12:16:09 AM Mike Miller wrote: Sorry all, wasn't specific enough. By "modern" I mean the last decade perhaps. New languages that have had a chance to look at the older generations and choose their best ideas, while leaving behind the rest. Personally I thought of Swift (Ryan mentioned), Kotlin, Rust, and perhaps Go, though Go wasn't focused on breaking new ground outside of ease of concurrency. I don't know R or Felix at all, but sound interesting. Nim is another I'm vaguely aware of. They surely have given some thought to the issue. One thing that jumped out at me is that most replies here jumped to the question of whether they supported assignment-expressions, but that is only one potential solution. To be more clear, I wondered how did they solve "the problem itself?" Was their solution different? Ryan somewhat alluded to that, but I'd like to dig in a bit on that part. In contrast, in many of the other threads I heard, "C, C++, C#, Java, etc do assignment-expressions, they're useful and not so hard to learn." Ok that's reasonable, but where is the industry headed? Python deferred long enough that we don't necessarily have to choose a classic solution. So, it sounds like many of the new generation of languages are not embracing these expressions everywhere but rather letting folks do an assignment right in the statement where their use case applies, if, while, maybe comprehensions. Is that accurate? This is basically what I was trying to say, except far better worded... Looks like I've got some homework to do, haha. -Mike On 2018-04-26 17:58, Steven D'Aprano wrote: What counts as a modern language? Less than five years old? Less than fifty years old? Are Javascript, Ruby and R modern? They all support assignment as expressions. I think Koitlin, Rust and Go prohibit assignment as expressions. Swift assignment evaluates as Void (equivalent to None in Python, I guess), so you can use assignment in an expression but it returns nothing and only operates by side-effect. As far as type hints go, I think that if you need explicit type hints in the middle of an expression, it's a bad idea and you ought to pull it out as a separate statement. That applies regardless of whether that expression involves binding or not. ___ 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 (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ ___ 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] Python startup time
I'm hardly an expert, but AFAIK CPython's start-up issues are more due to a mix of architectural issues and the fact that it's hard to optimize imports while maintaining backwards compatibility with Python's dynamism. -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ On May 3, 2018 1:37:57 AM Glenn Linderman wrote: On 5/2/2018 8:56 PM, Gregory Szorc wrote: Nobody in the project is seriously talking about a complete rewrite in Rust. Contributors to the project have varying opinions on how aggressively Rust should be utilized. People who contribute to the C code, low-level primitives (like storage, deltas, etc), and those who care about performance tend to want more Rust. One thing we almost universally agree on is that we want to rewrite all of Mercurial's C code in Rust. I anticipate that figuring out the balance between Rust and Python in Mercurial will be an ongoing conversation/process for the next few years. Have you considered simply rewriting CPython in Rust? And yes, the 4th word in that question was intended to produce peals of shocked laughter. But why Rust? Why not Go? http://esr.ibiblio.org/?p=7724 -- ___ 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 ___ 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] Drop/deprecate Tkinter?
On May 3, 2018 11:56:24 AM MRAB wrote: On 2018-05-03 13:24, Steve Holden wrote: On Thu, May 3, 2018 at 12:12 AM, Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>> wrote: On 03.05.2018 1:01, Antoine Pitrou wrote: On Wed, 2 May 2018 22:54:04 +0100 Paul Moore mailto:p.f.mo...@gmail.com>> wrote: On 2 May 2018 at 22:37, Antoine Pitrou mailto:solip...@pitrou.net>> wrote: To elaborate a bit: the OP, while angry, produced both a detailed analysis *and* a PR. It's normal to be angry when an advertised feature doesn't work and it makes you lose hours of work (or, even, forces you to a wholesale redesign). Producing a detailed analysis and a PR is more than most people will ever do. His *other* email seems reasonable, and warrants a response, yes. But are we to take the suggestion made here (to drop tkinter) seriously, based on the fact that there's a (rare - at least it appears that the many IDLE users haven't hit it yet) race condition that causes a crash in Python 2.7? (It appears that the problem doesn't happen in the python.org <http://python.org> 3.x builds, if I understand the description of the issue). In 3.x, Tkinter+threads is broken too, albeit in a different way -- see https://bugs.python.org/issue33412 <https://bugs.python.org/issue33412> (this should've been the 2nd link in the initial message, sorry for the mix-up). The observation in that issue that tkinter and threads should be handled in specific ways is certainly a given for old hands, who have long put the GUI code in one thread with one or more concurrent worker threads typically communicating through queues. But I haven't built anything like that recently, so I couldn't say how helpful the current documenation might be. Interacting with the GUI only in the main thread is something that I've had to do in other languages (it is/was the recommended practice), so I naturally do the same with Python and tkinter. It's also easier to reason about because you don't get elements of the GUI changing unexpectedly. To add to this, most GUI frameworks disallow modifications outside the main thread altogether. IIRC both GTK+ and Qt require this, or else it's undefined altogether. [snip] ___ 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 (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ ___ 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] Slow down...
10 years feels like a simultaneously long and arbitrary limit. IMO a policy of "try to avoid major language features for a while" would work better. On Mon, May 7, 2018 at 2:11 PM Craig Rodrigues wrote: > > > On Sun, May 6, 2018 at 7:35 PM Nick Coghlan wrote: > >> >> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 >> language moratorium could be a very good idea. Between matrix >> multiplication, enhanced tuple unpacking, native coroutines, f-strings, and >> type hinting for variable assignments, we've had quite a bit of syntactic >> churn in the past few releases, and the rest of the ecosystem really hasn't >> caught up on it all yet (and that's not just other implementations - it's >> training material, online courses, etc, etc). >> >> If we're going to take such a step, now's also the time to do it, since >> 3.8 feature development is only just getting under way, and if we did >> decide to repeat the language moratorium, we could co-announce it with the >> Python 3.7 release. >> >> > Would it be reasonable to request a 10 year moratorium on making changes > to the core Python language, > and for the next 10 years only focus on things that do not require core > language changes, > such as improving/bugfixing existing libraries, writing new libraries, > improving tooling, improving infrastructure (PyPI), > improving performance, etc., etc.? > > There are still many companies still stuck on Python 2, so giving 10 years > of breathing room > for these companies to catch up to Python 3 core language, even past 2020 > would be very helpful. > > -- > Craig > ___ > 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 (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ ___ 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] A fast startup patch (was: Python startup time)
On May 7, 2018 9:15:32 PM Steve Dower wrote: “the data shows that a focused change to address file system inefficiencies has the potential to broadly and transparently deliver benefit to users without affecting existing code or workflows.” This is consistent with a Node.js experiment I heard about where they compiled an entire application in a single (HUGE!) .js file. Reading a single large file from disk is quicker than many small files on every significant file system I’m aware of. Is there benefit to supporting import of .tar files as we currently do .zip? Or perhaps having a special fast-path for uncompressed .zip files? I kind of built something like this, though I haven't really put in the effort to make it overly usable yet: https://github.com/kirbyfan64/bluesnow (Bonus points to anyone who gets the character reference in the name, though I seriously doubt it.) Main thing I noticed was that reading compiled .pyc files is far faster than uncompiled Python code, even if you eliminate the disk access. Kind of obvious in retrospect, but still something to note However, there are more obstacles to this in the Python world than the JS world. C extensions have a heavier prevalence here, distribution is a bit weirder (sorry, even with Pipfiles), and JavaScript already has an entire ecosystem built around packing files together from the web world. Top-posted from my Windows phone From: Carl Shapiro Sent: Monday, May 7, 2018 14:36 To: Nathaniel Smith Cc: Nick Coghlan; Python Dev Subject: Re: [Python-Dev] A fast startup patch (was: Python startup time) On Fri, May 4, 2018 at 6:58 PM, Nathaniel Smith wrote: What are the obstacles to including "preloaded" objects in regular .pyc files, so that everyone can take advantage of this without rebuilding the interpreter? The system we have developed can create a shared object file for each compiled Python file. However, such a representation is not directly usable. First, certain shared constants, such as interned strings, must be kept globally unique across object code files. Second, some marshaled objects, such as the hashed collections, must be initialized with randomization state that is not available until after the hosting runtime has been initialized. We are able to work around the first issue by generating a heap image with the transitive closure of all modules that will be loaded which allows us to easily maintain uniqueness guarantees. We are able to work around the second issue with some unobservable changes to the affected data structures. Based on our numbers, it appears there should be some hesitancy--at this time--to changing the format of compiled Python file for the sake of load-time performance. In contrast, the data shows that a focused change to address file system inefficiencies has the potential to broadly and transparently deliver benefit to users without affecting existing code or workflows. -- ___ 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 (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ ___ 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] Python startup time
https://refi64.com/uprocd/ On May 11, 2018 9:39:28 AM Chris Barker - NOAA Federal via Python-Dev wrote: Inspired by chg: Could one make a little startup utility that, when invoked the first time, starts up a raw python interpreter, keeps it running somewhere, and then forks it to run the actual python code. Then every invocation after that would make a new fork. I presume forking is a LOT faster than re-invoking the entire startup. I suspect that many of the cases where startup time really matters is when a command line utility is likely to be invoked many times — often in the same shell instance. So having a “pre-built” warm interpreter ready to go could really help. This is way past my technical expertise to know if it’s possible, or to try to prototype it, but I’m sure many of you would know. -CHB Sent from my iPhone On May 7, 2018, at 12:28 PM, Neil Schemenauer wrote: On 2018-05-03, Lukasz Langa wrote: On May 2, 2018, at 8:57 PM, INADA Naoki wrote: * Add lazy compiling API or flag in `re` module. The pattern is compiled when first used. How about go the other way and allow compiling at Python *compile*-time? That would actually make things faster instead of just moving the time spent around. Lisp has a special form 'eval-when'. It can be used to cause evaluation of the body expression at compile time. In Carl's "A fast startup patch" post, he talks about getting rid of the unmarshal step and storing objects in the heap segment of the executable. Those would be the objects necessary to evaluate code. The marshal module has a limited number of types that it handle. I believe they are: bool, bytes, code objects, complex, Ellipsis float, frozenset, int, None, tuple and str. If the same mechanism could handle more types, rather than storing the code to be evaluated, we could store the objects created after evaluation of the top-level module body. Or, have a mechanism to mark which code should be evaluated at compile time (much like the eval-when form). For the re.compile example, the compiled regex could be what is stored after compiling the Python module (i.e. the re.compile gets run at compile time). The objects created by re.compile (e.g. SRE_Pattern) would have to be something that the heap dumper could handle. Traditionally, Python has had the model "there is only runtime". So, starting to do things at compile time complicates that model. Regards, Neil ___ 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/chris.barker%40noaa.gov ___ 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 ___ 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] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
AFAIK there's no setting like this available, and I've done this many times on other repos with no trouble. Maybe it could be a GitHub bug? On May 28, 2018 4:59:03 AM Victor Stinner wrote: Hi, Since one or two weeks, I noticed that it's difficult to merge pull requests into the 2.7 branch. If a different commit is pushed in the meanwhile (if a different PR has been merged), the 2.7 branch diverges and the PR is immediately marked as "This branch is out-of-date with the base branch" and the "Squash and Merge" button is disabled (grey). For example my PR https://github.com/python/cpython/pull/7120 which changes Lib/test/regrtest.py cannot be merged because a commit touching the documentation (Doc/ directory) has been merged after I posted my PR and before the CI completed. I don't see the same behavior on the master branch. Is the 2.7 branch configured as more strict? Victor ___ 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 ___ 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] Unable to build regex module against Python 3.5 32-bit
Try building the module with -m32. The error message basically means: "../libpython35.a is 32-bit, but what you're building is 64-bit." Gotta love ld! On May 25, 2015 3:06:01 PM CDT, MRAB wrote: >As the subject says, I've been unable to build the regex module against >Python 3.5b1 for 32-bit. MingGW says: > > skipping incompatible .../libpython35.a when searching for -lpython35 > >It builds without a problem against Python 3.5 for 64-bit. > >Any ideas? Should I just wait until beta 2? >___ >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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ 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] Single-file Python executables (was: Computed Goto dispatch for Python 2)
py2exe tends to invoke DLL hell if you have various versions of VS or Office or both installed. Because Windows. On May 28, 2015 11:23:57 AM CDT, Chris Barker wrote: >I'm confused: > >Doesn't py2exe (optionally) create a single file executable? > >And py2app on the Mac creates an application bundle, but that is >more-or-less the equivalent on OS-X (you may not even be able to have a >single file executable that can access the Window Manager, for >instance) > >Depending on what extra packages you need, py2exe's single file doesn't >always work, but last I tried, it worked for a fair bit (I think all of >the >stdlib). > >I don't know what PyInstaller or others create. And I have no idea if >there >is a linux option -- but it seems like the standard of practice for an >application for linux is a bunch of files scattered over the system >anyway >:-) > >Yes, the resulting exe is pretty big, but it does try to include only >those >modules and packages that are used, and that kind of optimization could >be >improved in any case. > >So is something different being asked for here? > >Barry Warsaw wrote: >>> I do think single-file executables are an important piece to >Python's long-term >competitiveness. > >Really? It seems to me that desktop development is dying. What are the >critical use-cases for a single file executable? > >And I'd note that getting a good way to use Python to develop for iOS, >Android, and Mobile Windows is FAR more critical! -- maybe that's the >same >problem ? > >-Chris > > >On Thu, May 28, 2015 at 8:39 AM, Donald Stufft >wrote: > >> >> >> On May 28, 2015 at 11:30:37 AM, Steve Dower >(steve.do...@microsoft.com) >> wrote: >> > Donald Stufft wrote: >> > > Well Python 3.4.3 binary is 4kb for me, so you'd have that + your >1KB >> Python script + whatever >> > other pieces you need. >> > >> > For contrast, here are the things you need on Windows to be able to >get >> to an interactive >> > prompt (I don't know how other platforms get this down to 4KB...): >> > >> > * python.exe (or some equivalent launcher) 39KB >> > * python35.dll 3,788KB >> > * vcruntime140.dll 87KB (the rest of the CRT is about 1MB, but is >not >> redistributable >> > so doesn't count here) >> > * 26 files in Lib 343KB >> > >> > This gets you to ">>>", and basically everything after that is >going to >> fail for some reason. >> > That's an unavoidable 4,257KB. >> > >> > The rest of the stdlib adds another ~16MB once you exclude the test >> suite, so a fully functioning >> > Python is not cheap. (Using compressed .pyc's in a zip file can >make a >> big difference here >> > though, assuming you're willing to trade CPU for HDD.) >> > >> > Cheers, >> > Steve >> > >> > >> >> You don’t need a "fully functioning Python" for a single file binary, >you >> only >> need enough to actually run your application. For example, if you're >making >> an application that can download files over HTTP, you don't need to >include >> parts of the stdlib like xmlrpc, pickle, shelve, marshall, sqlite, >csv, >> email, >> mailcap, mailbox, imaplib, nntplib, etc. >> >> Of course deciding which pieces you include in the zip file you're >> appending >> to the end of Python is up to whatever tool builds this executable >which >> doesn't need to be part of Python itself. If Python itself gained the >> ability >> to operate in that manner than third party tools could handle trying >to do >> the >> optimizations where it only includes the things it actually needs in >the >> stdlib >> and excludes things it doesn't. The key thing here is that since >you're >> doing >> a single file binary, you don't need to have a Python which is >suitable to >> execute random Python code, you only need one that is suitable to >execute >> this >> particular code so you can specialize what that includes. >> >> --- >> Donald Stufft >> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >> >> >> ___ >> 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/chris.barker%40noaa.gov >> > > > >-- > >Christopher Barker, Ph.D. >Oceanographer > >Emergency Response Division >NOAA/NOS/OR&R(206) 526-6959 voice >7600 Sand Point Way NE (206) 526-6329 fax >Seattle, WA 98115 (206) 526-6317 main reception > >chris.bar...@noaa.gov > > > > >___ >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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailma
Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)
I agree that size is an issue, but is it really that bad? Just compare it to the recent "web surge" where everyone is writing desktop apps in HTML5+CSS+JS and bundling a huge WebKit engine in their apps binary. Python on Windows is seriously in a bad state. IMO, what needs to be prioritized is the ability to make exes that *actually work* with nicer GUI abilities. py2exe gives too many random DLL errors and PyInstaller is an ugly hack that just shoves 20 DLLs with your executable. Mixed with the fact that TkInter looks even uglier when built via py2exe and almost everything else (PyGI, PySide, etc.) requires yet another 20 DLLs (PySide threw in Qt DLLs that I didn't even use!), it's sad. Really sad. This is most of the reason I write programs that I plan on distributing to various crowds in some statically compiled language (C++, Nim, Felix, not Go) with (when necessary) a statically-linked GUI library. Less DLL hell, less free files, etc. Oh yeah, and add to that the problems with running both Python 2 and 3 on Windows while using some binaries that want 3 and others that want 2. It's painful. On May 28, 2015 10:30:33 AM CDT, Steve Dower wrote: >Donald Stufft wrote: >> Well Python 3.4.3 binary is 4kb for me, so you'd have that + your 1KB >Python script + whatever other pieces you need. > >For contrast, here are the things you need on Windows to be able to get >to an interactive prompt (I don't know how other platforms get this >down to 4KB...): > >* python.exe (or some equivalent launcher) 39KB >* python35.dll 3,788KB >* vcruntime140.dll 87KB (the rest of the CRT is about 1MB, but is not >redistributable so doesn't count here) >* 26 files in Lib 343KB > >This gets you to ">>>", and basically everything after that is going to >fail for some reason. That's an unavoidable 4,257KB. > >The rest of the stdlib adds another ~16MB once you exclude the test >suite, so a fully functioning Python is not cheap. (Using compressed >.pyc's in a zip file can make a big difference here though, assuming >you're willing to trade CPU for HDD.) > >Cheers, >Steve > >___ >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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ 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] Computed Goto dispatch for Python 2
YESSS!!! On Thu, May 28, 2015 at 8:09 PM, Larry Hastings wrote: > On 05/28/2015 05:58 PM, Victor Stinner wrote: > > Why not continue to enhance Python 3 instead of wasting our time with > Python 2? We have limited resources in term of developers to maintain > Python. > > > Uh, guys, you might as well call off the debate. Benjamin already checked > it in. > > https://hg.python.org/cpython/rev/17d3bbde60d2 > > > */arry* > > ___ > 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 [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. 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] Single-file Python executables (was: Computed Goto dispatch for Python 2)
I did that once; it wasn't worth it. It was no smaller than what PyInstaller would output and required manually adding in the required modules that weren't in the stdlib, along with any extra DLLs (e.g. the Qt DLLs). On Fri, May 29, 2015 at 4:45 PM, Paul Moore wrote: > On 29 May 2015 at 21:49, Glenn Linderman wrote: > > > > That looks interesting, I wonder what compilation environment it would > need? > > I don't think I've even installed a C compiler on my last couple boxes, > and > > the only version of a C compiler I have is, umm... M$VC++6.0, since I've > > moved to using Python for anything a 5 line batch file can't do... > > > >> One mildly annoying thing is that python3.dll is only installed in > >> \DLLs, which typically isn't on PATH. > > > > Ah, linking so I guess if I figured out how to create this binary, it > > would contain a reference to python3.dll that would attempt to be > resolved > > via the PATH, from what you say, and typically fail, due to PATH seldom > > containing python3.dll. The python launcher gets around that by (1) > being > > installed in %windir%, and going and finding the appropriate Python (per > its > > own configuration file, and command line parameters), and setting up the > > path to that Python, which, when executed, knows its own directory > structure > > and can thus find its own python3.dll. > > > > The launcher, of course, adds an extra layer of process between the shell > > and the program, because it launches the "real" Python executable. > > > >> So actually using the limited API from your own application fails by > >> default. > >> Fixing that's mostly a user admin issue, though (and you can just link > >> to the full API and avoid the whole problem). > > > > > > Do I understand correctly that the "user admin issue" means "add the > > appropriate \DLLs to the PATH"? > > > > What I don't understand here is how linking to the full API avoids the > > problem... it must put more python library code into the stub executable? > > Enough to know how to search the registry to find the dir> > > for the version of Python from which the full API was obtained? Or > something > > else? > > Sorry, I assumed more Windows/C knowledge than you have. > > I'll work on this and produce proper binaries in due course, so you > can always wait for them. But you can build the stub with pretty much > anything, I suspect - I managed with MSVC 2010 and mingw. I'll add > some build docs and get it on github. > > Using mingw > > gcc -Wall -O2 -o stub.exe stub.c -I \Include > C:\Windows\system32\python34.dll > strip -s stub.exe > > Using MSVC > > cl /Festub.exe /O2 stub.c /I\Include home>\libs\python34.lib > > Regarding the DLLs, yes the "user admin issue" is adding the right > directory to PATH. I used the phrase "admin issue" as it's the aspect > that's likely to be far harder than any of the technical issues :-) > The reason using the full API helps is that the full API references > python34.dll rather than python3.dll. And the Python installer puts > python34.dll on PATH automatically, as it's what the "python" command > uses. (For the people with more Windows knowledge, I know this is a > simplification, but it's close enough for now). > > So there are two options with the code I posted. > > 1. Build an exe that uses a specific version of Python, but which will > "just work" in basically the same way that the "python" command works. > 2. Build an exe that works with any version of Python, but requires > some setup from the user. > > Either approach requires that the Python DLL is on PATH, but that's > far more likely with the version-specific one, just because of how the > installer does things. > > With extra code, the stub could locate an appropriate Python DLL > dynamically, which would simplify usage at the cost of a bit of fiddly > code in the stub. > > This might be a useful addition to the zipapp module for Python 3.6. > > Paul > > PS Current launchers (py.exe, the entry point launchers from > pip/setuptools, etc) tend to spawn the actual python program in a > subprocess. I believe there are *technically* some differences in the > runtime environment when you use an embedding approach like this, but > I don't know what they are, and they probably won't affect 99.9% of > users. Lack of support for binary extensions is likely to be way more > significant. > __
[Python-Dev] Where are bugs with the web site reported?
I have encountered this weird issue on Chrome for Android where scrolling up just a little causes the page to dart to the top. I was going to report it in the bug tracker, but I didn't see a label for the web site itself. Worst part is, this is stopping me from reading the humor page! -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ 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] Where are bugs with the web site reported?
Response from the Chrome devs: This site has JS that reacts to the viewport resize event from top controls showing by scrolling to the top. I guess the intent might be to scroll to the top when the phone rotates, and it overtriggers here. I don't think there's a short-term fix, but this seems like an interesting case to keep in mind while evolving viewport resize behaviors. On Thu, Jul 16, 2015 at 2:24 PM, Glenn Linderman wrote: > On 7/16/2015 12:11 PM, Ryan Gonzalez wrote: > > I have encountered this weird issue on Chrome for Android where scrolling > up just a little causes the page to dart to the top. I was going to report > it in the bug tracker, but I didn't see a label for the web site itself. > > Worst part is, this is stopping me from reading the humor page! > > > Sounds more like a bug in Chrome than on the site, unless it is repeatable > using other browsers, or unless the site has Chrome-specific code. > > ___ > 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 [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. 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] How far to go with user-friendliness
I am tempted to reply with a slightly sarcastic message involving a cookie... On July 17, 2015 6:40:21 PM CDT, Antoine Pitrou wrote: > >Frankly, this kind of inept discussion, where a bunch of folks get hung >up about an extremely minor design decision (who cares whether "assret" >is being special-cased or not? in the actual world, not the fantasy >world of righteous indignation and armchair architects?), is amongst >the reasons why I'm stopping contributing to CPython. > >Keep up the good work, you're making this place totally repulsive to >participate in. Every maintainer or contributor now has an army of >voluntary hair-splitters to bother about, most of whom probably aren't >relying on said functionality to begin with. > >Regards > >Antoine. > > > >On Fri, 17 Jul 2015 15:11:59 -0700 >Ethan Furman wrote: >> On 07/16/2015 11:30 PM, Nick Coghlan wrote: >> > On 17 July 2015 at 08:30, Ben Finney wrote: >> >> >> By definition, advocating to not add cruft to an API is going to >be in >> >> advance of being bitten by those additions. >> > >> > That's not what people are doing. Folks are actually arguing for >> > *restoring* the ability to mock out method names starting with >> > "assret_*". >> >> Why is that surprising? As somebody already mentioned (Terry, I >think?) "assret" is a fine abbreviation, as well as possibly being a >foreign word. >> >> > I still don't know why anyone thinks restoring that would be a >> > worthwhile use of a maintainers' time (or why they thinking arguing >in >> > favour of such a capability is a worthwhile use of theirs). >> >> 1) Because it shouldn't have been added in the first place. >> >> 2) Because DWIM does not belong in Python. >> >> > None of the perspectives presented in this thread are new, although >> > the apparent obsession over such a minor detail has made it >abundantly >> > clear that this kind of helper simply isn't worth the distraction >it >> > creates for maintainers, *regardless* of whether or not it helps >end >> > users. >> >> To be clear: >> >>- those who are upset over "assret" are not upset over "assert" >> >>- it is not Python's job (nor the stdlib's) to correct spelling >errors >> >> -- >> ~Ethan~ > > > >___ >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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ 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] Status on PEP-431 Timezones
> On Jul 25, 2015, at 09:15, Alexander Belopolsky > wrote: > > >> On Sat, Jul 25, 2015 at 2:40 AM, Lennart Regebro wrote: >> There really is a reason every other date time implementation I know >> of uses UTC internally, and there really is a reason why everyone >> always recommends storing date times in UTC with the time zone or >> offset separately. > > Current datetime design does not prevent your application from storing > date-times > in UTC. You can store them in naive datetime instances, but the recommended > approach is to use datetime instances with tzinfo=timezone.utc. Yes, and now he wants to do the same thing for the internals of the datetime module, for the same reasons that it's the best thing most everywhere else. It's just going to take some significant effort to make that happen.___ 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] Status on PEP-431 Timezones
> On Jul 27, 2015, at 9:13 AM, Steven D'Aprano wrote: > > On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote: >> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore wrote: >>> I'm confused by your position. If it's 7am on the clock behind me, >>> right now, then how (under the model proposed by the PEP) do I find >>> the datetime value where it will next be 7am on the clock? >> >> PEP-431 does not propose to implement calendar operations, and hence >> does not address that question. > > To me, Paul's example is a datetime operation: you start with a datetime > (7am today), perform arithmetic on it by adding a period of time (one > day), and get a datetime as the result (7am tomorrow). > > To my naive mind, I would have thought of calendar operations to be > things like: > > - print a calendar; > - add or remove an appointment; > - send, accept or decline an invitation > > What do you think calendar operations are, and how do they differ from > datetime operations? And most importantly, how can we tell them apart? The way I interpreted it is that "calendar operations" require knowledge of events like daylight savings time that require a more complete knowledge of the calendar, rather than just a naive notion of what a date and time are. ___ 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] Status on PEP-431 Timezones
> On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky > wrote: > > On the other hand, these rare events are not that different from more or less > regular DST > transitions. You still have either a non-existent or ambiguous local times > interval and > you can resolve the ambiguity by adding 1 bit of information. The only > question is what > should we call the flag that will supply that information? IMO, "isdst" is a > wrong name > for dealing with the event I described above. While I see your point that isdst is the wrong name in that it doesn't describe what's actually happening in all cases, it is the most well known instance of the issue, and I personally think that using isdst for the other cases makes sense, and that they would disambiguate in the same direction that it would in a dst transition of the same type (clocks forward or backward). ___ 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] Python Issue-subprocess problem
*before anyone else says it* This list is for development *of* Python, not *in* Python. If you need help with things like this, I'd advise you to use the python-list <https://mail.python.org/mailman/listinfo/python-list> mailing list or Stack Overflow <http://stackoverflow.com/>. On Thu, Aug 27, 2015 at 3:57 AM, Low, Wai HoeX wrote: > Dear, > > > > I have faced a problem as below when I startup the python IDLE > > > > [image: cid:image001.png@01D0E0CE.454096D0] > > > > Then I try to run a simple program like this: > > [image: cid:image002.png@01D0E0CE.454096D0] > > > > Other issue is pop out > > > > [image: cid:image003.png@01D0E0CE.454096D0] > > > > May I know how to fix the issue? My laptop is window 7 64bits. > > > > > > > > Thanks and having a nice day ! > > > > Regards, > > Arthur Low Wai Hoe > > > > ___ > 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 [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. 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
[Python-Dev] python programmer
Dear Admin, I am an IT/Project Management recruiter looking to increase the available pool of talent for available job placements. Currently I have an opening for a python programmer/developer. Could I post opportunities to your member list? Thank you, Linda Ryan Business Development Manager 770-313-2739 cell TenStep Inc www.TenStep.com<http://www.TenStep.com> ___ 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] What's New editing
On September 5, 2015 12:27:26 PM CDT, David Mertz wrote: >I have to apologize profusely here. Just after I offered to do this >(and >work even said it was OK in principle to do it on work time), my work >load >went through the roof. And now it's really already later than most of >it >should have been done. I'd still very much like to work on this, but I >wonder if maybe someone else would like to be co-author since the >increased >workload doesn't actually seem likely to diminish soon. So... I also have a lot of stuff right now, but it's not that bad...could I help out here? > >On Wed, Sep 2, 2015 at 7:03 PM, Yury Selivanov > >wrote: > >> >> >> On 2015-07-06 11:38 AM, David Mertz wrote: >> >>> Hi Folks, >>> >>> I hereby volunteer to write "What's New for Python 3.5?" if folks on >>> python-dev are fine with me taking the job (i.e. I ran it by Travis, >my >>> boss at Continuum, and he's happy to allow me to do that work within >my >>> salaried hours... so having time isn't a problem). >>> >>> If this is OK with the powers-that-be, I'll coordinate with David >Murray >>> on how best to take over this task from him. >>> >> >> Hi David, >> >> Are you still going to work on what's new for 3.5? >> >> Yury >> >> >> ___ >> 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/mertz%40gnosis.cx >> -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ___ 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] PEP: Collecting information about git
On September 12, 2015 6:14:58 PM CDT, Tim Delaney wrote: >On 13 September 2015 at 04:42, Oleg Broytman wrote: > >>There are too many things that I personally can do with git but >can't >> do with hg. Because of that I switched all my development from hg to >git >> and I am willing to help those who want to follow. >> > >Slightly off-topic, but personally I'd love to know what those are. >I've >yet to find anything in Git that I haven't been able to do at least as >well >with Mercurial (or an extension), and there are things Mercurial >supports that I use extensively (in particular named branches and >phases) >where the concept doesn't even exist in Git. > >I switched all of my development to Mercurial, and use hg-git and >hgsubversion when I need to interact with those systems. ...speed?? Seriously; just try pulling the entire CPython repo. Then try again with the GitHub mirror. I love Mercurial's CLI. But, every time I use it, I end up feeling like I'm waiting forever. Git's CLI is really weird, but it's surprisingly powerful and flexible once you get the hang of it (which admittedly might take a while!). > >Tim Delaney > > > > >___ >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 -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ___ 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] PEP: Collecting information about git
*cough* Google *cough* http://stackoverflow.com/questions/5911774/git-gui-like-hg-workbench-in-ms-windows SourceTree looks quite similar. On Thu, Sep 17, 2015 at 2:07 PM, Terry Reedy wrote: > On 9/17/2015 3:17 AM, André Freitas wrote: > >> Regarding Git tools for Windows, GitHub Desktop and Sourcetree are >> actually very good with nice features. >> > > Do you know if either have anything like TortoiseHg Workbench? > https://tortoisehg.readthedocs.org/en/latest/workbench.html > (screenshot at top) > > -- > Terry Jan Reedy > > > ___ > 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 [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. 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] Not Deprecating Arbitrary Function Annotations
There is one reason I would be really freaking mad if they deprecated other uses of annotations: https://pypi.python.org/pypi/plac On October 5, 2015 1:55:37 PM CDT, Steve Wedig wrote: >Congratulations on the release of 3.5 and Pep 484. I've used Python >professionally for 10 years and I believe type hints will make it >easier to >work with large codebases evolving over time. My only concern about Pep >484 >is the discussion of whether or not to deprecate arbitrary function >annotations. >https://www.python.org/dev/peps/pep-0484/ > >I would like to request that arbitrary function annotations are not >deprecated for three reasons: >1. Backwards Compatibility >2. Type Experimentation >3. Embedded Languages > >1. Backwards Compatibility >After reading Pep 3107 my team has made significant use of non-standard >annotations. It would be a serious burden to be forced to port our >annotations back to decorators. This would also make our codebase >considerably less readable because function annotations are much more >readable than input/output annotations relegated to decorators. >https://www.python.org/dev/peps/pep-3107/ > >2. Type Experimentation >Arbitrary function annotations allow developers to experiment with >potential type system improvements in real projects. Ideas can be >validated >before officially adding them to the language. This seems like an >advantage >that should be preserved. After all, Pep 484 says it was strongly >inspired >by MyPy, an existing project. >http://mypy-lang.org/ > >3. Embedded Languages >Python's flexibility makes it an amazing language to embed other >languages >in. In this regard, Python 3's addition of arbitrary function >annotations >and class decorators complements Python 2's dynamic typing, function >decorators, reflection, metaclasses, properties, magic methods, >generators, >and keyword arguments. Arbitrary function annotations are a crucial >part of >this toolkit, and this feature is not available in most other >languages. >For anyone interested in the utility and mechanics of embedded >languages, >I'd recommend Martin Fowler's book: Domain Specific Languages. >http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-Series/dp/0321712943 > >So I agree with the course of action mentioned in Pep 484 that avoids >runtime deprecation of arbitrary function annotation: "Another possible >outcome would be that type hints will eventually become the default >meaning >for annotations, but that there will always remain an option to disable >them." I would only add that there should be a way to disable type >checking >for an entire directory (recursively). This would be useful for >codebases >that have not been ported to standard annotations yet, and for >codebases >that will not be ported for the reasons listed above. > >Thanks for your consideration. > >Best, >Steve > > > > >___ >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 -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ___ 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] Not Deprecating Arbitrary Function Annotations
PSF. Nothing personal, of course... On October 5, 2015 3:01:11 PM CDT, Guido van Rossum wrote: >"They"? > >On Mon, Oct 5, 2015 at 12:57 PM, Ryan Gonzalez >wrote: > >> There is one reason I would be really freaking mad if they deprecated >> other uses of annotations: >> >> https://pypi.python.org/pypi/plac >> >> On October 5, 2015 1:55:37 PM CDT, Steve Wedig >> wrote: >> >Congratulations on the release of 3.5 and Pep 484. I've used Python >> >professionally for 10 years and I believe type hints will make it >> >easier to >> >work with large codebases evolving over time. My only concern about >Pep >> >484 >> >is the discussion of whether or not to deprecate arbitrary function >> >annotations. >> >https://www.python.org/dev/peps/pep-0484/ >> > >> >I would like to request that arbitrary function annotations are not >> >deprecated for three reasons: >> >1. Backwards Compatibility >> >2. Type Experimentation >> >3. Embedded Languages >> > >> >1. Backwards Compatibility >> >After reading Pep 3107 my team has made significant use of >non-standard >> >annotations. It would be a serious burden to be forced to port our >> >annotations back to decorators. This would also make our codebase >> >considerably less readable because function annotations are much >more >> >readable than input/output annotations relegated to decorators. >> >https://www.python.org/dev/peps/pep-3107/ >> > >> >2. Type Experimentation >> >Arbitrary function annotations allow developers to experiment with >> >potential type system improvements in real projects. Ideas can be >> >validated >> >before officially adding them to the language. This seems like an >> >advantage >> >that should be preserved. After all, Pep 484 says it was strongly >> >inspired >> >by MyPy, an existing project. >> >http://mypy-lang.org/ >> > >> >3. Embedded Languages >> >Python's flexibility makes it an amazing language to embed other >> >languages >> >in. In this regard, Python 3's addition of arbitrary function >> >annotations >> >and class decorators complements Python 2's dynamic typing, function >> >decorators, reflection, metaclasses, properties, magic methods, >> >generators, >> >and keyword arguments. Arbitrary function annotations are a crucial >> >part of >> >this toolkit, and this feature is not available in most other >> >languages. >> >For anyone interested in the utility and mechanics of embedded >> >languages, >> >I'd recommend Martin Fowler's book: Domain Specific Languages. >> > >> >http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-Series/dp/0321712943 >> > >> >So I agree with the course of action mentioned in Pep 484 that >avoids >> >runtime deprecation of arbitrary function annotation: "Another >possible >> >outcome would be that type hints will eventually become the default >> >meaning >> >for annotations, but that there will always remain an option to >disable >> >them." I would only add that there should be a way to disable type >> >checking >> >for an entire directory (recursively). This would be useful for >> >codebases >> >that have not been ported to standard annotations yet, and for >> >codebases >> >that will not be ported for the reasons listed above. >> > >> >Thanks for your consideration. >> > >> >Best, >> >Steve >> > >> > >> >> >> > >> >___ >> >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 >> >> -- >> Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. >> ___ >> 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) -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___ 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] Not Deprecating Arbitrary Function Annotations
Uh, I kind of knew that. Then I rushed the email and my brain momentarily left me. Sorry... On October 5, 2015 3:23:29 PM CDT, Guido van Rossum wrote: >Maybe I should clarify how the process of changing the language works. > >The PSF doesn't enter into it -- they manage the infrastructure (e.g. >mailing lists, Hg repo, tracker, python.org) but they don't have >anything >to do with deciding how or when the language changes. > >Language changes are done *here* by *us* all. Anyone can write a PEP >and it >will be discussed here (but first in python-ideas of course). > >I'm sorry you don't feel more included, but I really don't like the >idea of >"us vs. them" in this list. We're all working together to make Python >the >best language it can be. > >--Guido > >On Mon, Oct 5, 2015 at 1:18 PM, Ryan Gonzalez wrote: > >> PSF. Nothing personal, of course... >> >> >> On October 5, 2015 3:01:11 PM CDT, Guido van Rossum > >> wrote: >>> >>> "They"? >>> >>> On Mon, Oct 5, 2015 at 12:57 PM, Ryan Gonzalez >wrote: >>> >>>> There is one reason I would be really freaking mad if they >deprecated >>>> other uses of annotations: >>>> >>>> https://pypi.python.org/pypi/plac >>>> >>>> On October 5, 2015 1:55:37 PM CDT, Steve Wedig > >>>> wrote: >>>> >Congratulations on the release of 3.5 and Pep 484. I've used >Python >>>> >professionally for 10 years and I believe type hints will make it >>>> >easier to >>>> >work with large codebases evolving over time. My only concern >about Pep >>>> >484 >>>> >is the discussion of whether or not to deprecate arbitrary >function >>>> >annotations. >>>> >https://www.python.org/dev/peps/pep-0484/ >>>> > >>>> >I would like to request that arbitrary function annotations are >not >>>> >deprecated for three reasons: >>>> >1. Backwards Compatibility >>>> >2. Type Experimentation >>>> >3. Embedded Languages >>>> > >>>> >1. Backwards Compatibility >>>> >After reading Pep 3107 my team has made significant use of >non-standard >>>> >annotations. It would be a serious burden to be forced to port our >>>> >annotations back to decorators. This would also make our codebase >>>> >considerably less readable because function annotations are much >more >>>> >readable than input/output annotations relegated to decorators. >>>> >https://www.python.org/dev/peps/pep-3107/ >>>> > >>>> >2. Type Experimentation >>>> >Arbitrary function annotations allow developers to experiment with >>>> >potential type system improvements in real projects. Ideas can be >>>> >validated >>>> >before officially adding them to the language. This seems like an >>>> >advantage >>>> >that should be preserved. After all, Pep 484 says it was strongly >>>> >inspired >>>> >by MyPy, an existing project. >>>> >http://mypy-lang.org/ >>>> > >>>> >3. Embedded Languages >>>> >Python's flexibility makes it an amazing language to embed other >>>> >languages >>>> >in. In this regard, Python 3's addition of arbitrary function >>>> >annotations >>>> >and class decorators complements Python 2's dynamic typing, >function >>>> >decorators, reflection, metaclasses, properties, magic methods, >>>> >generators, >>>> >and keyword arguments. Arbitrary function annotations are a >crucial >>>> >part of >>>> >this toolkit, and this feature is not available in most other >>>> >languages. >>>> >For anyone interested in the utility and mechanics of embedded >>>> >languages, >>>> >I'd recommend Martin Fowler's book: Domain Specific Languages. >>>> > >>>> >http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-Series/dp/0321712943 >>>> > >>>> >So I agree with the course of action mentioned in Pep 484 that >avoids >>>> >runtime deprecation of arbitrary function annotation: "Another >possible >>>> >outcome would be that type hints will eventually become the >default >>>>
[Python-Dev] Should PEP 498 specify if rf'...' is valid?
It mentions fr'...' as a formatted raw string but doesn't say anything about rf'...'. Right now, in implementing PEP 498 support in Howl (https://github.com/howl-editor/howl/pull/118 and https://github.com/howl-editor/howl/commit/1e577da89efc1c1de780634b531f64346cf586d6#diff-851d9b84896270cc7e3bbea3014007a5R86), I assumed both were valid. Should the PEP be more specific? BTW, at the rate language-python is going, GitHub will get syntax highlighting for f-strings in 2050. :D -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___ 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] Should PEP 498 specify if rf'...' is valid?
Ah, I missed that part. Sorry! :/ On October 22, 2015 7:27:41 AM CDT, "Eric V. Smith" wrote: >On 10/22/2015 7:32 AM, Eric V. Smith wrote: >> On 10/21/2015 10:57 PM, Ryan Gonzalez wrote: >>> It mentions fr'...' as a formatted raw string but doesn't say >anything >>> about rf'...'. Right now, in implementing PEP 498 support in Howl >>> (https://github.com/howl-editor/howl/pull/118 and >>> >https://github.com/howl-editor/howl/commit/1e577da89efc1c1de780634b531f64346cf586d6#diff-851d9b84896270cc7e3bbea3014007a5R86), >>> I assumed both were valid. Should the PEP be more specific? >> >> Yes, I'll add some wording. > >Now that I check, in the Specification section, the PEP already says >"'f' may be combined with 'r', in either order, to produce raw f-string >literals". So I think this case is covered, no? > >Eric. -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___ 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] Should PEP 498 specify if rf'...' is valid?
On October 22, 2015 11:10:48 AM CDT, "Sven R. Kunze" wrote: >On 22.10.2015 13:32, Eric V. Smith wrote: >> ['B', 'BF', 'BFR', 'BFr', 'BR', 'BRF', 'BRf', 'Bf', 'BfR', 'Bfr', >'Br', >> 'BrF', 'Brf', 'F', 'FB', 'FBR', 'FBr', 'FR', 'FRB', 'FRb', 'Fb', >'FbR', >> 'Fbr', 'Fr', 'FrB', 'Frb', 'R', 'RB', 'RBF', 'RBf', 'RF', 'RFB', >'RFb', >> 'Rb', 'RbF', 'Rbf', 'Rf', 'RfB', 'Rfb', 'U', 'b', 'bF', 'bFR', 'bFr', >> 'bR', 'bRF', 'bRf', 'bf', 'bfR', 'bfr', 'br', 'brF', 'brf', 'f', >'fB', >> 'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fb', 'fbR', 'fbr', 'fr', 'frB', >> 'frb', 'r', 'rB', 'rBF', 'rBf', 'rF', 'rFB', 'rFb', 'rb', 'rbF', >'rbf', >> 'rf', 'rfB', 'rfb', 'u'] >> >> I think the upper/lower ones are nuts, but it's probably too late to >do >> anything about it. 'FbR', really? > >Why not disallowing them? > >I for one could live with all-lower-case AND a predefined order. > Well, now it's backwards-compatibility. >Best, >Sven >___ >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 -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ___ 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] Should PEP 498 specify if rf'...' is valid?
But it'd be weird now if fR worked but fbR didn't. On Thu, Oct 22, 2015 at 12:02 PM, Sven R. Kunze wrote: > On 22.10.2015 18:17, Ryan Gonzalez wrote: > >> >>> anything about it. 'FbR', really? >>>> >>> Why not disallowing them? >>> >>> I for one could live with all-lower-case AND a predefined order. >>> >>> Well, now it's backwards-compatibility. >> > > Huh? There are no fb strings yet. > > Best, > Sven > -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. 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] If you shadow a module in the standard library that IDLE depends on, bad things happen
Why not just check the path of the imported modules and compare it with the Python library directory? On October 29, 2015 3:26:08 PM CDT, Mark Roseman wrote: >Laura, I think what you want should actually be more-or-less doable in >IDLE. > >The main routine that starts IDLE should be able to detect if it starts >correctly (something unlikely to happen if a significant stdlib module >is shadowed), watch for an attribute error of that form and try to >determine if shadowing is the cause, and if so, reissue a saner error >message. > >The subprocess/firewall error is occurring because the ‘string’ problem >in your example isn’t being hit right away so a few startup things >already are happening. The point where we’re showing that error (as a >result of a timeout) should be able to check as per the above that IDLE >was able to start alright, and if not, change or ignore the timeout >error. > >There’ll probably be some cases (depending on exactly what gets >shadowed) that may be difficult to get to work, but it should be able >to handle most things. > >Mark > >___ >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 -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___ 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] If you shadow a module in the standard library that IDLE depends on, bad things happen
Well, tell your friend that that means middle and high schoolers must think alike! :D On Thu, Oct 29, 2015 at 4:18 PM, Laura Creighton wrote: > In a message of Thu, 29 Oct 2015 15:50:30 -0500, Ryan Gonzalez writes: > >Why not just check the path of the imported modules and compare it with > the Python library directory? > > My friend Åsa who is 12 years old suggested exactly this at the club. If > this > works then I will be certain to mention this to her. I said that I would > ask 'how hard is this?' > > Laura > -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. 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] If you shadow a module in the standard library that IDLE depends on, bad things happen
Well, this works on Python 2 only (I'm on a phone with only access to 2 right
now), but this is a start (apologies for the screwy syntax highlighting):
import sys, imp, logging, os
modules = '''
imp
string
...
'''.split()
class StdlibTester(object):
base = os.path.dirname(os.__file__) # hack; is there a better way to do
this?
def find_module(self, fullname, path=None):
if fullname in modules:
self.path = path
return self
return None
def load_module(self, name):
if name in sys.modules:
return sys.modules[name]
module_info = imp.find_module(name, self.path)
module = imp.load_module(name, *module_info)
sys.modules[name] = module
if hasattr(module, '__file__') and not
os.path.dirname(module.__file__).startswith(self.base):
logging.warning('stdlib module %s was overriden', name)
return module
sys.meta_path.append(StdlibTester())
import string
On October 29, 2015 7:06:51 PM CDT, "R. David Murray"
wrote:
>On Thu, 29 Oct 2015 16:56:38 -0700, Nathaniel Smith
>wrote:
>> On Thu, Oct 29, 2015 at 1:50 PM, Ryan Gonzalez
>wrote:
>> > Why not just check the path of the imported modules and compare it
>with the
>> > Python library directory?
>>
>> It works, but it requires that everyone who could run into this
>> problem carefully add some extra guard code to every stdlib import
>> statement, and in practice nobody will (or at least, not until after
>> they've already gotten bitten by this at least once... at which point
>> they no longer need it).
>>
>> Given that AFAICT there's no reason this couldn't be part of the
>> default import system's functionality and "just work" for everyone,
>if
>> I were going to spend time on trying to fix this I'd probably target
>> that :-).
>>
>> (I guess the trickiest bit would be to find an efficient and
>> maintainable way to check whether a given package name is present in
>> the stdlib.)
>
>For Idle, though, it sounds like a very viable strategy, and that's
>what Laura is concerned about.
>
>--David
>___
>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
--
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
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] 2.7.11 plans
On Sun, Nov 1, 2015 at 4:42 PM, Benjamin Peterson wrote: > Happy November, everyone. It’s nearly time for the next semi-annual > instalment of the 2.7 series. I’m planning to release a 2.7.11 release > candidate on November 21st and 2.7.11 final on December 5. > > More than half-done releasing 2.7-ly yours, > This made me laugh! > Benjamin > ___ > 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 [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. 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] modernizing IDLE
On Tue, Nov 10, 2015 at 5:02 PM, Michiel Overtoom wrote: > > > On 06 Nov 2015, at 18:08, Mark Roseman wrote: > > > > (There’s also currently a post on Hacker News about this). > > You have a link for that HN item? I've looked at the first five pages but > couldn't find it. > > https://news.ycombinator.com/item?id=10519785 I used the big "Search" box at the bottom of the main Hacker News page. ;) > Greetings, > > ___ > 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 [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. 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] Reading Python source file
Well, not quite the same thing, but https://github.com/kirbyfan64/pfbuild/blob/master/pfbuild embeds the compressed version of 16k LOC. Would it be affected negatively in any way be this? Since all the data is on one line, I'd think the old (current) parser would end up reading in the whole line anyway. On November 18, 2015 9:48:41 AM CST, Guido van Rossum wrote: >On Wed, Nov 18, 2015 at 4:15 AM, Hrvoje Niksic >wrote: >> On 11/18/2015 03:31 AM, Nick Coghlan wrote: >>> >>> That behaviour is then inherited at the command line by both the -m >>> switch and the support for executing directories and zip archives. >>> When we consider that the "-c" switch also executes an in-memory >>> string, direct script execution is currently the odd one out in >*not* >>> reading the entire source file into memory first, so Serhiy's >proposed >>> simplification of the implementation makes sense to me. >> >> >> Reading the whole script in memory will incur an overhead when >executing >> scripts that contain (potentially large) data embedded after the end >of >> script source. >> >> The technique of reading data from sys.argv[0] is probably obsolete >now that >> Python supports executing zipped archives, but it is popular in shell >> scripting and might still be used for self-extracting scripts that >must >> support older Python versions. This feature doesn't affect imports >and -c >> which are not expected to contain non-Python data. > >That trick doesn't work unless the data looks like Python comments or >data (e.g. a docstring). Python has always insisted on being able to >parse until EOF. The only extreme case would be a small script >followed by e.g. 4 GB of comments (where the old parser would indeed >be more efficient). But unless you can point me to an occurrence of >this in the wild I'm going to speculate that you just made this up >based on the shell analogy (which isn't perfect). > >-- >--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 -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___ 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] "python.exe is not a valid Win32 app"
Did you get the x86-64 version or x86? If you had gotten the former, it would lead to that error. On December 1, 2015 8:30:25 AM CST, Alexei Belenki via Python-Dev wrote: >Installed python 3.5 (from https://www.python.org/downloads/) on >Windows XPsp3/32 >On starting >>python.exe got the text above in the Windows message box. >Any suggestions?Thanks.AB > > > >___ >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 -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___ 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] Python Language Reference has no mention of list comÃprehensions
On December 3, 2015 8:26:23 AM CST, Laura Creighton wrote: >In a message of Thu, 03 Dec 2015 13:37:17 +, Paul Moore writes: >>On 3 December 2015 at 12:51, Laura Creighton wrote: >>> Intentional or Oversight? >> >>Hard to find :-) >> >>https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries >> >>I went via "Atoms" in the expression section, then followed the links >>in the actual grammar spec. >> >>Paul > >I think the whole use of the language displays as in > > 6.2.4. Displays for lists, sets and dictionaries > > For constructing a list, a set or a dictionary Python provides > special syntax called “displays”, each of them in two flavors: > >either the container contents are listed explicitly, or >they are computed via a set of looping and filtering instructions, >called a comprehension. > >is very odd. I don't know anybody who talks of 'displays'. They >talk of 'two ways to construct a'. > >Who came up with the word 'display' and what does it have going for >it that I have missed? Right now I think its chief virtue is that >it is a meaningless noun. (But not meaningless enough, as I >associate displays with output, not construction). > >I think that > >6.2.4 Constructing lists, sets and dictionaries > >would be a much more useful title, and > >6.2.4 Constructing lists, sets and dictionaries -- explicitly or >through the use of comprehensions > What about: 6.2.4 Constricting lists, sets, and dictionaries (including comprehensions) or something to that effect? >an even better one. > >Am I missing something important about the 'display' language? > >Laura >___ >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 -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ___ 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] Python Language Reference has no mention of list comÃprehensions
On December 3, 2015 10:09:56 AM CST, Ryan Gonzalez wrote: > > >On December 3, 2015 8:26:23 AM CST, Laura Creighton >wrote: >>In a message of Thu, 03 Dec 2015 13:37:17 +, Paul Moore writes: >>>On 3 December 2015 at 12:51, Laura Creighton wrote: >>>> Intentional or Oversight? >>> >>>Hard to find :-) >>> >>>https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries >>> >>>I went via "Atoms" in the expression section, then followed the links >>>in the actual grammar spec. >>> >>>Paul >> >>I think the whole use of the language displays as in >> >> 6.2.4. Displays for lists, sets and dictionaries >> >> For constructing a list, a set or a dictionary Python provides >> special syntax called âdisplaysâ, each of them in two flavors: >> >>either the container contents are listed explicitly, or >>they are computed via a set of looping and filtering instructions, > >>called a comprehension. >> >>is very odd. I don't know anybody who talks of 'displays'. They >>talk of 'two ways to construct a'. >> >>Who came up with the word 'display' and what does it have going for >>it that I have missed? Right now I think its chief virtue is that >>it is a meaningless noun. (But not meaningless enough, as I >>associate displays with output, not construction). >> >>I think that >> >>6.2.4 Constructing lists, sets and dictionaries >> >>would be a much more useful title, and >> >>6.2.4 Constructing lists, sets and dictionaries -- explicitly or >>through the use of comprehensions >> > >What about: > >6.2.4 Constricting lists, sets, and dictionaries (including >comprehensions) > Whoops! I meant "Constructing", not "Constricting". Pythons definitely constrict their prey, but that's not what I was referring to... >or something to that effect? > >>an even better one. >> >>Am I missing something important about the 'display' language? >> >>Laura >>___ >>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 -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ___ 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
