[issue46909] Update getpath.py to look for os.pyc in __pycache__ folders

Steve Dower added the comment: It's looking for a precompiled bundled stdlib, rather than one that's been generated from adjacent source files. This is deliberate (also quite an advanced scenario, but it does get used). -- components: -Documentation resolution: -> not a bug stage:

[issue46909] Update getpath.py to look for os.pyc in __pycache__ folders

New submission from Russel Webber : The STDLIB_LANDMARKS in Modules/getpath,py refers to os.pyc in an old location: STDLIB_LANDMARKS = [f'{STDLIB_SUBDIR}/os.py', f'{STDLIB_SUBDIR}/os.pyc'] Since https://www.python.org/dev/peps/pep-3147 the .pyc files are in __pycache__ folders

[issue41081] Exclude __pycache__ directories from backups using CACHEDIR.TAG

Eric V. Smith added the comment: To spoil it for other readers: the linked page says to create a file named CACHEDIR.TAG with a specific first line. -- nosy: +eric.smith ___ Python tracker

[issue41081] Exclude __pycache__ directories from backups using CACHEDIR.TAG

Change by Jakub Stasiak : -- keywords: +patch pull_requests: +20231 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21060 ___ Python tracker ___

[issue41081] Exclude __pycache__ directories from backups using CACHEDIR.TAG

New submission from Jakub Stasiak : It'd be nice of __pycache__ directories didn't pollute backups. Granted, one can add __pycache__ directory to their backup-tool-of-choice exclusion list, but those lists are ever growing and maybe it'd be good to help the tools and the users. There's

[issue38257] __pycache__ directory with World writable permission

basis the permission of the __pycache__ directory has been decided. Thanks in advance. -- messages: 353009 nosy: SivaKumar NSK priority: normal severity: normal status: open title: __pycache__ directory with World writable permission versions: Python 3.7

Re: __pycache__

On Wed, Feb 4, 2015 at 1:34 AM, Emile van Sebille em...@fenx.com wrote: On 2/3/2015 6:21 AM, Dennis Lee Bieber wrote: The second is to use Google... https://www.google.com/?gws_rd=ssl#q=python+idle+can%27t+make+connection but the first page of results isn't helping -- lots of

Re: __pycache__

On 2/3/2015 6:21 AM, Dennis Lee Bieber wrote: The second is to use Google... https://www.google.com/?gws_rd=ssl#q=python+idle+can%27t+make+connection but the first page of results isn't helping -- lots of reports of the problem, but no firm remedy listed. it was suggested to me

__pycache__

I am in school and there is a problem with my code: When I try to run my code in the python code in the python shell it waits about 10 seconds then shows an error that says “IDLE’s subprocess didn’t make connection. Either IDLE can’t start a subprocess or personal firewall software is blocking

Re: __pycache__

On 2/2/2015 6:26 PM, Luke Lloyd wrote: I am in school and there is a problem with my code: When I try to run my code in the python code in the python shell it waits about 10 seconds then shows an error that says “IDLE’s subprocess didn’t make connection. Either IDLE can’t start a subprocess or

Re: __pycache__

On Tue, Feb 3, 2015 at 10:31 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: I know that you can target sites, but can you exclude them, e.g. -site:stackoverflow.com ? Yes, you can. Compare the results of these two searches, for example: git initial push git initial push

Re: __pycache__

On 03/02/2015 14:34, Emile van Sebille wrote: On 2/3/2015 6:21 AM, Dennis Lee Bieber wrote: The second is to use Google... https://www.google.com/?gws_rd=ssl#q=python+idle+can%27t+make+connection but the first page of results isn't helping -- lots of reports of the problem, but no firm

Re: __pycache__

On 2/3/2015 8:31 AM, Mark Lawrence wrote: On 03/02/2015 14:34, Emile van Sebille wrote: On 2/3/2015 6:21 AM, Dennis Lee Bieber wrote: The second is to use Google... https://www.google.com/?gws_rd=ssl#q=python+idle+can%27t+make+connection but the first page of results isn't helping --

Re: __pycache__

On Mon, Feb 2, 2015 at 4:26 PM, Luke Lloyd nieko...@gmail.com wrote: I am in school and there is a problem with my code: When I try to run my code in the python code in the python shell it waits about 10 seconds then shows an error that says “IDLE’s subprocess didn’t make connection. Either

Re: __pycache__

On Mon, Feb 2, 2015 at 4:26 PM, Luke Lloyd nieko...@gmail.com wrote: I am in school and there is a problem with my code: When I try to run my code in the python code in the python shell it waits about 10 seconds then shows an error that says “IDLE’s subprocess didn’t make connection. Either

[issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__

Vjacheslav Fyodorov added the comment: Now in 3.4 Fedora 21 -- nosy: +Vjacheslav.Fyodorov versions: +Python 3.4 -3rd party, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13307

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Brett Cannon added the comment: Apparently this broke under Windows: http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8999/steps/test/logs/stdio -- status: closed - open ___ Python tracker rep...@bugs.python.org

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Barry A. Warsaw added the comment: I already pushed a fix. http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.4/builds/702/steps/test/logs/stdio (although asyncio is still failing there but that should be unrelated) -- status: open - closed

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Matthias Klose added the comment: seen as well with 3.3 -- keywords: +3.3regression, 3.4regression nosy: +doko ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Matthias Klose added the comment: proposed patch: diff -r 8dacb1a21793 Lib/importlib/_bootstrap.py --- a/Lib/importlib/_bootstrap.py Fri Nov 28 13:15:41 2014 +0100 +++ b/Lib/importlib/_bootstrap.py Mon Dec 01 17:05:00 2014 +0100 @@ -453,7 +453,7 @@ else: suffixes =

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Barry A. Warsaw added the comment: I'll take this one. I think it should be easy to add a test case, which I'll do. -- assignee: - barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Changes by Barry A. Warsaw ba...@python.org: -- versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___ ___ Python-bugs-list

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Barry A. Warsaw added the comment: Not counting importlib.h, here's the diff I'm going to apply to 3.4. It passes all the existing tests and includes a new test for this behavior. -- Added file: http://bugs.python.org/file37339/22966.txt ___ Python

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Roundup Robot added the comment: New changeset 269bf37a57a1 by Barry Warsaw in branch '3.4': - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is https://hg.python.org/cpython/rev/269bf37a57a1 New changeset 3b3ba38d503a by Barry Warsaw in branch '3.4': - Issue #22966: Fix

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Changes by Barry A. Warsaw ba...@python.org: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Changes by Berker Peksag berker.pek...@gmail.com: -- stage: patch review - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___ ___

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

R. David Murray added the comment: And, therefore, a missing test :(. This probably snuck in when we refactored the CLI. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

foo.bar.py $ ls __pycache__ foo.cpython-34.pyc Even though foo.bar.py is not a valid file name, some programmers are using such names for plugins which leads to bugs similar to https://lists.debian.org/debian-python/2014/11/msg00061.html. I will update my scripts to not feed py_compile module

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Changes by Brett Cannon br...@python.org: -- components: +Library (Lib) stage: - test needed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Changes by Brett Cannon br...@python.org: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___ ___ Python-bugs-list

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___ ___ Python-bugs-list mailing

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Piotr Ożarowski added the comment: Python 3.2 generates foo.bar.cpython-32.pyc so it's a regression -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Éric Araujo mer...@netwok.org added the comment: See also #13123 for the same bug in bdist_wininst. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11254 ___

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset c10946a17420 by Éric Araujo in branch 'default': Clean up byte-compilation code in packaging (#11254 followup). http://hg.python.org/cpython/rev/c10946a17420 -- ___

[issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__

Éric Araujo mer...@netwok.org added the comment: I wrote the same fix this night :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13307 ___ ___

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset ea926dff958f by Éric Araujo in branch '3.2': More fixes for PEP 3147 compliance in distutils (#11254) http://hg.python.org/cpython/rev/ea926dff958f New changeset 60ede940089f by Éric Araujo in branch 'default':

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Changes by Éric Araujo mer...@netwok.org: -- resolution: - fixed stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11254 ___

[issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__

have expanded one test and successfully reproduced the bug; next I will fix the code. -- assignee: - eric.araujo components: +Distutils, Distutils2 nosy: +alexis title: test_bdist_rpm: INSTALLED_FILES does not use __pycache__ - bdist_rpm: INSTALLED_FILES does not use __pycache__ versions

[issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__

Changes by Éric Araujo mer...@netwok.org: -- dependencies: +distutils doesn't byte-compile .py files to __pycache__ during installation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13307

[issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__

Antoine Pitrou pit...@free.fr added the comment: Should be fixed now (verified here on Mageia). -- dependencies: -distutils doesn't byte-compile .py files to __pycache__ during installation nosy: +pitrou resolution: - fixed stage: - committed/rejected status: open - closed

[issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 2c0253d4d9ba by Antoine Pitrou in branch '3.2': Issue #13307: fix bdist_rpm test failures http://hg.python.org/cpython/rev/2c0253d4d9ba New changeset eb2991f7cdc8 by Antoine Pitrou in branch 'default': Issue #13307:

[issue13307] test_bdist_rpm: INSTALLED_FILES does not use __pycache__

New submission from Stefan Krah stefan-use...@bytereef.org: The failures seen on the Fedora buildbot are caused by the fact that INSTALLED_FILES does not use __pycache__: [stefan@fedora-14-i386 foo]$ cat build/bdist.linux-i686/rpm/BUILD/foo-0.1/INSTALLED_FILES /usr/local/lib/python3.3/site

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 1cc4d822123b by Éric Araujo in branch 'default': More fixes for PEP 3147 compliance in packaging (#11254) http://hg.python.org/cpython/rev/1cc4d822123b -- ___ Python

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Éric Araujo mer...@netwok.org added the comment: Installation was not completely fixed. Distutils delegates to each command’s get_outputs method to make the list of all files to install or package in an sdist, and the previous patch missed edits to these get_outputs methods. I should have

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 27a36b05caed by Éric Araujo in branch '3.2': Fix distutils byte-compilation to comply with PEP 3147 (#11254). http://hg.python.org/cpython/rev/27a36b05caed New changeset 651e84363001 by Éric Araujo in branch '3.2':

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Éric Araujo mer...@netwok.org added the comment: Finally fixed. I fail at boolean logic; removing the “dance around imp.cache_from_source that seemed unnecessary” as I called it was a mistake, we have to do it, so I restored that part of your original patch. I’m sorry I took so long to fix

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Éric Araujo mer...@netwok.org added the comment: I will commit this today or tomorrow. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11254 ___

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

python3-* rpm packages (as generated by distutils). rpm's post-processing has been generating .pyc files in the (correct) __pycache__ location (via rpmbuild's brp-python-bytecompile script, which uses compileall). For examples, see that Fedora bug report; so far it's affected every built rpm

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Tarek Ziadé ziade.ta...@gmail.com added the comment: to be backported in packaging -- in a way that will make it work with previous python versions for the incoming 2.x backport -- ___ Python tracker rep...@bugs.python.org

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Ned Deily n...@acm.org added the comment: Should this be a release blocker for 3.2.1? -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11254 ___

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Jeff Ramnani j...@jefframnani.com added the comment: I've reviewed your patch and it looks good. I appreciate the review and cleanup. The tests succeed for me after applying your patch. I also tested with PYTHONOPTIMIZE and PYTHONDONTWRITEBYTECODE and got the output I expected. --

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Éric Araujo mer...@netwok.org added the comment: The dance around imp.cache_from_source looks necessary, judging by Georg’s http://hg.python.org/cpython/rev/713c6b6ca5ce/#l8.53 -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Éric Araujo mer...@netwok.org added the comment: I cleaned up the patch a bit. In particular, I removed the dance around imp.cache_from_source that seemed unnecessary. I tested with regular Python, with PYTHONOPTIMIZE and with PYTHONDONTWRITEBYTECODE. Can you review and test too?

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Éric Araujo mer...@netwok.org added the comment: Thanks for the test. The patch is minimal and makes distutils work correctly with the new pyc handling in 3.2+, so I will apply it in a few days unless Tarek disagrees. -- assignee: tarek - eric.araujo stage: patch review - commit

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

not looking in the __pycache__ directory for byte-compiled or optimized files. Attaching an updated patch that fixes the unit tests that were breaking. -- nosy: +jramnani Added file: http://bugs.python.org/file21146/issue11254.patch ___ Python tracker rep

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

New submission from Stefan Behnel sco...@users.sourceforge.net: During installation of Python packages (setup.py install or bdist), distutils puts .pyc files into the installed source directory, instead of moving them into __pycache__. This may mean that they are not getting used after

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Stefan Behnel sco...@users.sourceforge.net added the comment: Here's a patch. I basically copied over the way py_compile determines the .pyc file name. It works for me for a normal installation. However, I couldn't test it with -O, as 2to3 crashes for me when I enable it during installation.

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Éric Araujo mer...@netwok.org added the comment: Patch looks good. Regarding the problem with 2to3 and -O, maybe you can run 2to3 manually, copy the setup.py and run python3.2 -0. disutils.util.byte_compile is not tested, so this patch requires at least careful manual testing, and if

[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation

Changes by Antoine Pitrou pit...@free.fr: -- priority: normal - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11254 ___ ___

[issue11154] Alternate name for __pycache__

Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11154 ___ ___ Python-bugs-list

[issue11154] Alternate name for __pycache__

Barry A. Warsaw ba...@python.org added the comment: Hmm. That's problematic. How would that interact with a system Python that is already looking in __pycache__ for its pyc files? Would it suddenly start ignoring those and wanting to write them to .pycache? IIRC we thought about something

[issue11154] Alternate name for __pycache__

Changes by Georg Brandl ge...@python.org: -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11154 ___ ___ Python-bugs-list

[issue11154] Alternate name for __pycache__

Dave Malcolm dmalc...@redhat.com added the comment: On Wed, 2011-02-09 at 16:41 +, Barry A. Warsaw wrote: IIRC we thought about something like this during the PEP discussions and Guido nixed it. FWIW, the closest I could find was this mail:

[issue11154] Alternate name for __pycache__

Antoine Pitrou pit...@free.fr added the comment: I agree with barry's argument and also with Marc-André's argument on python-ideas. Your directories are far cleaner than before with pyc files all around, so what is the problem exactly? -- nosy: +pitrou

[issue11154] Alternate name for __pycache__

Raymond Hettinger rhettin...@users.sourceforge.net added the comment: That makes sense. Making it configurable would lose some of the benefits. What we could do though, before 3.2 goes out, is change the name to .pycache to follow the dot-file naming convention and avoid cluttering directory

[issue11154] Alternate name for __pycache__

Raymond Hettinger rhettin...@users.sourceforge.net added the comment: I just saw a post from Guido saying that he doesn't want the directory to be invisible. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org

[issue11154] Alternate name for __pycache__

New submission from Raymond Hettinger rhettin...@users.sourceforge.net: It would be great if the __pycache__ name could be set by an environment variable. I would like to rename it to .pycache so that it doesn't pollute my directory listings. -- assignee: barry messages: 128194 nosy

Re: __pycache__, one more good reason to stck with Python 2?

On Wed, 19 Jan 2011 14:31:15 -0800, Alice Bevan–McGregor wrote: On 2011-01-19 13:01:04 -0800, Steven D'Aprano said: I know I've seen problems executing .pyc files from the shell in the past... perhaps I was conflating details of something else. Ah, I know! [steve@sylar ~]$ chmod u+x

Re: __pycache__, one more good reason to stck with Python 2?

Hi You have disturbe my slumber, Steven ;-) On Jan 19, 2:42 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Tue, 18 Jan 2011 00:58:14 -0800, jmfauth wrote: It is now practically impossible to launch a Python application via a .pyc file. When has that ever been

Re: __pycache__, one more good reason to stck with Python 2?

On Thu, 20 Jan 2011 05:09:50 -0800, John Pinner wrote: Hi You have disturbe my slumber, Steven ;-) On Jan 19, 2:42 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Tue, 18 Jan 2011 00:58:14 -0800, jmfauth wrote: It is now practically impossible to launch a Python

Re: __pycache__, one more good reason to stck with Python 2?

I know I've seen problems executing .pyc files from the shell in the past... perhaps I was conflating details of something else. Ah, I know! [steve@sylar ~]$ chmod u+x toto.pyc [steve@sylar ~]$ ./toto.pyc : command not found �� ./toto.pyc: line 2: syntax error near unexpected token `('

Re: __pycache__, one more good reason to stck with Python 2?

But you got me thinking... how far back does this behaviour go? = == Release 1.1 (11 Oct 1994) == = - Passing the interpreter a .pyc file as script argument will execute the code in that file. (On the Mac such files can be

Re: __pycache__, one more good reason to stck with Python 2?

On Jan 18, 4:04 am, Peter Otten __pete...@web.de wrote: What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'? Portability. Running the '-exec' version will work fine in a directory with a relatively small number of files, but will fail on a large one. 'xargs', which is

Re: __pycache__, one more good reason to stck with Python 2?

, to sanitize the bred-crumbs and data trails applications leave, and so forth. But having said that, the __pycache__ idea isn't too bad. If you have this directory structure: ./module.py ./module.pyc and import module, the top-level .pyc file will continue to be used. If you delete module.py

Re: __pycache__, one more good reason to stck with Python 2?

toto.py $ __svn__/python __pycache__/toto.cpython-32.pyc 3.2rc1+ (py3k:88095M, Jan 18 2011, 17:12:15) [GCC 4.4.3] Regards Antoine. -- http://mail.python.org/mailman/listinfo/python-list

Re: __pycache__, one more good reason to stck with Python 2?

My nightmare was mainly due, because when I read the the What's new?, I did not understand too much this caching stuff. It's only later, after testing some applications, I really got the surprise to understand it. (Py3.1 and Py3.2 pyc's mixture). Having said this, to tell you the truth. I do

Re: __pycache__, one more good reason to stck with Python 2?

H₂0.py okop...@gmail.com writes: On Jan 18, 4:04 am, Peter Otten __pete...@web.de wrote: What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'? Portability. Running the '-exec' version will work fine in a directory with a relatively small number of files, but will fail on

Re: __pycache__, one more good reason to stck with Python 2?

On Wed, 19 Jan 2011 08:30:12 -0800 (PST) jmfauth wxjmfa...@gmail.com wrote: Yes, I can launch a pyc, when I have a single file. But what happens, if one of your cached .pyc file import a module with a name as defined in the parent directory? The machinery is broken. The parent dir is not in

Re: __pycache__, one more good reason to stck with Python 2?

On Jan 19, 7:03 pm, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 19 Jan 2011 08:30:12 -0800 (PST) jmfauth wxjmfa...@gmail.com wrote: Yes, I can launch a pyc, when I have a single file. But what happens, if one of your cached .pyc file import a module with a name as defined in the

Re: __pycache__, one more good reason to stck with Python 2?

On Jan 19, 6:42 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: But having said that, the __pycache__ idea isn't too bad. If you have this directory structure: ./module.py ./module.pyc and import module, the top-level .pyc file will continue to be used. Nope. PEP 3147

Re: __pycache__, one more good reason to stck with Python 2?

On Wed, 19 Jan 2011 16:00:20 +0100, Antoine Pitrou wrote: .pyc files are Python byte-code. You can't run them directly using Python (except via the import machinery), you can't run them as a script, they're not machine code. Unless you write a wrapper to import the file as a module, you

Re: __pycache__, one more good reason to stck with Python 2?

On Wed, 19 Jan 2011 11:30:36 -0800, Carl Banks wrote: On Jan 19, 6:42 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: But having said that, the __pycache__ idea isn't too bad. If you have this directory structure: ./module.py ./module.pyc and import module, the top-level

Re: __pycache__, one more good reason to stck with Python 2?

On 2011-01-19 13:01:04 -0800, Steven D'Aprano said: I know I've seen problems executing .pyc files from the shell in the past... perhaps I was conflating details of something else. Ah, I know! [steve@sylar ~]$ chmod u+x toto.pyc [steve@sylar ~]$ ./toto.pyc : command not found �� ./toto.pyc:

Re: __pycache__, one more good reason to stck with Python 2?

On Jan 18, 6:07 am, Terry Reedy tjre...@udel.edu wrote: ... This is the 21-year-old behavior now changed. ... Yes, you summarized the situation very well. The way of working has changed and probably more deeply that one may think. It is now practically impossible to launch a Python

Re: __pycache__, one more good reason to stck with Python 2?

Carl Banks wrote: On Jan 17, 6:29 pm, Alice Bevan–McGregor al...@gothcandy.com wrote: find . -name \*.pyc -exec rm -f {} \; vs. rm -rf __pycache__ I do not see how this is more difficult, but I may be missing something. Well the former deletes all the pyc files in the directory tree

Re: __pycache__, one more good reason to stck with Python 2?

Terry Reedy, 18.01.2011 04:39: Saving module code to the filesystem speeds startup, which most find slow as it is. I've been using Jython recently, which, in addition to the huge JVM startup time, must also fire up the Jython runtime before actually doing anything useful. I must say that I

Re: __pycache__, one more good reason to stck with Python 2?

Peter Otten, 18.01.2011 10:04: What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'? The former runs in parallel, the latter runs sequentially. Stefan -- http://mail.python.org/mailman/listinfo/python-list

Re: __pycache__, one more good reason to stck with Python 2?

jmfauth, 18.01.2011 09:58: About the caches, I'am just fearing, they will become finally garbage collectors of orphan .pyc files, Python has seeded I can't see how that is supposed to be any different than before. If you rename a file without deleting the .pyc file, you will end up with an

Re: __pycache__, one more good reason to stck with Python 2?

the source file would have been, not in the __pycache__ directory (it'll be considered stale otherwise). Typo? According to PEP 3147 a standalone *.pyc *should* (not should not) be put in the same directory where the source file would have been. ~Ethan~ -- http://mail.python.org/mailman

Re: __pycache__, one more good reason to stck with Python 2?

Peter Otten __pete...@web.de writes: Carl Banks wrote: Well the former deletes all the pyc files in the directory tree whereas the latter only deletes the top level __pycache__, not the __pycache__ for subpackages. To delete all the __pycache__s you'd have to do something like

Re: __pycache__, one more good reason to stck with Python 2?

Stefan Behnel wrote: Peter Otten, 18.01.2011 10:04: What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'? The former runs in parallel, the latter runs sequentially. This may sometimes be relevant, but I doubt that it matters in this particular case. Peter --

Re: __pycache__, one more good reason to stck with Python 2?

Sherm Pendley wrote: Peter Otten __pete...@web.de writes: Carl Banks wrote: Well the former deletes all the pyc files in the directory tree whereas the latter only deletes the top level __pycache__, not the __pycache__ for subpackages. To delete all the __pycache__s you'd have to do

Re: __pycache__, one more good reason to stck with Python 2?

On Tue, Jan 18, 2011 at 8:27 AM, Peter Otten __pete...@web.de wrote: Stefan Behnel wrote: Peter Otten, 18.01.2011 10:04: What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'? The former runs in parallel, the latter runs sequentially. This may sometimes be relevant, but

__pycache__, one more good reason to stck with Python 2?

fall on this cached pyc's directory, __pycache__. Without to many explanations (I think they will be obvious for an end user), one word: a nithtmare. -- http://mail.python.org/mailman/listinfo/python-list

Re: __pycache__, one more good reason to stck with Python 2?

3.2rc1. Python is still this powerful and pleasant language, but... I fall on this cached pyc's directory, __pycache__. Without to many explanations (I think they will be obvious for an end user), one word: a nithtmare. What are the specific problems you've seen with __pycache__? Have you

Re: __pycache__, one more good reason to stck with Python 2?

is still this powerful and pleasant language, but... I fall on this cached pyc's directory, __pycache__. Without to many explanations (I think they will be obvious for an end user), one word: a nithtmare. No, I'm sorry, they're not obvious at all. I too have been using Python since version

Re: __pycache__, one more good reason to stck with Python 2?

No, I'm sorry, they're not obvious at all. These reasons become obious as soon as you start working. Let's take a practical point view. It did not take a long time to understand, that it is much simpler to delete the __pycache__ directory everytime I compile my scripts than to visit it just

Re: __pycache__, one more good reason to stck with Python 2?

a practical point view. It did not take a long time to understand, that it is much simpler to delete the __pycache__ directory everytime I compile my scripts than to visit it just because I deleted or renamed a .py file in my working directory. Deleting the subdirectory is as least as easy as searching

Re: __pycache__, one more good reason to stck with Python 2?

-compilation, and may also deactivate __pycache__ effects, but i'm not sure, i can't test it now. See http://docs.python.org/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE . The implications of deactivating this behaviour are somewhat obvious, and i wonder what impacts it'd cause on your system (but i

  1   2   >