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 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.
> Pytho
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. Pyt
> 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
bec
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 practic
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
rec
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 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 complaints m
On Jan 17, 6:29 pm, Alice Bevan–McGregor 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 the latter o
On Jan 17, 10:17 am, 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 practical point view. It did not take a long time
> to understand, that it is much simpler to delete the __pycache__
> directory everyti
On 1/17/2011 10:57 PM, Ben Finney wrote:
Terry Reedy 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
On Jan 17, 10:17 am, jmfauth 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
--
http://mail.python.org/mailm
On Jan 18, 6:07 am, Terry Reedy 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
application via a .pyc
Carl Banks wrote:
> On Jan 17, 6:29 pm, Alice Bevan–McGregor 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
o
Carl Banks wrote:
On Jan 17, 10:17 am, jmfauth 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 the source file wo
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 t
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
--
http:
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
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
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 de
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 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 byte-code. You can't run them
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 r
H₂0.py 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 a large
On Wed, 19 Jan 2011 08:30:12 -0800 (PST)
jmfauth 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 the
> sys.path.
W
On Jan 19, 7:03 pm, Antoine Pitrou wrote:
> On Wed, 19 Jan 2011 08:30:12 -0800 (PST)
>
> jmfauth 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 machine
On Jan 19, 6:42 am, Steven D'Aprano 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 says it now always uses __pycache_
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, y
On Wed, 19 Jan 2011 11:30:36 -0800, Carl Banks wrote:
> On Jan 19, 6:42 am, Steven D'Aprano +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
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: lin
Hi
You have disturbe my slumber, Steven ;-)
On Jan 19, 2:42 pm, Steven D'Aprano 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 byt
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 +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 do
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
39 matches
Mail list logo
