Re: write to file
On Sunday, 6 May 2018 10:48:12 UTC+5:30, Chris Angelico wrote:
> On Sun, May 6, 2018 at 3:10 PM, Sharan Basappa
> wrote:
> > On Saturday, 5 May 2018 21:47:33 UTC+5:30, Steven D'Aprano wrote:
> >> On Sat, 05 May 2018 08:45:39 -0700, Sharan Basappa wrote:
> >>
> >> > Thanks a lot. I have actually tried print with file handle as a
> >> > parameter (the last option). I see that the file is created but nothing
> >> > is logged.
> >>
> >> That could be a file buffer issue. Nothing will actually be written to
> >> the disk until either the buffer is full, or you close the file. Try
> >> calling fh.flush() from time to time, or use:
> >>
> >> print(msg, file=fh, flush=True)
> >>
> >>
> >> although things may be different on Windows. (For example, you may not be
> >> able to open the file while it is still open in Python.)
> >>
> >>
> >>
> >> --
> >> Steve
> >
> > Steve,
> >
> > I agree that flushing could be an issue but I assume when the program
> > closes, buffered data should be flushed even if I am explicitly flushing.
> > This I did not see happening. Probably, I have to spend some additional
> > time.
> > --
>
> Can you post a complete (but preferably small) example of a program
> that creates a file but doesn't properly write to it?
>
> ChrisA
Thanks, Everyone. I was probably making some mistake.
I re-checked again and added file handle to the prints.
Everything works fine.
Below is the code ...
# Imports
from matplotlib import pyplot as plt
from sklearn.datasets import load_iris
import numpy as np
import pickle
fh = open("ML_PY_2.log","w+")
# load the data with load_iris from sklearn
data = load_iris()
features = data['data']
feature_names = data['feature_names']
target = data['target']
target_names = data['target_names']
labels = target_names[target]
plength = features[:,2]
# use numpy operations to get setosa features
is_setosa = (labels == 'setosa')
# this the important step
max_setosa = plength[is_setosa].max()
min_non_setosa = plength[~is_setosa].min()
print("data\n",data,file=fh)
print("target\n",target, file=fh)
print("target_names\n",target_names,file=fh)
print("labels\n",labels,file=fh)
print("is_setosa\n",is_setosa,file=fh)
print("plength\n",plength,file=fh)
print('maximum of setosa: {0}.'.format(max_setosa))
print('minimum of others: {0}.'.format(min_non_setosa))
fh.close()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tk covering the entire screen
> Try to upgrade to 2.7.15. It should be shipped with Tk 8.6. Thanks. I'm using an internal (to work) Anaconda distro at work. Hopefully it will update soon. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: ImportError: cannot import name _remove_dead_weakref
joseph pareti writes: > thanks for the hint, virtualenv looks like an interesting option, however > in my case I need to rely on several components that are already installed > in the VM in Azure, including tensorflow, etc. > If I use virtualenv, do I need to start from scratch? "virtualenv" has an option which makes the Python packages installed in the "parent" Python installation available in the created virtual environment. The "parent" Python installation is determined by the Python you call "virtualenv" with. Typically, it is a system Python installation. This way, you can make your system Python modules and packages available in your created virtual environment. > In addition, I am not sure this will solve my problem: all I have seen is > that the error code changes depending on the PYTHONPATH value. Perhaps it > is a bug in the application code? Likely, this alone will not solve your problem -- it might only help you with a solution. You have provided detailed error information only in your initial post. Someone looked at those details and noticed that parts of a Python 3 and of a Python 2 installation where involved -- which is a very bad sign. You must ensure that only either Python 2 or Python 3 parts are used by your application - not a mix of both. In a typical setup, Python 2 and Python 3 installations are well separated -- not in your case, however. A set "PYTHONPATH" can cause those installations to interfere with one another. You reported that unsetting "PYTHONPATH" has changed the observed behaviour. This indicates, that in your environment, "PYTHONPATH" is set. A virtual environment is a tool to avoid the need to set "PYTHONPATH" (which easily confuses setups with both Python 2 and Python 3 installations). >From what you describe, I conclude that in your case the "PYTHONPATH" setting is important for your application. For a quick fix, I would investigate for which Python version this setting was designed for and then use this Python version for your application. However, as far as we know up to now, your environment has both Python 2 and Python 3 installed -- and in such an environment, a (quite) "global" "PYTHONPATH" setting can lead to surprises. Using "virtualenv"s can avoid the use of "PYTHONPATH" (another way would be to use a shell wrapper for the applications which sets "PYTHONPATH" appropriately and then calls the application; then, you would no longer need a "global" "PYTHONPATH"). -- https://mail.python.org/mailman/listinfo/python-list
