Actually, it seems that IPython’s run magic runs the file in its own namespace, 
where __file__ is defined. And afterwards, the current/main namespace is 
updated with the variables created by running the file. However, the current 
directory is not changed.

=== test.py ===
import os
print(os.getcwd())
print(__file__)
try:
    print(foo)
except NameError:
    print('cannot reach foo')
bar = 3

=== IPython ---
In [1]: cd
C:\Users\almar

In [2]: bar = 0

In [3]: foo = 0

In [4]: %run d:\dev\py\test.py
C:\Users\almar
d:\dev\py\test.py
cannot reach foo

In [5]: bar
Out[5]: 3

In [6]: __file__
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-6-adeb0343a89b> in <module>()
----> 1 __file__

NameError: name '__file__' is not defined

======

From: Dietrich Pescoller
Sent: 11 October 2016 12:09
To: Pyzo
Cc: dit...@gmail.com; projet...@gmail.com
Subject: Re: [Pyzo] IEP and __file__

Ok I see your point. I did the following further tests:

I have the prova.py file containing print(__file__)

and did the following with 
 ~/anaconda3/bin/python
with open("/tmp/prova.py") as f:
   code = compile(f.read(), "/tmp/prova.py", 'exec')
   exec(code)

and got
/tmp/prova.py in <module>()
----> 1 print(__file__)

NameError: name '__file__' is not defined

Than I did 
 ~/anaconda3/bin/ipython
In [1]: %run /tmp/prova.py
/tmp/prova.py

So should pyzo be more "compatible/similar" to python or ipython?

IMO since pyzo is more a Scientifice IDE, (ala Matlab) probably it should be 
more "compatible/similar" to ipython than pure python.
Probably sometimes pragmaticity should be preferred to purity.

But this is only my personal opinion, I fully understand your point and I m not 
the person who can say which one is the better one. Probably this should become 
a more
general discussion with more people involved.

Anyway, probably the best  is to let the things like they are, unless other 
people or other arguments come up to support my way.

Thanks,
Dietrich








Il giorno martedì 11 ottobre 2016 10:52:36 UTC+2, Almar Klein ha scritto:
> wouldn't it be the best/easiest solution or simply set the __file__ variable 
> as the standard behavior?
 
Well, if you’d first run a file as a script (which would set __file__), and 
then run another file (not as a script) then the __file__ would be overwritten, 
which would be wrong, IMO; __file__ should maintain the value of the script 
that was initially run.
 
> __file__ is only present when running a file as script. Similar to how there 
> is no __file__ in the normal Python interpreter
 
I mean that there is no __file__ when you run the Python interpreter 
interactively, without running a script. In your example you do run a ascript. 
Try:
 
$ python
>> __file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name '__file__' is not defined
 

 
From: Dietrich Pescoller
Sent: 10 October 2016 14:36
To: Pyzo
Cc: dit...@gmail.com; proj...@gmail.com
Subject: Re: [Pyzo] IEP and __file__
 
In your suggestion the only drawback is that 'foo.py' needs to be set manually, 
This would work and is acceptable but of course not optimal.

I can understand you point to not add another way to run a file.
My question/thought since in the current file execution (command) the __file__ 
is not set and thus typically is not used, wouldn't it be the best/easiest
solution or simply set the __file__ variable as the standard behavior?

Btw you wrote in a prevoius mail: """__file__ is only present when running a 
file as script. Similar to how 
there is no __file__ in the normal Python interpreter. """

I'm not sure this is correct since I thing that the standard python interpreter 
actually defines the __file__variable.

I did worte prova.py with the following simple code:
print(__file__)

and obtained both with ipython and python the same result:

diti$ ~/anaconda3/bin/ipython /tmp/prova.py 
/tmp/prova.py
diti$ ~/anaconda3/bin/python /tmp/prova.py 
/tmp/prova.py

Thanks,
Dietrich

Il giorno lunedì 10 ottobre 2016 11:26:13 UTC+2, Almar Klein ha scritto:
I am hesitant to add yet another way to run a file. Since the current directory 
is changed now, would it work for you to put this at the top of your file:
 
__file__ = os.path.join(os.cwd(), ‘foo.py’)
 
From: Dietrich Pescoller
Sent: 10 October 2016 09:20
To: Pyzo
Cc: dit...@gmail.com; proj...@gmail.com
Subject: Re: [Pyzo] IEP and __file__
 
Yes, but also in this case if I run the file as a script than the console is 
retarted and we loose all previous work.
Effectively we are in a very same situation as we had with the current 
directory setting.

Perhaps could it be the definitive solution to have the option "running as a 
script" not restarting the shell? If this is needed the user can do it very 
easily manually, or perhaps having a third option, i.e. run as a script (with 
all the special settings __file__ setting directory,) but not automatically 
restarting. (just a thought)

Finally I not really need to use __file__ I would just need to find out another 
way to get the current filename.

Thanks,
Dietrich

Il giorno sabato 8 ottobre 2016 22:02:29 UTC+2, Almar Klein ha scritto:
Run the file as a script.
 
Running code normally (not as a script) is equivalent to firing up having a 
Python interpreter and running code in it. There is no script file, and thus no 
__file__. Technically, Pyzo could set __file__ each time a file is run, but it 
would be wrong to reset that variable.
 
I recently made a change to set the current directory when a file is run also 
if its *not* run as a script. In this case practicality beats purity, plus the 
current directory is expected to be more dynamic than the value of __file__.
 
- Almar
 
 
 
From: Dietrich Pescoller
Sent: 07 October 2016 16:41
To: Pyzo
Cc: proj...@gmail.com
Subject: Re: [Pyzo] IEP and __file__
 
I had the same issue recently.
What would be the best way in a script to get its own filename than?

Thanks,
Dietrich



Il giorno martedì 13 ottobre 2015 22:32:24 UTC+2, Almar Klein ha scritto:
__file__ is only present when running a file as script. Similar to how 
there is no __file__ in the normal Python interpreter. 

- Almar 

On 13-10-15 22:08, Christophe Bal wrote: 
> Hello. 
> 
> It seems that I can't use directly __file__. Is it normal or is it a bug 
> ? If it's normal what is the technical reason for that ? 
> 
> 
> *Christophe BAL* 
> *Enseignant de mathématiques en Lycée **et développeur Python amateur* 
> *---* 
> *French math teacher in a "Lycée" **and **Python **amateur developer* 
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Pyzo" group. 
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to pyzo+uns...@googlegroups.com 
> <mailto:pyzo+uns...@googlegroups.com>. 
> For more options, visit https://groups.google.com/d/optout. 
-- 
You received this message because you are subscribed to the Google Groups 
"Pyzo" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pyzo+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
-- 
You received this message because you are subscribed to the Google Groups 
"Pyzo" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pyzo+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
-- 
You received this message because you are subscribed to the Google Groups 
"Pyzo" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pyzo+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
-- 
You received this message because you are subscribed to the Google Groups 
"Pyzo" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pyzo+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Pyzo" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pyzo+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to