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
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
>> ./module.pyc
>>
>> and import module, the
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. PEP 3147 says it now always uses __pycache_
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
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
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 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__ for subpackages. To delete all the __pycache__s you'd
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'd
>> have to do something like t
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
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 former deletes all the pyc files in the directory tree
>
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 to delete the __pycache__
> directory everyti
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
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 think python
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
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
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
> 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
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
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
46 matches
Mail list logo
