Re: [Pyzo] Strange behavior in console history

[Dietrich Pescoller]

Thanks
Dietrich

Il giorno martedì 11 ottobre 2016 11:00:38 UTC+2, Almar Klein ha scritto:
>
> There already is an issue for it. And now wrote it on my personal todo 
> list. Might be a few weeks before I get to it though.
>
>  
>
> https://github.com/pyzo/pyzo/issues/248
>
>  
>
>  
>
>  
>
> *From: *Dietrich Pescoller 
> *Sent: *10 October 2016 14:39
> *To: *Pyzo 
> *Cc: *dit...@gmail.com 
> *Subject: *Re: [Pyzo] Strange behavior in console history
>
>  
>
> Ok,
> was thinking there is just a simple line/command to type...
>
> Anyway, do you thing this is something which will be fixed soon? So should 
> we just wait and be patient, or should we try to find a way to leave with 
> this issue?
>
> Thanks,
> Dietrich
>
> Il giorno lunedì 10 ottobre 2016 11:23:00 UTC+2, Almar Klein ha scritto:
>
> That’s probably possible. But typing that code into the logger shell each 
> time would be tedious. So you’d have to modify the Pyzo source code.
>
>  
>
>  
>
> *From: *Dietrich Pescoller
> *Sent: *10 October 2016 09:23
> *To: *Pyzo
> *Cc: *dit...@gmail.com
> *Subject: *Re: [Pyzo] Strange behavior in console history
>
>  
>
> Is there perhaps a temporary manual workaround for this? For instance to 
> load the history tool entries into console?
> This would be already be very useful
>
> Thanks,
> Dietrich
>
> Il giorno sabato 24 settembre 2016 14:26:14 UTC+2, Almar Klein ha scritto:
>
> I think both tools keep track of history separately from each other. While 
> the tool preserves it between sessions, the shell’s own history does not. 
> There is an issue to fix the latter.
>
>  
>
>  
>
>  
>
> *From: *Dietrich Pescoller
> *Sent: *23 September 2016 15:44
> *To: *Pyzo
> *Subject: *[Pyzo] Strange behavior in console history
>
>  
>
> Do some one else have strange behaviors in the Ipython console History 
> using pyzo?
>
> The history viewer seems to work properly, ie.. if you issue a new command 
> it updates the history.
>
> If you restart the shell, if you use UP and Down arrow the commands do not 
> appear.
> If you issue a new command and do not restart the shell the arrow work for 
> that command.
>
> It is strange because the history viewer contains typically all the 
> commands from older sessions... but those are not recallable from the 
> Ipython-console
>
> Thanks,
> Dietrich
>
> -- 
> 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.

Re: [Pyzo] IEP and __file__

[Dietrich Pescoller]

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 ()
> 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 "", line 1, in 
>
> 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 

Re: [Pyzo] Re: crash on startup 4.3.1

[wjrolls]

Sorry I can't be more specific. It doesn't give me any error messages or 
anything else - it just fails...




On Tuesday, October 11, 2016 at 10:54:46 AM UTC+1, Almar Klein wrote:
>
> Hi Will,
>
>  
>
> That’s a serious problem. Hard to say what the exact problem is though. We 
> switched to using PyQt5 for the binaries, maybe we should fall back to 
> PySide...
>
>  
>
> - Almar
>
>  
>
>  
>
> *From: *wjr...@gmail.com 
> *Sent: *11 October 2016 11:34
> *To: *Pyzo 
> *Subject: *[Pyzo] Re: crash on startup 4.3.1
>
>  
>
> OK I've uninstalled 4.3 and reinstalled 4.2.1 and everything is working 
> fine again...
>
>  
>
> There is clearly something weird going on, bu I've no idea what... Can 
> anyone help me?
>
>  
>
> Thanks
>
>  
>
>  
>
>  
>
>
>
> On Tuesday, October 11, 2016 at 10:06:26 AM UTC+1, wjr...@gmail.com wrote:
>
> Hi,
>
> I've just upgraded to 4.3.1 from 4.2.1 and there seems to be a problem. 
> Every time I try and launch the program I get the splash screen, which then 
> disappears, and then the program closes. I'm running windows 10 - if that 
> makes any difference...
>
> Any ideas?
>
> Cheers
>
> Will
>
> -- 
> 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.

RE: [Pyzo] Re: crash on startup 4.3.1

[almar.klein]

Hi Will,

That’s a serious problem. Hard to say what the exact problem is though. We 
switched to using PyQt5 for the binaries, maybe we should fall back to PySide...

- Almar


From: wjro...@gmail.com
Sent: 11 October 2016 11:34
To: Pyzo
Subject: [Pyzo] Re: crash on startup 4.3.1

OK I've uninstalled 4.3 and reinstalled 4.2.1 and everything is working fine 
again...

There is clearly something weird going on, bu I've no idea what... Can anyone 
help me?

Thanks





On Tuesday, October 11, 2016 at 10:06:26 AM UTC+1, wjr...@gmail.com wrote:
Hi,

I've just upgraded to 4.3.1 from 4.2.1 and there seems to be a problem. Every 
time I try and launch the program I get the splash screen, which then 
disappears, and then the program closes. I'm running windows 10 - if that makes 
any difference...

Any ideas?

Cheers

Will
-- 
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.

[Pyzo] Re: crash on startup 4.3.1

[wjrolls]

OK I've uninstalled 4.3 and reinstalled 4.2.1 and everything is working 
fine again...

There is clearly something weird going on, bu I've no idea what... Can 
anyone help me?

Thanks





On Tuesday, October 11, 2016 at 10:06:26 AM UTC+1, wjr...@gmail.com wrote:
>
> Hi,
>
> I've just upgraded to 4.3.1 from 4.2.1 and there seems to be a problem. 
> Every time I try and launch the program I get the splash screen, which then 
> disappears, and then the program closes. I'm running windows 10 - if that 
> makes any difference...
>
> Any ideas?
>
> Cheers
>
> Will
>

-- 
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.

[Pyzo] crash on startup 4.3.1

[wjrolls]

Hi,

I've just upgraded to 4.3.1 from 4.2.1 and there seems to be a problem. 
Every time I try and launch the program I get the splash screen, which then 
disappears, and then the program closes. I'm running windows 10 - if that 
makes any difference...

Any ideas?

Cheers

Will

-- 
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.

RE: [Pyzo] Strange behavior in console history

[almar.klein]

There already is an issue for it. And now wrote it on my personal todo list. 
Might be a few weeks before I get to it though.

https://github.com/pyzo/pyzo/issues/248



From: Dietrich Pescoller
Sent: 10 October 2016 14:39
To: Pyzo
Cc: dit...@gmail.com
Subject: Re: [Pyzo] Strange behavior in console history

Ok,
was thinking there is just a simple line/command to type...

Anyway, do you thing this is something which will be fixed soon? So should we 
just wait and be patient, or should we try to find a way to leave with this 
issue?

Thanks,
Dietrich

Il giorno lunedì 10 ottobre 2016 11:23:00 UTC+2, Almar Klein ha scritto:
That’s probably possible. But typing that code into the logger shell each time 
would be tedious. So you’d have to modify the Pyzo source code.
 
 
From: Dietrich Pescoller
Sent: 10 October 2016 09:23
To: Pyzo
Cc: dit...@gmail.com
Subject: Re: [Pyzo] Strange behavior in console history
 
Is there perhaps a temporary manual workaround for this? For instance to load 
the history tool entries into console?
This would be already be very useful

Thanks,
Dietrich

Il giorno sabato 24 settembre 2016 14:26:14 UTC+2, Almar Klein ha scritto:
I think both tools keep track of history separately from each other. While the 
tool preserves it between sessions, the shell’s own history does not. There is 
an issue to fix the latter.
 
 
 
From: Dietrich Pescoller
Sent: 23 September 2016 15:44
To: Pyzo
Subject: [Pyzo] Strange behavior in console history
 
Do some one else have strange behaviors in the Ipython console History using 
pyzo?

The history viewer seems to work properly, ie.. if you issue a new command it 
updates the history.

If you restart the shell, if you use UP and Down arrow the commands do not 
appear.
If you issue a new command and do not restart the shell the arrow work for that 
command.

It is strange because the history viewer contains typically all the commands 
from older sessions... but those are not recallable from the Ipython-console

Thanks,
Dietrich
-- 
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.

RE: [Pyzo] IEP and __file__

[almar.klein]

> 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 "", line 1, in 
NameError: name '__file__' is not defined




From: Dietrich Pescoller
Sent: 10 October 2016 14:36
To: Pyzo
Cc: dit...@gmail.com; projet...@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 
> . 
> 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