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 p
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 -- lo
On Tue, Feb 3, 2015 at 10:31 AM, Mark Lawrence
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 -site:stackoverflow.com
Skip
--
https://
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 r
On Wed, Feb 4, 2015 at 1:34 AM, 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
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 rec
On Mon, Feb 2, 2015 at 4: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
On Mon, Feb 2, 2015 at 4: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
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 t
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
> 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
> 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
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
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 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
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
>
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 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. P
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 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
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
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
" > toto.py
$ __svn__/python -m compileall -l .
Listing . ...
Compiling ./toto.py ...
$ rm 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
;s a
PITA, and I wish they'd standardize on a single cache location, to make
it easy to exclude them from backups, 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
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, 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
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
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:
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&
e 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/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
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
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
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
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
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 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:
> > 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 t
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 tr
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 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 th
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
eactivates auto-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'
t'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
because I deleted or renamed a .py file in my working directory.
Deleting the subdirectory is as least as ea
> 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 tha
ython 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.
No, I'm sorry, they're not obvious a
ython 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 see
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
48 matches
Mail list logo
