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
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
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
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 `('
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
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
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 possible?
.pyc files are Python byte-code. You can't run them directly using Python
(except via the import machinery), you can't run
On 19 Jan 2011 14:42:14 GMT
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 possible?
.pyc files are Python
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
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
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
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
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
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
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
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:
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
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
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
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
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
Carl Banks wrote:
On Jan 17, 10:17 am, jmfauth wxjmfa...@gmail.com wrote:
...
If I get (stupidly, I agree) a .pyc file and want to test
it. Should I create manually a cache alongside my test.py
script?
Nope: according to PEP 3147 a standalone *.pyc should not be put in
same directory where
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 this:
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
--
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
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
As a scientist using computer tools, and not as a computer
scientist, I discovered Python long time ago (it was in its
1.5.6 version) and I remain an happy user up to now date.
Yesterday, I was happy to download and test Python 3.2rc1.
Python is still this powerful and pleasant language, but...
I
On Mon, Jan 17, 2011 at 08:31, jmfauth wxjmfa...@gmail.com wrote:
As a scientist using computer tools, and not as a computer
scientist, I discovered Python long time ago (it was in its
1.5.6 version) and I remain an happy user up to now date.
Yesterday, I was happy to download and test Python
On Mon, 17 Jan 2011 06:31:00 -0800, jmfauth wrote:
As a scientist using computer tools, and not as a computer scientist, I
discovered Python long time ago (it was in its 1.5.6 version) and I
remain an happy user up to now date. Yesterday, I was happy to download
and test Python 3.2rc1. Python
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
No. The benefit of, for instance, not adding 200 .pyc files to a
directory with 200 .py files is immediately obvious to most people.
On 1/17/2011 1:17 PM, jmfauth wrote:
No, I'm sorry, they're not obvious at all.
These reasons become obious as soon as you start working.
Let's take a
That's why i disagree (and hate) the automatic compilation of code, my
project directory becomes full of object files, and then i need to either
delete everything manually or create a script to do the work (not in python,
because it'll dirt things even more :). Sometimes i notice python doesn't
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.
— Alice.
--
http://mail.python.org/mailman/listinfo/python-list
On 1/17/2011 8:59 PM, Flávio Lisbôa wrote:
That's why i disagree (and hate) the automatic compilation of code, my
project directory becomes full of object files
That is one point of stashing them all in a .__pycache__ directory.
After reading some articles about it, I've come to think python
Terry Reedy tjre...@udel.edu writes:
On 1/17/2011 8:59 PM, Flávio Lisbôa wrote:
But that's me, i'm sure most of python users don't mind at all.
Seems so. Complaints are rare.
That conclusion isn't valid; the behaviour is (AIUI) only in Python 3.2
and later. You can't presume that a lack of
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
whereas
On Jan 17, 10:17 am, jmfauth wxjmfa...@gmail.com wrote:
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__
On 1/17/2011 10:57 PM, Ben Finney wrote:
Terry Reedytjre...@udel.edu writes:
On 1/17/2011 8:59 PM, Flávio Lisbôa wrote:
But that's me, i'm sure most of python users don't mind at all.
Seems so. Complaints are rare.
That conclusion isn't valid; the behaviour is (AIUI) only in Python 3.2
On Jan 17, 10:17 am, jmfauth wxjmfa...@gmail.com wrote:
That's life, unfortunately.
Also, an earlier version of the proposal was to create a *.pyr
directory for each *.py file. That was a real mess; be thankful they
worked on it and came up with a much cleaner method.
Carl Banks
--
39 matches
Mail list logo
